files.move重命名必须显式指定replace_existing，同目录移动才安全；跨卷会退化为复制+删除，需预检文件系统一致性并校验后再操作。
Files.move 重命名文件必须用 REPLACE_EXISTING
不加 StandardCopyOption.REPLACE_EXISTING，目标文件已存在时直接抛 FileAlreadyExistsException，而不是覆盖——这和直觉相反，但恰恰是安全设计。重命名本质就是“同目录下移动”，源和目标路径的父目录必须一致，否则就不是重命名而是跨目录移动了。
常见错误：
- 只写
Files.move(source, target)，结果目标文件存在就崩，没报错信息里看不出是覆盖问题 - 误以为
REPLACE_EXISTING是默认行为，实际它必须显式传入 - 用
Path.getFileName()提取名字后拼字符串改名，却忘了用Path.getParent()拼回完整路径，导致目标路径变成相对路径或根目录下
跨目录移动要先判断是否同卷，否则性能和可靠性都崩
Java 的 Files.move() 在同一文件系统内是原子重命名（毫秒级），跨文件系统（比如 C: → D: 或本地盘 → NFS）会退化为“复制 + 删除源”，既慢又危险：复制中途失败，源删了新文件没写完，数据就丢了。
正确做法是自己预检：
- 用
FileStore获取源和目标路径的文件系统标识：Files.getFileStore(source).equals(Files.getFileStore(target)) - 或者更轻量：用
source.toRealPath().getRoot().equals(target.toRealPath().getRoot())判断是否同卷（注意toRealPath()会解析符号链接并检查存在性） - 不同卷时，别硬用
Files.move()，改用Files.copy()+Files.delete()组合，并在 copy 后校验Files.size()和Files.getLastModifiedTime()再删源
批量重命名必须构建映射表，不能边遍历边改
直接对 Files.list(dir) 返回的 Stream 调 forEach 执行 Files.move() 极其危险：目录结构实时变化，后续 Stream 元素可能失效或重复，尤其 Windows 下还容易触发句柄冲突。
稳妥流程：
- 先用
Files.list(dir).filter(Files::isRegularFile).map(Path::toAbsolutePath).collect(Collectors.toList())拿到完整、绝对、只读的路径列表 - 按业务规则生成新路径，存进
Map<path path></path>映射表（推荐LinkedHashMap保持顺序） - 遍历映射表前，统一检查每个目标路径是否存在：
Files.exists(target)，存在则跳过或自动追加序号（如"file_1.txt"） - 逐个执行
Files.move(source, target, REPLACE_EXISTING)，捕获IOException并记录失败项，便于回滚
中文路径和非法字符不处理，运行时直接炸
Files.move() 对路径合法性校验极严，遇到 Windows 禁止的字符（: * ? " |）或编码乱码，会立刻抛 InvalidPathException 或 FileSystemException，连异常栈都不一定打全。
关键防御点：
- 用户输入的文件名，必须过一遍
Path.of(name)+toString().indexOfAny(":*?\"|") == -1，或用正则过滤 - 中文路径本身没问题，但 JVM 启动编码必须和系统一致：Windows 中文环境务必加
-Dfile.encoding=UTF-8，否则Paths.get("测试.txt")可能解析成乱码再报错 - 别依赖
Charset.defaultCharset()去猜编码——它在 IDE 和命令行下返回值常不一致，且无法覆盖系统 locale 影响
最易被忽略的是跨卷移动的隐式降级行为：代码里写着 Files.move()，看起来很原子，实际跑在 D 盘到 E 盘时早就变成复制删除了。不预检、不校验、不回滚，批量操作出一次错，现场就不可逆。
