Files.isWritable()常返回false却实际能写入，因其仅检查文件系统权限位，不验证磁盘空间、父目录可写性、UAC、SELinux等真实限制，故不可靠；应直接尝试写入并捕获异常。
Files.isWritable() 为什么经常返回 false 却实际能写入
Files.isWritable() 判定的是文件系统层面的权限位（POSIX 权限或 Windows ACL 中的“写入”标志），不是运行时实际能否成功写入。它不检查磁盘空间、父目录可写性、挂载只读、SELinux/AppArmor 策略、容器内绑定挂载限制等真实阻碍因素。常见现象是：调用 Files.isWritable(path) 返回 false，但后续 Files.write() 却成功；反之，返回 true 后却抛出 AccessDeniedException 或 IOException。
根本原因在于该方法只读取文件/目录的元数据权限位，而 Java 不会模拟写入行为来验证——它连父目录是否可写都不看。所以它更像一个“粗略提示”，不能替代真实写入尝试或更细粒度的检查。
真正需要检查什么：路径存在性、父目录可写性、文件是否为目录
若目标是避免写入失败，重点不该是 Files.isWritable()，而是以下三项：
- 用
Files.exists(path)确认路径存在；若不存在，需检查其父目录：Files.isDirectory(path.getParent())且Files.isWritable(path.getParent())—— 因为创建新文件依赖父目录可写 - 若
path已存在，先用Files.isRegularFile(path)排除它是目录的情况（向目录调用Files.write()必然失败） - Windows 下还需注意：某些路径（如
C:\Program Files\）即使权限位允许，UAC 也会拦截写入，Files.isWritable()完全无法反映这点
更可靠的替代方案：用 Files.write() 的异常做判断
与其预检，不如直接写，并捕获明确异常。这是最贴近真实行为的做法：
try {
Files.write(path, data, StandardOpenOption.CREATE, StandardOpenOption.WRITE);
} catch (AccessDeniedException e) {
// 权限不足（含父目录不可写、只读文件系统、UAC 拦截等）
} catch (NoSuchFileException e) {
// 父目录不存在
} catch (IOException e) {
// 其他 I/O 问题（磁盘满、句柄耗尽等）
}
优势在于：覆盖所有 Files.isWritable() 漏掉的场景，且无竞态条件（预检后权限可能被其他进程修改）。
如果必须预检，可组合使用：
-
Files.exists(path.getParent()) && Files.isWritable(path.getParent())（确保能创建文件） -
!Files.exists(path) || (Files.isRegularFile(path) && Files.isWritable(path))（确保能覆盖或追加）
Windows 上的特殊陷阱：隐藏的只读属性和重定向
Windows 文件可能被标记为“只读”（DOS_READONLY），但该属性不影响写入——它只是个提示。此时 Files.isWritable() 可能返回 false，但写入仍成功。更麻烦的是虚拟化重定向：普通用户往 C:\Program Files\app\config.txt 写，系统悄悄重定向到 %LOCALAPPDATA%\VirtualStore\...，而 Files.isWritable() 查的仍是原始路径，结果毫无意义。
因此在 Windows 环境下，不要信任 Files.isWritable() 的返回值，尤其当路径位于受保护目录时。真实写入 + 异常处理仍是唯一可靠路径。
真正难处理的从来不是“能不能写”，而是“写到哪去了”和“为什么拒绝——是权限？路径？还是策略？”这些问题，Files.isWritable() 一个都答不上来。
