File类路径构造易出错因不标准化路径,跨平台行为不一致;exists()和isFile()返回false常因权限不足而非文件不存在;mkdirs()静默失败;toURI()弃用因编码不合规。
因为 File 构造函数对路径字符串不做标准化处理,斜杠方向、冗余分隔符、相对路径解析全靠操作系统行为,跨平台时极易失效。比如在 Windows 上写 "src\\main\\resources" 没问题,但拼成 "src//main/resources" 或传入 "./config/../conf/app.properties",File 不会自动规整,后续 exists()、getCanonicalPath() 可能返回意外结果。
Paths.get(...).toFile() 替代直接 new File(...)
File.separator 或 Paths.get(a, b, c),别硬写 "a/b/c"
new File(path).getCanonicalFile() 再判断或使用,否则符号链接、大小写、多余 .. 会导致误判这两个方法返回 false 不一定代表文件不存在——更常见的是权限不足、路径含非法字符、父目录不可读,或当前用户无权访问该挂载点(如 Docker 容器内访问宿主机路径)。尤其在 Linux 上,如果 /data/logs 目录存在但权限是 drwx------,且当前 Java 进程用户不是属主,new File("/data/logs/app.log").exists() 就会返回 false,哪怕文件物理上存在。
file.getParentFile().canRead()
Files.isReadable(file.toPath()) 替代 file.canRead()(后者在某些 JVM 版本有 bug)exists() 做业务逻辑分支,应结合 Files.probeContentType(file.toPath()) 或异常捕获来确认状态File.mkdirs() 返回 boolean,失败时静默返回 false,不抛异常。常见失败场景包括:父目录是只读文件(不是目录)、磁盘满、SELinux 限制、NTFS 权限未继承。很多老代码只写 if (!dir.mkdirs()) throw new RuntimeException("创建失败"),但没打印具体路径和错误上下文,排查时只能盲猜。
Files.createDirectories(dir.toPath()),失败直接抛 IOException,带明确原因File,请补全诊断信息:if (!dir.mkdirs()) {
System.err.println("mkdirs failed on: " + dir.getAbsolutePath());
System.err.println("Parent exists: " + dir.getParentFile().exists());
System.err.println("Parent writable: " + dir.getParentFile(
).canWrite());
}mkdirs() 返回 true,也不能保证后续写入成功——目录可能被其他进程立即删掉或改权限JDK 7 引入 Paths 和 Files 后,File.toURI() 被标记为 @Deprecated,但不是因为功能错误,而是它生成的 URI 缺少对空格、中文等字符的正确编码(例如路径含中文时转成 file:///C:/测试.txt,实际应为 file:///C:/%E6%B5%8B%E8%AF%95.txt),导致用该 URI 构造 URL 或传给某些库(如 Apache Commons IO)时解析失败。
file.toPath().toUri(),它会做 RFC 3986 编码Class.getResource("/path.txt").toURI(),而非先获取 File 再转 URItoURI().toString() 结果手动调用 URLEncoder.encode(..., "UTF-8") 是错的——URI 编码规则和 URL 不同,应避免自行处理new File("config.properties").exists(),背后已牵涉到 VFS 层、ACL 检查、路径规范化、编码转换四层逻辑。别迷信文档里的“应该工作”,每次路径操作后都该用 getCanonicalPath() 和 canRead() 验证真实状态。