Files.walk默认不跟随符号链接且不避开挂载点，遍历时需显式检查文件系统、过滤临时文件、用deleteIfExists安全删除，避免parallel()，慎处理被占用文件。
Files.walk 会跳过符号链接，但默认不递归进入挂载点
Java 的 Files.walk 默认行为是「不跟随符号链接」，也不会自动避开其他文件系统挂载点（比如 /mnt、/media 下的外部磁盘）。如果你的目标目录里有挂载点，而你又没加限制，遍历可能卡住、抛 IOException，甚至误删外接设备里的同名临时文件。
实操建议：
- 用
Files.walk(path, FileVisitOption.FOLLOW_LINKS)显式控制是否跟进符号链接——多数情况应避免，除非你明确知道链接目标安全 - 在遍历时检查每个
Path的文件系统：用path.getFileSystem() == root.getFileSystem()过滤跨文件系统的子路径 - 加 try-catch 包裹单次访问，避免一个权限错误导致整个遍历中断
匹配 .tmp、~、.swp 等临时文件要小心 glob 模式和大小写
Files.walk 本身不提供文件名过滤，得靠 Stream.filter 配合 Path.getFileName().toString()。但这里容易踩两个坑：一是 Windows 下临时文件可能叫 file.tmp 或 FILE.TMP；二是编辑器生成的备份文件如 .foo.swp 是隐藏文件，Linux/macOS 下以 . 开头，Files.isHidden() 可靠，但不能只依赖它——有些临时文件并不隐藏。
实操建议：
- 用
String.toLowerCase()统一转小写再匹配，覆盖大小写变体 - 用正则
Pattern.compile("(?i)\.(tmp|swp|swo|un~)|~$|\.backup$")比多个endsWith更稳 - 排除目录：确保
Files.isRegularFile(p)为 true，否则可能误删空目录（虽然Files.delete对目录会直接抛异常）
删除前必须用 Files.deleteIfExists 而不是 Files.delete
Files.delete(path) 在文件不存在或权限不足时直接抛 NoSuchFileException 或 AccessDeniedException，导致 stream 中断；而 Files.deleteIfExists(path) 安全得多——它返回 boolean，失败也不抛异常。这对批量清理非常关键。
实操建议：
- 永远优先用
Files.deleteIfExists(p)，配合日志输出结果（比如System.err.println("deleted: " + p)） - 如果需要区分“删成功”和“本来就没有”，可先调
Files.exists(p)，但注意并发场景下存在竞态——一般没必要 - 不要在 filter 里删文件，应在
forEach或peek中执行删除动作，避免 stream 短路或并行流中状态混乱
并行遍历（parallel()）在删除时反而更慢且风险更高
有人觉得加 .parallel() 能加速删除，实际几乎总是适得其反：磁盘 I/O 是瓶颈，多线程争抢文件句柄和磁盘队列，还可能触发同一目录下多个线程同时尝试 delete，造成 DirectoryNotEmptyException（尤其在删完子文件后立刻删父目录时）。
实操建议：
- 彻底放弃
Files.walk(...).parallel()用于删除场景 - 若目录极深、极宽（比如数万级子目录），考虑用
SimpleFileVisitor手动递归，可控性更强，还能在postVisitDirectory中安全删空目录 - 真正需要提速？用
find /path -name "*.tmp" -delete（Linux/macOS）或forfiles（Windows）这类原生工具，比 JVM 层遍历快一个数量级
最常被忽略的一点：临时文件可能被进程占用（比如 IDE 正在写 .swp），此时 deleteIfExists 会静默失败。如果你发现某些文件总删不掉，别急着重试，先检查是否被锁——Java 没法跨平台强制解锁，只能提示用户关闭相关程序。
