Java Files.copy 复制符号链接目标的参数选择

使用 Files.copy(Path, Path, CopyOption...) 时，若希望复制源符号链接最终指向的内容，使用默认行为，不传 NOFOLLOW_LINKS；若希望保留源链接本身，传 LinkOption.NOFOLLOW_LINKS。允许替换已存在目标则另选 StandardCopyOption.REPLACE_EXISTING，它不负责决定源链接是否跟随。

我会先问“交付的是文件内容，还是目录里的链接关系”，再写参数。一个叫 current.txt 的路径，既可能是待打包的真实内容入口，也可能是必须保留的链接配置；只看文件名，无法决定正确结果。下面用一组独立演示文件说明取舍，不声称已经在本机运行。

Java 官方 API：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/Files.html

我会先把内容副本与链接副本分开

假设源目录有 report.txt，current.txt 是指向 report.txt 的符号链接。我的两种目标会写成不同需求：

• 交给只接收普通文件的导出流程：新副本需要保存 report.txt 的内容，之后不再依赖原链接。
• 保留目录结构中的别名关系：新副本仍是一个链接，访问时再解析它保存的路径。

这不是 Java 新版本改变了默认语义，而是两种复制对象本来就不同。给所有复制动作统一添加“看起来更完整”的参数，反而会把需求藏起来。特别是不能把其他 API 的 FOLLOW_LINKS 选项直接搬进 Files.copy；该重载使用 CopyOption，默认就会跟随源链接。

同一组源文件对比两种复制写法

下面的独立示例把两种输出放在同一目录，避免相对链接搬家带来的额外变量。需要文件系统支持符号链接创建，并具备所需权限；不支持时应处理异常，不能把内容复制悄悄当作“保留链接”的成功替代。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.LinkOption;
import java.nio.file.Path;

public class LinkCopyDemo {
    public static void main(String[] args) throws IOException {
        // 使用独立临时目录，避免改动已有业务文件；示例按 JDK 25 编写。
        Path work = Files.createTempDirectory("link-copy-demo-");
        Path data = work.resolve("report.txt");
        Files.writeString(data, "sample report\n");
        Path sourceLink = work.resolve("current.txt");
        // 保存相对路径，源链接与数据文件位于同一目录。
        Files.createSymbolicLink(sourceLink, Path.of("report.txt"));

        Path contentCopy = work.resolve("content-copy.txt");
        Path linkCopy = work.resolve("link-copy.txt");
        // 默认跟随源链接：得到内容副本，不需要 FOLLOW_LINKS 参数。
        Files.copy(sourceLink, contentCopy);
        // 不跟随源链接：在支持符号链接的文件系统上得到链接副本。
        Files.copy(sourceLink, linkCopy, LinkOption.NOFOLLOW_LINKS);

        System.out.println(Files.isSymbolicLink(contentCopy));
        System.out.println(Files.readString(contentCopy));
        System.out.println(Files.isSymbolicLink(linkCopy));
        System.out.println(Files.readSymbolicLink(linkCopy));
        System.out.println("演示目录：" + work);
        // 保留目录供观察；观察结束后仅删除本示例创建的文件及空目录。
    }
}

按示例语义，content-copy.txt 应是普通内容副本；link-copy.txt 应是符号链接，readSymbolicLink 读取的路径为 report.txt。这里提供的是读者可观察的预期，不是测试回执。示例没有读取敏感文件，也没有替换已有目标；遇到 IOException 时由 main 向调用环境报告，不输出“复制成功”。

我会保留“是否链接”和“读取链接保存的路径”两个观察项。只调用 readString 看内容，两种副本都可能显示相同文字，容易掩盖输出类型已经不同。

REPLACE_EXISTING 处理的是目标位置

源路径和目标位置要分别判断。对于通常的不同文件复制，目标已经存在时，默认调用会失败。显式允许 REPLACE_EXISTING 后，如果目标位置是符号链接，被替换的是那个链接目录项，不能把它理解成沿目标链接修改背后的文件。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardCopyOption;

class ReplaceLinkEntry {
    static void copy(Path source, Path existingTargetLink) throws IOException {
        // 调用前应确认业务确实允许替换目标目录项。
        // 若目标是符号链接，替换链接本身，不是沿链接覆盖其指向的文件。
        Files.copy(source, existingTargetLink,
                StandardCopyOption.REPLACE_EXISTING);
    }
}

这个方法片段故意没有自动删除目标或吞掉异常：是否替换，应由业务契约明确决定。若我的要求是“更新原链接指向的内容但保留原链接”，就不会把上面的调用当成同一需求，应另行设计明确的目标文件更新操作。

另外，COPY_ATTRIBUTES 处理属性复制，不是链接选择开关。复制链接时，其属性能否复制由实现决定，该选项可能被忽略。文件复制也不是原子事务：I/O 失败可能留下不完整目标，不能根据“目标路径出现了”判断任务已成功。

换目录保留相对链接时，要重新判断指向

如果把保存 report.txt 的链接复制到另一个目录，链接的相对路径会在新位置参与解析。我最在意的是“保留了链接”与“仍然指向原先那份数据”并非同一个要求。

例如原来的 current.txt 与 report.txt 同目录，新链接位于另一个没有 report.txt 的目录时，保留相对路径不会自动替你搬运真实文件。若那个目录恰好有另一个 report.txt，读取结果还可能来自另一份内容。因此，目录迁移任务需要先确定新的文件布局，再决定保留、重建链接或改为内容副本。

NOFOLLOW_LINKS 也不应被当成覆盖整个路径树的隔离策略。它解决当前复制操作的源链接处理语义；不能仅凭此参数就断言所有父目录都没有链接，或复制对象在并发修改时始终不变。对于受外部修改影响的目录，应按实际文件系统和应用边界另外设计约束。

我会怎样为复制任务选择参数

对内容导出，我倾向于默认跟随源链接并拒绝意外覆盖；对结构迁移，我会先明确链接关系再选 NOFOLLOW_LINKS。两者都不应把一次 copy 调用扩展成目录树备份承诺：源最终指向目录时，单次复制只创建空目录，不递归复制内部条目。

这些取舍依据 JDK 25 的 Files.copy 契约。LinkOption 定义可查看：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/file/LinkOption.html。在不同文件系统上部署时，仍要处理所选选项、符号链接支持与 I/O 错误。

常见问题

想复制真实内容，需要先 readSymbolicLink 再手动拼接吗？

通常不需要，Path到Path复制默认跟随源符号链接。手动解析会额外引入相对路径与多级链接处理问题。

NOFOLLOW_LINKS 与 REPLACE_EXISTING 可以一起用吗？

可以组合：前者选择复制源链接本身，后者允许替换目标位置。是否符合需求仍取决于你要保留的对象。

源链接失效时为什么默认复制失败？

复制内容需要可解析的源目标；若需求是保留链接本身，应选择不跟随，并满足文件系统和权限条件。