BufferedInputStream 与 FileInputStream 共享文件句柄但不共享 FileChannel，后者需通过原始 FileInputStream 显式获取；二者读取位置不同步，mark/reset 为内存行为，position() 为系统级偏移，混用易导致数据重复或遗漏，建议二选一使用。
BufferedInputStream 和 FileInputStream 共享底层文件句柄，但它们不共享 FileChannel 实例，也不会自动协同操作 —— FileChannel 是独立通道，需显式获取，与缓冲流逻辑隔离。
FileChannel 不能从 BufferedInputStream 直接获取
BufferedInputStream 没有 getChannel() 方法。只有原始的 FileInputStream（或 RandomAccessFile、FileOutputStream）能返回 FileChannel。即使你把 FileInputStream 包装成 BufferedInputStream，调用 bufferedInputStream.getChannel() 会编译失败。
正确做法是：保留对原始 FileInputStream 的引用，再调用其 getChannel()：
- FileInputStream fis = new FileInputStream("data.txt");
- BufferedInputStream bis = new BufferedInputStream(fis); // 包装后仍可访问 fis
- FileChannel channel = fis.getChannel(); // ✅ 合法
两者读取位置可能不同步
FileInputStream 的 position 由系统内核维护；BufferedInputStream 在内存中维护自己的读取偏移（基于已缓存的数据）。一旦 BufferedInputStream 读过一部分数据，底层 FileInputStream 的文件指针其实已被移动，但 BufferedInputStream 自身不暴露该位置，也无法用 channel.position() 精确同步到“当前已读完的逻辑位置”。
立即学习“Java免费学习笔记（深入）”；
例如：
- fis.getChannel().position() 返回的是内核级文件指针（比如已读 1024 字节）
- bis.mark(1024); bis.read(); bis.reset(); 这个 reset 只在缓冲区内回退，不改变内核指针
- 此时 fis.getChannel().position() 仍为 1024，而 bis 的逻辑读取点回到了 mark 处
换句话说：BufferedInputStream 的 mark/reset 是纯内存行为，FileChannel 的 position() 是系统级偏移 —— 它们属于两套独立机制。
实际使用中建议避免混合操作
同一 FileInputStream 实例，不要一边用 BufferedInputStream 读，一边又用其 FileChannel 做 transferTo 或 read(ByteBuffer)。原因如下：
- BufferedInputStream 已预读部分数据进缓冲区，但这些字节并未反映在 channel.position() 中
- 若在 bis 读了一半后调用 channel.read(buf)，结果可能跳过缓冲区中未消费的数据，造成重复或遗漏
- transferTo() 虽然高效，但要求源 channel 位置准确；若被 BufferedInputStream “偷偷”移动过，transferTo 可能从错误偏移开始
稳妥做法是：二选一 —— 要么全程用 BufferedInputStream（适合逐块/逐行处理），要么直接用 FileChannel + ByteBuffer（适合高性能、零拷贝场景），不要交叉混用。
需要协同时，手动管理位置
如果确实需要结合两者（例如先用 BufferedInputStream 解析头部，再用 FileChannel 读剩余内容），必须手动同步位置：
- 用 BufferedInputStream 读完头部后，调用 fis.getChannel().position(已读字节数)
- 注意：已读字节数不能靠 bis.available() 估算，应自己计数（如每次 read(byte[]) 后累加 len）
- 确保 BufferedInputStream 缓冲区已清空（比如调用 bis.close() 或读到 EOF），否则残留数据会干扰后续 channel 操作
这种模式较脆弱，仅在特定协议解析等少数场景下必要，日常开发中不推荐。
