怎么在 Java 中使用 Files.copy() 快速实现文件或流的复制

怎么在 Ja va 中使用 Files.copy() 快速实现文件或流的复制

说到文件复制，Files.copy() 无疑是 Ja va 开发者工具箱里的首选。它简洁、高效，但用起来也并非毫无“脾气”。默认不覆盖文件，需要显式传入 StandardCopyOption.REPLACE_EXISTING；复制 InputStream 时，必须用 try-with-resources 确保流不被提前消费；处理大文件时，得留意返回值并考虑手动缓冲；至于保留文件属性，那仅限于同文件系统，并且需要明确指定 COPY_ATTRIBUTES 等选项。下面就来逐一拆解这些常见的“坑”。

Files.copy() 复制文件时抛出 FileAlreadyExistsException 怎么办

遇到这个异常先别慌，这通常不是代码有 bug，而是 Files.copy() 设计上的安全策略在起作用。它的默认行为就是拒绝覆盖已存在的目标文件，直接抛出异常，以此来防止数据被意外覆盖。

解决方法很直接：在调用时，显式传入 StandardCopyOption.REPLACE_EXISTING 选项，明确告知系统你的覆盖意图。

Files.copy(sourcePath, targetPath, StandardCopyOption.REPLACE_EXISTING);

• 如果不加这个选项，哪怕目标文件是空的或者只读的，FileAlreadyExistsException 也会如期而至。
• 这里有个细节需要注意：如果目标路径指向的是一个已存在的目录，而不是文件，那么即使你传入了 REPLACE_EXISTING，依然会抛出同样的异常。原因很简单，目录不能被直接“覆盖”，通常需要先删除再创建。
• 另外，在 Windows 环境下，如果目标文件正被其他进程占用，即使使用了覆盖选项，也可能触发 AccessDeniedException。稳妥的做法是采用“临时文件 + 原子重命名”的策略来绕过这个问题。

用 Files.copy() 把 InputStream 复制到文件，为什么写入内容为空

这个问题困扰过不少人。常见原因不外乎是忘了关闭输入流，或者漏掉了覆盖选项。但还有一个更隐蔽的陷阱：你可能正在使用 Files.copy(InputStream, Path) 这个重载方法，却没有意识到，它内部不会自动帮你关闭传入的 InputStream，而且如果这个流已经被读取过一部分，复制就会从当前位置开始，导致内容缺失。

正确的姿势是确保传入的流是可读的、未被关闭的，并且位置处于起始点：

try (InputStream is = new FileInputStream(sourceFile)) {
    Files.copy(is, targetPath, StandardCopyOption.REPLACE_EXISTING);
}

• 务必使用 try-with-resources 语句来管理 InputStream，这是保证资源被正确释放、避免后续复用失败的关键。
• 千万不要传入一个已经调用过 read() 或 skip() 方法的流，因为 Files.copy() 不会去重置流的位置。
• 从实现原理上看，这个重载方法底层会调用 Channels.newChannel() 和 transferTo()，在操作系统支持的情况下，能实现高效的零拷贝传输。不过，如果传入的是 ByteArrayInputStream，它会退化为普通的字节循环复制，性能上就没有优势了。

复制大文件时卡住或内存暴涨，是不是 Files.copy() 有 Bug

这还真不是 Files.copy() 的 Bug，而是其底层机制与特定环境相互作用的结果。方法本身并不分配大缓冲区，它依赖于像 FileChannel.transferTo 这样的通道传输技术。问题在于，某些 Linux 内核版本对单次 transferTo 调用有大小限制（例如 2GB），对于超大的文件，复制操作会被拆分成多次进行。如果其中某次调用失败（比如磁盘空间不足），整个过程不会自动回滚，也不会抛出明确的异常，最终可能导致目标文件被静默截断。

• 务必检查返回值：Files.copy() 方法会返回实际复制的字节数。这是一个非常重要的信号，必须将其与源文件的大小进行比对。如果两者不符，就说明复制过程出了问题。
• 尽量避免在 NFS 或 CIFS 这类网络文件系统上依赖 transferTo 的零拷贝特性。部分网络文件系统并不支持高效的原生传输，反而会降级为用户态的缓冲复制，导致性能下降。
• 对于体积达到几 GB 甚至更大的文件，更稳妥的方案是采用手动缓冲复制（比如使用 8KB 的 byte[] 数组进行循环读写）。这种方式虽然代码稍多，但便于加入进度监控和中断逻辑，可控性更强。

Files.copy() 能否保留文件权限和时间戳

答案是肯定的，但附加条件不少。这个功能主要适用于同一文件系统内的普通文件复制，并且需要你额外指定相应的选项。

如果想保留文件的最后修改时间，需要使用 StandardCopyOption.COPY_ATTRIBUTES 选项。若要保留所有属性，包括权限、所有者和访问控制列表（ACL），则需要配合 PosixFilePermissions 或 FileOwnerAttributeView 等 API。不过，一旦涉及跨文件系统复制，或者在 Windows 系统上，很多属性可能无法被完整保留。

Files.copy(sourcePath, targetPath,
    StandardCopyOption.REPLACE_EXISTING,
    StandardCopyOption.COPY_ATTRIBUTES);

• 在 Linux 系统上，COPY_ATTRIBUTES 通常可以保留文件的修改时间（mtime）和访问时间（atime），但文件状态变更时间（ctime）总是会被重置为复制操作发生的时间。
• 在 Windows 系统上，这个选项可能保留文件的“最后写入时间”，但对于 NTFS 权限（ACL）则无能为力，除非你额外调用 Files.setPosixFilePermissions() 或使用 AclFileAttributeView 进行手动设置。
• 最关键的一点是：如果复制源是一个 InputStream（而不是一个 Path），那么 COPY_ATTRIBUTES 选项将完全失效，因为流对象本身并不携带任何文件元数据。

说到底，Files.copy() 并非万能。它的语义和功能深度绑定于 Path 对象和底层文件系统的具体能力。一旦场景变得复杂，比如涉及网络存储、容器挂载卷、FUSE 文件系统，或者特殊的权限模型时，最可靠的做法往往是退回到手动控制数据流的方式，亲自处理异常边界和保证操作的原子性。