skip()实际跳过字节数可能小于请求值，需循环调用并校验返回值；推荐用filechannel.position()替代，避免字符边界和性能问题。
skip() 方法能跳过多少字节？
skip() 方法声明为 long skip(long n)，但实际跳过的字节数可能小于请求值——它只保证“尽力跳过”，返回值才是真实跳过的字节数。对大文件做偏移定位时，不能假设 skip(1024 * 1024) 一定跳过 1MB；尤其在 NFS、加密文件系统或某些 JDK 实现（如早期 OpenJDK on Windows）上，多次小量 skip() 比单次大数值更可靠。
常见错误现象：skip(1000000) 返回 123456，后续读取却从错误位置开始，因为没校验返回值。
- 必须用循环调用，直到累计跳过目标偏移量
- 每次调用后检查返回值：若为
0，说明已到 EOF 或流阻塞，应中断并报错 - 避免传入负数，会直接抛
IllegalArgumentException
为什么 FileInputStream.skip() 在大文件里有时慢得反常？
底层依赖操作系统 lseek() 系统调用是否支持。如果文件描述符指向的是普通磁盘文件（非管道、socket、/proc 文件），skip() 通常是 O(1)；但若文件被 mmap 映射过、或运行在某些容器环境（如旧版 Docker with overlayfs），内核可能退化为逐字节读丢弃，导致跳 1GB 耗时数秒。
实操建议：
- 用
FileChannel.position(long)替代：它直接映射lseek()，更稳定且不消耗缓冲区 - 先
fileInputStream.getChannel().position(offset)，再用原流读取，无需调用skip() - 注意：
FileChannel.position()不影响流本身的内部缓冲，所以要确保流未预读（例如刚 new 出来就调 position）
跳过偏移后读取中文乱码？编码和 BOM 怎么处理？
skip() 是字节级操作，不识别字符边界。若偏移量落在 UTF-8 多字节字符中间（比如跳到某个汉字第二字节），后续用 InputStreamReader 读取就会解码失败，出现 或 MalformedInputException。
使用场景明确是文本文件时：
- 不要用
skip()定位到“第 N 行”或“第 M 个字符”，而应定位到已知的字节安全点（如行首、BOM 后、或固定分隔符后） - UTF-8 BOM 是
0xEF 0xBB 0xBF三字节，若文件带 BOM 且你想跳过它，skip(3)安全；但若不确定是否有 BOM，先读 3 字节判断再决定是否跳 - 真正需要按字符偏移读取时，改用
RandomAccessFile或内存映射（MappedByteBuffer），自己解析 UTF-8 字节序列
替代 skip() 的更可靠方案：FileChannel + position()
这是目前最推荐的大文件偏移定位方式，绕过 skip() 的不确定性，也规避了字符边界问题（因为定位本身不涉及解码）。
FileInputStream fis = new FileInputStream("huge.log");
FileChannel channel = fis.getChannel();
channel.position(1024 * 1024); // 直接跳到 1MB 处
// 后续用 fis.read() 读取，位置已更新
byte[] buf = new byte[8192];
int n = fis.read(buf);
注意点：
- 必须在
FileInputStream创建后立即获取channel，避免流已被包装（如被BufferedInputStream包裹则getChannel()返回 null） -
position()设置后，所有基于该流的读操作都从此位置开始，包括read(byte[])和read(ByteBuffer) - 如果文件被其他进程写入，
position()不保证原子性，需配合文件锁（channel.lock()）
真正麻烦的地方不在跳转本身，而在你跳到的位置是否“语义合法”——比如跳进一个 JSON 对象中间、跳过 gzip header 却没校验魔数、或跳到 tar 归档块中间。这些都不是 skip() 能解决的，得靠业务层协议感知。
