Files.walk()默认深度优先且不依赖调用栈递归，不会引发StackOverflowError；maxDepth控制遍历层级数，用于业务过滤而非防栈溢出，如walk(path, 1)仅访问根及其直接子项。
Files.walk() 本身不依赖方法调用栈递归，所以根本不会因目录深度引发 StackOverflowError。所谓“栈变量溢出”在这里是误用概念——真正风险来自传统 File.listFiles() 递归实现，而非 Files.walk()。
maxDepth 的真实作用：控制遍历广度，不是防栈溢出
maxDepth 参数限制的是从起始路径向下展开的**层级数**，例如：
-
Files.walk(path, 1)：只访问path自身及其直接子项（不进子目录的子目录）； -
Files.walk(path, 0)：仅返回path这一个元素（哪怕它是目录）； - 省略
maxDepth（即单参数形式）：默认无深度限制，但仍是迭代式遍历，内存中维护的是待处理路径队列，非调用栈。
为什么它常被误认为“防栈溢出”？
因为开发者常把 Files.walk() 当作传统递归的替代方案，而旧写法确实会爆栈。实际是：换用 walk 就已规避栈溢出，maxDepth 只是额外的业务过滤手段。它能：
- 减少不必要的子树打开（如跳过
/proc、/sys下海量虚拟文件）； - 避免因符号链接循环导致的无限路径生成（配合
FileVisitOption.FOLLOW_LINKS时尤其关键）； - 在搜索类场景中提前收口，提升响应速度（比如只查两级内配置文件）。
真正需要防御的“溢出”其实是资源耗尽
即使不爆栈，无限制遍历仍可能引发问题：
-
句柄耗尽：Linux 默认进程最多打开 1024 文件描述符，
walk在遍历大目录时会批量打开子目录句柄； -
内存缓存压力：虽然流式处理，但若中间操作（如
.map(...).collect(...)）全量加载，仍可能 OOM； -
IO 阻塞雪崩：并发流（
parallel()）未限速时，大量并发 stat 调用拖垮存储子系统。
此时 maxDepth 是简单有效的第一道防线，但需配合其他措施：
- 用
try-with-resources确保 Stream 关闭； - 对敏感路径（如
/dev,/proc）做前置 skip； - 捕获
AccessDeniedException并跳过，而非中断整个流。
对比：walk vs walkFileTree 中 maxDepth 的差异
Files.walk(start, maxDepth) 是“硬截断”——到达指定深度后，不再将该层目录的子项加入队列；Files.walkFileTree(start, options, maxDepth, visitor) 则更精细：在 preVisitDirectory 回调中可动态决定是否 SKIP_SUBTREE，还能统一处理异常、记录日志、统计跳过数等。
若需健壮性 + 可观测性，后者更适合生产环境；若只是快速过滤浅层文件，walk 加 maxDepth 更简洁。
