files.walkfiletree() 清理目录时 delete() 抛 accessdeniedexception，因默认深度优先遍历导致非空目录删除失败，且 windows 下空目录若被占用也会失败；正确做法是在 postvisitdirectory() 中删空目录，并用 previsitdirectory() 跳过 .git 等路径，捕获异常返回 continue 继续遍历。
Files.walkFileTree() 清理目录时，为什么 delete() 总抛 AccessDeniedException
因为 Files.walkFileTree() 默认按深度优先遍历，先访问子目录再访问父目录，而你如果在 visitFile() 里直接调用 file.delete()（或 Files.delete()），会卡在非空目录上——目录不为空时 Files.delete() 必然失败。更关键的是，Windows 下即使目录为空，若其句柄被占用（比如被 IDE、资源管理器或防病毒软件打开），也会触发 AccessDeniedException。
正确做法是把删除逻辑放到 postVisitDirectory() 回调里，等子项全部处理完、目录变空后再删它：
Files.walkFileTree(path, new SimpleFileVisitor<path>() {
@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
// 这里只删文件，不删目录
Files.delete(file);
return FileVisitResult.CONTINUE;
}
@Override
public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException {
if (exc == null) {
Files.delete(dir); // 此时 dir 已空，可安全删除
}
return FileVisitResult.CONTINUE;
}
});
</path>
如何跳过只读文件或受保护路径（如 .git、node_modules）
清理不是无脑删，得有策略。靠 preVisitDirectory() 拦截特定目录是最轻量的方式；它返回 SKIP_SUBTREE 就不会进该目录，也不会触发它的 visitFile() 或 postVisitDirectory()。
常见过滤逻辑：
- 跳过以
.开头的隐藏目录：dir.getFileName().toString().startsWith(".") - 跳过已知大体积干扰项：
"node_modules".equals(dir.getFileName().toString())或".git".equals(...) - 跳过系统保护路径（仅 Windows）：
dir.startsWith(Paths.get(System.getenv("WINDIR")))
注意：不要在 visitFile() 里做路径匹配判断来跳过删除——那只是“删了又跳过”，浪费 I/O；拦截必须发生在进入前。
遇到 IOException 时，继续还是中断？
默认行为是抛异常中断整个遍历。但清理场景下，单个文件权限不足或正被占用很常见，你不希望因此停掉整个任务。
解决方案是在每个回调方法里捕获异常，并返回 CONTINUE：
@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
try {
Files.delete(file);
} catch (IOException e) {
System.err.println("跳过文件: " + file + " (" + e.getMessage() + ")");
}
return FileVisitResult.CONTINUE;
}
@Override
public FileVisitResult postVisitDirectory(Path dir, IOException exc) {
try {
if (exc == null) Files.delete(dir);
} catch (IOException e) {
System.err.println("跳过目录: " + dir + " (" + e.getMessage() + ")");
}
return FileVisitResult.CONTINUE;
}
注意：postVisitDirectory() 的参数 exc 是该目录下某个子项访问失败时传入的异常，不代表目录本身不可删；所以即使 exc != null，只要你想清空目录，仍可尝试 Files.delete(dir)。
用 FileVisitOption.FOLLOW_LINKS 会不会误删符号链接指向的原始内容？
不会。Files.walkFileTree() 遍历时，符号链接本身是作为 Path 节点存在的，visitFile() 处理的是链接文件自身（即那个小文本文件），不是它指向的目标。除非你显式调用 Files.readSymbolicLink() 再手动处理目标，否则不会穿透。
但要注意两点：
- 如果你启用了
FOLLOW_LINKS，那么遍历会进入链接指向的目录树——这可能导致重复清理或跨分区误操作，一般清理场景应禁用它（默认不跟随） - 对符号链接调用
Files.delete()只删链接本身，不影响目标；但若用Files.deleteIfExists()+FOLLOW_LINKS，行为不变，仍是删链接
真正危险的是用 Files.walk()（Stream API）配合 Files.delete() ——它不提供 postVisitDirectory()，无法保证空目录再删，容易崩。
