transferTo 不能跨文件系统使用，因其底层 sendfile 要求源文件系统支持 mmap（如 ext4/xfs），而 NFS、FAT32 等不满足，导致 JDK 回退到低效的用户态缓冲拷贝，丧失零拷贝优势。
transferTo 为什么不能跨文件系统使用
Linux 的 sendfile 系统调用（transferTo 底层依赖它）要求源文件描述符必须支持 mmap，而大多数非 ext4/xfs 的文件系统（如 NFS、FAT32、NTFS 挂载在 Linux 上）不满足这个条件。一旦跨文件系统调用 transferTo，JDK 会自动 fallback 到用户态缓冲区拷贝，**根本不是零拷贝**，且性能可能比 Files.copy() 还差。
验证方法：开启 JVM 参数 -Djdk.nio.maxCachedBufferSize=0 -XX:+PrintGCDetails 并观察日志中是否出现 fallback to transferFrom/transferTo with buffer；更直接的是用 strace -e trace=sendfile,read,write 跟踪系统调用。
- 检查是否同文件系统：
df -T /path/to/src /path/to/dst，输出的Type字段必须一致 - 避免挂载参数干扰：NFS 挂载时禁用
noac或sync，否则内核可能拒绝sendfile - Linux 4.15+ 支持
copy_file_range，JDK 10+ 在部分场景下会尝试用它替代sendfile，但依然受限于文件系统支持
transferTo 的正确调用姿势和分段处理
transferTo 单次调用有长度上限（Linux 通常为 2^31-1 字节），超长文件必须循环分段。更重要的是，它的返回值是**实际传输字节数**，可能小于请求长度（例如磁盘满、信号中断），必须显式检查并重试。
错误写法：channel.transferTo(pos, count, target) 不检查返回值，误以为全部完成。
- 始终用
long transferred = srcChannel.transferTo(pos, count, targetChannel)接收返回值 - 用
while (transferred 循环，更新 <code>pos += transferred和count -= transferred - 注意
FileChannel的 position 是 long，但transferTo的count参数是 long，JVM 会截断为 int 传给sendfile，所以单次不要传超过Integer.MAX_VALUE - 目标
FileChannel必须是可写的，且 position 处于有效范围（比如未 truncate 过小）
Windows 下 transferTo 的实际行为
Windows 没有 sendfile，JDK 的 transferTo 在 Windows 上本质是 ReadFile + WriteFile 的组合，全程走用户态缓冲——**Windows 上没有真正的零拷贝 transferTo**。即使同 NTFS 分区，也不存在内核 bypass。
如果你的应用需跨平台，别依赖 transferTo 实现零拷贝性能优势；Windows 下等效方案是 AsynchronousFileChannel 配合 I/O completion ports，但 API 完全不同。
- 开发时用
System.getProperty("os.name")区分逻辑，Windows 直接走Files.copy() - Windows Server 2019+ 支持
CopyFileEx的COPY_FILE_NO_BUFFERING标志，但 JDK 未暴露该能力 - JDK 17 的
FileChannel.map()在 Windows 上支持MapMode.READ_ONLY+DirectByteBuffer手动读写，可逼近零拷贝效果，但复杂度高
替代方案：什么时候该放弃 transferTo
当你的场景涉及加密、压缩、校验或格式转换时，transferTo 完全无用——它只做原始字节搬运。此时零拷贝已不成立，不如用带堆外缓冲的 ByteBuffer 流式处理，还能控制内存驻留。
- HTTP 响应静态文件：Tomcat/Jetty 内部已对
transferTo做了优化，但 HTTPS 下必然解密/加密，自动退化 - 日志归档管道：如果要同时写多份（如本地 + S3），
transferTo无法 fan-out，得用Channels.newChannel(OutputStream)配合ByteBuffer中转 - 容器环境：Docker overlay2 文件系统不支持
sendfile，Kubernetes Pod 内挂载的 configmap/secrets 也是 tmpfs，transferTo必 fallback
真正关键的不是“用了 transferTo”，而是“数据有没有进过用户态内存”。只要路径里出现一次 byte[] 或 HeapByteBuffer，零拷贝就破了。盯着这个边界比背 API 更重要。
