files.copy()抛出nosuchfileexception主因是目标父目录不存在，需先调用files.createdirectories()；源路径错误或大小写不符也会触发该异常。
Files.copy() 为什么抛出 NoSuchFileException？
常见错误是误以为 Files.copy() 能自动创建父目录。它只负责复制文件，不创建目标路径中缺失的任何上级目录。
- 目标路径的父目录不存在时，必须先调用
Files.createDirectories() - 源文件路径写错（比如漏了扩展名或大小写不符），也会触发该异常，尤其在 Linux 环境下
- 使用
StandardCopyOption.REPLACE_EXISTING并不能绕过父目录缺失问题
Path source = Paths.get("data/input.txt");
Path target = Paths.get("backup/2024/output.txt");
// 必须提前确保 backup/2024 存在
Files.createDirectories(target.getParent());
Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING);
如何安全地用 Files.walk() 遍历大目录而不爆栈或卡死？
Files.walk() 默认深度优先且不设限，遇到符号链接循环、超深嵌套或海量小文件时极易 OOM 或响应迟滞。
- 务必用 try-with-resources 包裹返回的
Stream<path></path>，否则底层资源不释放 - 加
.limit(n)或.filter(Files::isRegularFile)缩减处理范围 - 避免在 stream 的
forEach中执行阻塞 I/O（如逐个读取文件内容），改用并行流 + 异步处理更稳妥
try (Stream<Path> paths = Files.walk(Paths.get("logs"), 3)) {
paths.filter(Files::isRegularFile)
.filter(p -> p.toString().endsWith(".log"))
.forEach(System.out::println);
}
Files.readAllBytes() 和 Files.readString() 在中文文本上为何乱码？
这两个方法默认使用 UTF-8 编码读取，但若文件实际是 GBK、ISO-8859-1 或无 BOM 的 UTF-16，就会解码失败。
-
Files.readAllBytes()返回byte[]，本身不涉及编码；乱码发生在后续用错误 Charset 构造 String 时 -
Files.readString()有重载版本支持显式传入Charset，例如Files.readString(path, StandardCharsets.GBK) - 不要依赖系统默认 Charset（
Charset.defaultCharset()），Windows 中常为 GBK，Docker 容器里多是 UTF-8
Files.delete() 和 Files.deleteIfExists() 的关键区别在哪？
核心在于异常语义：前者在路径不存在时抛 NoSuchFileException，后者静默成功——但两者对“非空目录”的行为完全一致：都直接失败，不递归删除。
立即学习“Java免费学习笔记（深入）”；
- 想安全清理一个可能不存在的文件，用
deleteIfExists() - 想明确感知“本该存在却没了”的异常场景（如配置文件被意外删掉），用
delete()并捕获异常 - 要删非空目录，必须手动递归调用
Files.walk()+Files.delete()，或改用第三方库（如 Apache Commons IO）
最易被忽略的是：NIO 的删除操作不可逆，没有回收站，也没有原子性保证——删到一半出错，状态就残缺了。
