transferFrom 不保证一次传输全部数据，需循环调用直至返回0或-1；受OS零拷贝支持限制，Windows仅支持SocketChannel→FileChannel，Linux支持更广；须显式管理position，避免覆盖或错位。
transferFrom 为什么经常复制不了全部数据
transferFrom 不保证一次调用就把源通道所有剩余数据搬完，尤其当源是 SocketChannel 或文件未读完时，它只尽力传输当前可读的字节（受系统缓冲区、网络状况、目标文件系统限制等影响）。返回值是实际传输字节数，可能远小于源通道的 size() 或你预期的长度。
实操建议：
- 必须循环调用，直到源通道返回
0（表示暂无可读数据）或-1（如FileChannel到 EOF） - 对
SocketChannel，需确保其处于阻塞模式（configureBlocking(true)），否则可能立即返回0；非阻塞下应配合Selector使用，但transferFrom本身不支持非阻塞源 - 目标
FileChannel必须可写，且 position 处于有效写入位置（例如用channel.position(channel.size())追加）
源通道类型限制很实际
transferFrom 的底层依赖操作系统零拷贝能力（如 Linux 的 sendfile 或 copy_file_range），因此并非所有 ReadableByteChannel 都能高效工作。常见表现：
- 从
FileChannel到FileChannel：通常走内核零拷贝，快且稳定 - 从
SocketChannel到FileChannel：Linux 3.9+ 支持copy_file_range，但若 socket 缓冲区空或目标文件系统不支持，会退化为用户态中转 - 从
Pipe.SourceChannel或自定义ByteBuffer-backed channel：不支持零拷贝，transferFrom会抛IOException或静默降级为普通读写
判断方式：捕获异常并 fallback 到 ByteBuffer + read/write 循环更稳妥。
position 和 size 配合容易出错
transferFrom 总是从目标 FileChannel 当前 position() 开始写，且不会自动移动 position —— 它只负责把数据“倒进去”，不管理游标。常见误操作：
- 调用前没设好 position，导致覆盖已有内容（比如忘了
channel.position(channel.size())） - 误以为
transferFrom会更新 position，结果后续写入错位 - 多线程并发写同一
FileChannel，没同步position，造成数据交错
安全做法：显式调用 channel.position(newPos) 再 transfer，或用 FileChannel.transferFrom(ReadableByteChannel, long position, long count) 重载指定起始偏移，避免依赖隐式 position。
Windows 下 transferFrom 行为差异明显
Windows 的 transferFrom 实现基于 TransmitFile API，仅支持 SocketChannel → FileChannel 场景，且要求目标文件已打开为异步 I/O 模式（即创建 FileChannel 时传入 StandardOpenOption.WRITE 和 StandardOpenOption.DIRECT 不起作用，实际依赖底层句柄标志）。其他组合（如 file→file）会直接抛 IOException：“Operation not supported”。
跨平台兼容方案：
- 先检查
System.getProperty("os.name")，Windows 下主动禁用transferFrom路径 - 统一用
ByteBuffer.allocateDirect(8192)+read/write循环，性能损失在多数业务场景中可接受 - 若坚持零拷贝，Windows 只能用于 HTTP 响应体直接落盘等 socket→file 场景，且需确保 socket 已连接、目标文件以
CREATE和WRITE打开
真正难处理的不是语法，而是不同 OS 对“零拷贝”的定义和支撑程度——同一段代码在 Linux 可能 100% 零拷贝，在 Windows 可能根本走不通，这点常被忽略。
