Files.walk默认是深度优先。它底层使用递归式栈遍历，路径按进入子目录的顺序逐层深入，如/a/b/c.txt一定在/a/d.txt之前被访问，前提是未指定maxDepth且不干预流顺序。
Files.walk 默认是深度优先还是广度优先？
默认是深度优先。Java 8 的 Files.walk 底层使用递归式栈遍历（非显式队列），路径按进入子目录的顺序逐层深入，比如 /a/b/c.txt 一定在 /a/d.txt 之前被访问——前提是未指定 maxDepth 且不干预流顺序。
但要注意：这个“深度优先”仅体现在文件系统遍历逻辑上，Stream 本身是惰性求值，一旦你调用 .sorted()、.collect(Collectors.toList()) 或任何触发全量消费的操作，就可能破坏原始访问顺序；更隐蔽的是，某些终端操作（如 parallelStream()）会彻底打乱顺序。
如何安全地边遍历边累加文件大小？
不能直接对 Files.walk(path) 流做 .mapToLong(…).sum()，因为 Files.walk 返回的流是“可关闭”的，必须显式处理异常并确保资源释放；同时，遇到权限不足或断开的符号链接时，Files.walk 默认抛出 IOException 并终止整个流。
- 用
try-with-resources包裹流，否则可能泄漏文件句柄（尤其在 Windows 上） - 改用
Files.walk(path, FileVisitOption.FOLLOW_LINKS)显式控制链接行为 - 用
.onClose(() -> {})不起作用——必须用 try-with-resources - 统计前先过滤掉目录：
.filter(Files::isRegularFile)，否则Files.size(dir)会抛IOException
正确写法示例：
long total = 0;
try (Stream<Path> stream = Files.walk(startPath, FileVisitOption.FOLLOW_LINKS)) {
total = stream
.filter(Files::isRegularFile)
.mapToLong(p -> {
try {
return Files.size(p);
} catch (IOException e) {
return 0; // 或记录警告，不能让单个文件失败中断整个统计
}
})
.sum();
}为什么有时看到的遍历顺序像广度优先？
常见于以下两种情况：
- 你在 IDE 或命令行里用
Files.walk(path).forEach(System.out::println)，但输出被缓冲或重排了——实际流中仍是深度优先，只是终端显示延迟造成错觉 - 你用了
Files.walk(path, maxDepth)且maxDepth == 1，这时只列出一级子项，看起来像“平铺”，但这不是广度优先算法，只是提前截断 - 你把流转成
List后再打印，而某些文件系统（如 APFS）返回的目录项本身无序，导致子目录未必按字母/创建时间排列，进一步混淆判断
验证真实顺序最简单的方法：在 forEach 里打印每项的深度（path.getNameCount() - startPath.getNameCount()），你会看到 1→2→3→2→1 这类典型的深度优先跳变。
大目录下性能和内存需要注意什么？
Files.walk 是懒加载，不会一次性读入所有路径，所以内存占用相对可控；但如果你在 map 阶段频繁调用 Files.size()，每次都是系统调用，I/O 成为瓶颈，比单纯遍历慢一个数量级。
- 避免重复解析同一路径：不要在 lambda 里反复调用
p.getParent()或p.getFileName()，提取到变量里复用 - 如果只需要总大小，不用路径信息，考虑用
SimpleFileVisitor手动遍历——它能跳过 Stream 的对象包装开销 - Windows 上注意：NTFS 硬链接和重解析点可能造成重复计数，需用
Files.getAttribute(p, "basic:fileKey")去重（但代价高，慎用）
真正容易被忽略的是符号链接循环：即使加了 FOLLOW_LINKS，Files.walk 也不会自动检测循环引用，遇到 /a → /b 且 /b → /a 会无限递归直到栈溢出——生产环境务必限制 maxDepth 或改用 Files.walkFileTree 配合自定义 FileVisitor 做循环检测。
