File对象仅抽象路径而非文件内容，无读写方法，需配合FileInputStream等类；创建删除需显式调用并检查boolean返回值；listFiles()返回null可能因路径不存在、非目录或无读权限；推荐迁移到Paths/Files。
File对象不等于文件内容，只是路径的抽象
很多人一用 File 就想读写数据，结果调用 file.read() 报错——File 类本身没有读写方法。它只封装路径字符串、提供元信息判断和简单 I/O 前置操作，真正读写得靠 FileInputStream、Files（Java 7+）或 Scanner 等配套类。
容易踩的坑：
-
new File("data.txt")不会创建文件，只是建了个对象；file.exists()返回false很正常 -
file.getParentFile()可能返回null（比如路径是"abc.txt"，没目录层级） - 路径分隔符别硬写
"\\"或"/"，用File.separator或直接传字符串给构造函数（JVM 自动适配）
创建/删除文件和目录必须显式调用对应方法
File 的创建和删除都是“一步触发”，没有隐式行为。而且失败不抛异常，只返回 boolean 结果——这是老 API 的典型设计，必须手动检查返回值。
File dir = new File("mydir");
if (!dir.exists()) {
boolean created = dir.mkdir(); // 创建单层目录
if (!created) {
System.err.println("mkdir failed: " + dir);
}
}
File file = new File("test.txt");
if (!file.exists()) {
try {
boolean created = file.createNewFile(); // 创建空文件
if (!created) {
System.err.println("createNewFile returned false");
}
} catch (IOException e) {
System.err.println("IO error: " + e.getMessage());
}
}
注意点：
立即学习“Java免费学习笔记（深入）”；
-
mkdir()不支持创建嵌套路径（如"a/b/c"），要用mkdirs() -
createNewFile()在文件已存在时返回false，不是异常 -
delete()对非空目录直接返回false，不会递归删；要删整个目录树得自己遍历
listFiles() 返回 null 的真实原因
file.listFiles() 返回 null 并不总代表“没文件”，而是三种情况之一：路径不存在、不是目录、没有读权限。这个 null 容易引发 NullPointerException，但文档里写得非常隐晦。
安全写法示例：
File dir = new File("/path/to/dir");
File[] files = dir.listFiles();
if (files == null) {
// 别急着报错，先确认原因
if (!dir.exists()) {
System.err.println("Path does not exist");
} else if (!dir.isDirectory()) {
System.err.println("Not a directory");
} else if (!dir.canRead()) {
System.err.println("No read permission");
}
return;
}
// 此时 files 是合法数组（可能长度为 0）
for (File f : files) {
System.out.println(f.getName());
}
补充说明：
-
list()返回String[]，只含名字，不带路径，适合轻量遍历 -
listFiles(FileFilter)可过滤，比如只取.log文件，但注意FileFilter是 Java 7 之前的老接口，现在更推荐Files.walk()+Stream - Windows 下对长路径或特殊字符（如
CON、AUX）可能静默失败，listFiles()返回null
File 与 Paths/Files 混用时的常见误判
Java 7 引入 java.nio.file 后，File 就逐渐退居二线。但很多旧代码还在用，新代码又常混用，导致路径语义错乱。
关键差异：
-
new File("a/b").toPath()和Paths.get("a/b")表面等价，但toPath()返回的Path是sun.nio.fs.WindowsPath（或对应平台实现），而Paths.get()是标准工厂方式，更可靠 -
file.toURI()在含空格路径下可能生成非法 URI（未编码），应改用file.toPath().toUri() -
Files.exists(file.toPath())比file.exists()更准确：后者在某些 JVM 实现中对符号链接处理不一致
建议迁移路径判断逻辑到 Files，例如：
Path p = Paths.get("config.json");
if (Files.isRegularFile(p) && Files.isReadable(p)) {
String content = Files.readString(p, StandardCharsets.UTF_8);
}
老 File 类在 Java 17+ 已被标记为“legacy”，新项目尽量避免裸用，尤其涉及路径解析、符号链接、原子移动等场景。
