filesystemloopexception是继承自runtimeexception的非受检异常，遍历遇软链接循环时jvm直接抛出，编译器不强制处理；应禁用follow_links、用filevisitor主动检测重复路径或提前过滤软链接来规避。
Java中FileSystemLoopException是Files.walk()等遍历方法在遇到符号链接（软链接）构成循环路径时抛出的运行时异常，它不属于受检异常（checked exception），无法用try-catch强制捕获，也不能在方法签名中声明throws。所谓“受检捕获”本身是个误解——它不可被编译器强制要求处理。
为什么FileSystemLoopException不能被受检捕获
FileSystemLoopException继承自RuntimeException，属于非受检异常。JVM在遍历文件系统发现软链接闭环（如A → B → A）时直接抛出，不经过编译期检查。试图用catch (FileSystemLoopException e)虽语法合法，但不会改变其非受检本质，也不会让编译器“要求你处理它”。
真正有效的应对方式
与其尝试“捕获”，不如从设计上规避或优雅处理：
-
禁用符号链接跟随：调用
Files.walk(path, FileVisitOption.FOLLOW_LINKS)时**不要传入**FOLLOW_LINKS。默认不跟随软链接，自然不会触发循环检测。 -
使用FileVisitor手动控制：通过
Files.walkFileTree()配合自定义SimpleFileVisitor，在preVisitDirectory中检查是否已访问过该真实路径（可用Files.isSameFile或缓存realPath.toAbsolutePath().normalize()），主动跳过重复入口。 -
提前过滤软链接：遍历时用
Files.isSymbolicLink(entry)识别软链接，按需跳过或单独记录，避免进入可疑路径。
常见误操作与澄清
有人试图用try-catch包裹walk()并期望“捕获后继续”，但实际一旦抛出FileSystemLoopException，整个流（Stream）会立即终止，后续元素不再处理——它不是可恢复的异常。也没有标准API能“跳过该循环点继续遍历”。强行捕获仅能用于日志或降级逻辑（比如改用非递归方式重试），不能修复遍历本身。
替代方案推荐
若业务必须安全遍历含软链接的目录：
- 优先用
Files.walkFileTree()+FileVisitor，完全掌控访问逻辑； - 对关键路径预先调用
Files.isSymbolicLink()和Files.readSymbolicLink()做拓扑分析； - 考虑引入第三方库如Apache Commons IO的
FileUtils.iterateFiles()（注意其默认也不跟随软链接）。
不复杂但容易忽略：软链接循环不是bug，而是文件系统特性；Java的处理逻辑是“不跟就不环”，而非“遇环再救”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
