Files.copy 默认行为因安全检查和强制刷盘导致性能下降，需显式指定 REPLACE_EXISTING、避免 COPY_ATTRIBUTES、确保同文件系统以启用零拷贝，并注意 Windows 路径长度与权限问题。
Files.copy 用错方法会变慢十倍
默认的 Files.copy 调用不指定选项时，走的是“安全但保守”的路径——它会先检查目标是否存在、是否可写、是否是目录，再做原子性复制（比如用临时文件 + rename），这些检查在大批量小文件场景下开销明显。真正影响速度的不是 NIO 本身，而是你没告诉它“我确定目标可覆盖”“我不需要元数据同步”。
- 必须显式传入
StandardCopyOption.REPLACE_EXISTING，否则遇到同名文件直接抛FileAlreadyExistsException - 如果源和目标都在同一文件系统，加上
StandardCopyOption.COPY_ATTRIBUTES可能触发额外的stat和chmod调用，非必要别加 - 避免用
Files.copy(InputStream, Path)或Files.copy(Path, OutputStream)—— 这种绕过通道的用法会退化成传统字节循环，失去零拷贝优势
想用零拷贝？得满足三个硬条件
NIO 的 transferTo / transferFrom 是零拷贝基础，但 Files.copy 只在特定条件下自动启用它：源和目标都必须是 FileChannel，且底层操作系统支持（Linux ≥2.6.33，macOS 不支持 sendfile）。JDK 自己不会帮你判断，它只按规则走。
- 源
Path必须可打开为FileChannel（即不能是符号链接指向不可读路径，也不能是 NFS 挂载点） - 目标
Path所在文件系统必须支持sendfile（ext4/xfs 可以，ZFS/Btrfs 在旧内核上可能降级） - 不能跨设备复制（
df -P src dst显示不同Filesystem字段就肯定不行）
验证是否生效：用 strace -e trace=sendfile,splice,copy_file_range 跑你的程序，看到系统调用才说明真用了零拷贝。
大文件复制卡在 99%？可能是 sync 导致的
Files.copy 默认行为会在写完后调用 force(true) 强制刷盘，这对 SSD 小文件影响不大，但对 10GB+ 文件，内核要等所有页缓存落盘才返回，看起来就是“卡住”。这不是 bug，是设计如此。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 若业务允许短暂掉电丢数据（如缓存文件、临时导出），改用
Files.copy(src, dst, StandardCopyOption.REPLACE_EXISTING)不加其他选项，JVM 不会主动force - 若必须保证数据落盘，但又不想卡主线程，把复制逻辑扔进
ForkJoinPool.commonPool()或独立线程，别阻塞 UI 或响应链 - 别试图用
FileChannel.force(false)手动干预——Files.copy内部通道是临时打开的，你根本拿不到引用
Windows 上复制超大文件失败？注意 MAX_PATH 和权限
Windows 默认路径长度限制 260 字符，而 Files.copy 底层调用 CreateFile 时若路径超限，会直接抛 IOException：“The system cannot find the path specified”，错误信息完全不提长度问题。
- 启用长路径支持：在
application.manifest加longPathAware=true，或 Windows 组策略开启 “Enable Win32 long paths” - 目标目录需有
WRITE_DATA权限，但 Java 不报AccessDeniedException，而是静默失败或抛AccessControlException（取决于 JVM 启动参数） - 不要用
\?前缀手动构造路径传给Files.copy—— JDK 11+ 才部分支持，低版本会解析失败
跨平台脚本里最稳妥的做法：先用 Files.isWritable(dst.getParent()) 和 Files.exists(dst.getParent()) 做前置校验，比等 copy 报错再处理更可控。
