files.deleteifexists() 不抛 filenotfoundexception 是因先检查存在性再删除，不存在时直接返回 false；但仍会抛 directorynotemptyexception、accessdeniedexception 等 ioexception 子类。
Files.deleteIfExists 为什么不会抛出 FileNotFoundException
Files.deleteIfExists() 的设计目标就是“不因文件不存在而中断流程”。它在底层先检查路径是否存在，再决定是否执行删除；如果路径根本不存在，直接返回 false，不走删除逻辑，自然不会触发 FileNotFoundException 或 NoSuchFileException。这和 Files.delete() 形成关键区别——后者只要路径不存在就一定抛 IOException 子类。
哪些异常它依然会抛出，不能忽略
虽然绕过了“文件不存在”类异常，但以下情况仍会抛出 IOException（必须 try-catch）：
-
DirectoryNotEmptyException：试图删除非空目录（哪怕只含一个隐藏文件） -
AccessDeniedException：Windows 下文件被设为只读、或当前进程无写权限（如运行在受限服务账户下） -
FileSystemException：文件正被其他进程占用（例如 Excel 打开着 .xlsx，或 IDE 正在索引该文件） -
SecurityException：安全管理器显式拒绝删除操作（极少见，多见于沙箱环境）
也就是说，deleteIfExists() 只帮你屏蔽了“不存在”这一种失败原因，其余真实错误照常暴露——这不是缺陷，而是让你能区分“本来就没有”和“有但删不了”。
配合 Files.walkFileTree 删除非空目录的惯用写法
想删整个目录树？别自己递归调用 deleteIfExists()，容易漏掉子目录或顺序错乱。标准做法是用 Files.walkFileTree() 先遍历删文件，再删空目录：
Path root = Paths.get("target/dir");
try {
Files.walkFileTree(root, new SimpleFileVisitor<path>() {
@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
Files.delete(file); // 这里用 delete()，因为已知文件存在；失败会立即抛异常
return FileVisitResult.CONTINUE;
}
@Override
public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException {
Files.delete(dir); // 空目录才到这步，用 delete() 更准确
return FileVisitResult.CONTINUE;
}
});
} catch (IOException e) {
// 处理遍历或删除过程中的任意 IO 错误
}
</path>
注意：visitFile 里用的是 Files.delete() 而非 deleteIfExists()，因为 walk 已确保路径存在；而最后清理根目录时，可再补一句 Files.deleteIfExists(root) 避免根目录恰好为空却因异常未删净的问题。
实际使用中最容易被忽略的权限与状态检查点
很多线上故障不是代码逻辑错，而是没预判运行时环境：
- Windows 下务必检查
Files.getAttribute(path, "dos:readonly")，只读属性不手动清除会导致AccessDeniedException - Linux/macOS 注意父目录的写权限（删除文件依赖父目录的写权，而非文件自身权限）
- 不要假设
deleteIfExists()返回true就代表磁盘上立刻不可见——某些文件系统或杀毒软件可能延迟同步，后续createFile()仍可能报冲突 - 若需原子性保障（比如“删旧配置 → 写新配置”不能中间断档），应改用
Files.move()配合临时文件，而非依赖删除结果
