Paths.get仅创建Path对象，不执行I/O或遍历；真正递归需用Files.walk或Files.walkFileTree，后者支持TERMINATE终止、异常处理及符号链接控制。
Paths.get 为什么不能直接递归遍历目录
Paths.get 只是构造一个 Path 对象，不涉及 I/O，更不会访问文件系统。它不提供遍历能力，常见误用是以为调用 Paths.get("dir").toFile().listFiles() 就算用了 NIO.2——其实这已退回旧 IO，且 toFile() 在符号链接、权限受限路径下易抛 UnsupportedOperationException 或静默失败。
真正递归操作必须交由 Files 工具类，它封装了基于 FileSystemProvider 的底层访问逻辑，支持符号链接处理、访问控制检查和异常分类。
Files.walk 的默认行为与陷阱
Files.walk 是最常用的递归入口，但默认使用无限深度（Integer.MAX_VALUE）且不跳过循环符号链接——一旦遇到自引用软链或挂载点交叉，会陷入死循环或抛 FileSystemLoopException。
实操建议：
- 始终显式指定最大深度，如
Files.walk(path, 3)控制只查三层子目录 - 若需遍历全部但防环，改用
Files.walk(path, FileVisitOption.FOLLOW_LINKS)并配合自定义SimpleFileVisitor捕获FileSystemLoopException - 注意返回的
Stream<path></path>是延迟求值的，未forEach或collect前不触发实际读取——这点常被忽略，导致误判性能
Files.find 与 Files.walk 的性能差异在哪
Files.find 和 Files.walk 底层都走同一遍历引擎，区别在于过滤时机：find 在访问每个节点时立即应用谓词（BiPredicate），而 walk 返回完整流后再用 filter。这意味着：
- 对大目录树且匹配项靠前的场景，
find可早停，减少stat系统调用次数 -
find的谓词接收Path和BasicFileAttributes，可免去额外Files.readAttributes()调用 - 但
find不支持按深度分组或中途修改遍历策略，灵活性不如walk+ 自定义 visitor
例如查找所有 `.log` 文件并跳过 `target/` 目录：用 find 写成 Files.find(root, Integer.MAX_VALUE, (p, a) -> p.toString().endsWith(".log") && !p.toString().contains("target"))，比 walk 后 filter 更省系统调用。
如何安全终止 long-running walk 操作
Files.walk 返回的 Stream 不支持外部中断，一旦开始遍历就无法优雅停止。强行 close 流或中断线程可能导致底层 DirectoryStream 泄漏，后续对同一路径的操作可能卡住。
正确做法是用 Files.walkFileTree 配合自定义 SimpleFileVisitor：
Files.walkFileTree(path, new SimpleFileVisitor<Path>() {
@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
if (Thread.currentThread().isInterrupted()) {
return FileVisitResult.TERMINATE;
}
// 处理文件...
return FileVisitResult.CONTINUE;
}
});
关键点：
-
TERMINATE会立即退出整个遍历，释放所有打开的目录句柄 - 不要在 visitor 中抛异常来中断——除非你明确要传播
IOException - 如果需要响应超时，用
CompletableFuture包裹并设置get(timeout, unit)，而非依赖流的 close
递归操作真正的复杂点不在 API 调用本身，而在对符号链接拓扑、权限边界和资源生命周期的隐式假设——这些不会报错，但会让行为在不同环境里悄然变化。
