File类仅操作文件路径和元信息，不提供读写功能；读写需用IO流或Files工具类，后者更安全简洁，推荐JDK 7+中以Path配合Files替代File。
File类不能读写文件，只是操作路径和元信息
很多人一上来就用 File 类尝试调用 read() 或 write()，结果发现根本没有这些方法——File 本身不处理 I/O，它只代表一个路径（可能是不存在的），负责判断是否存在、是否为目录、能否读写、重命名、删除等。真正读写得靠 FileInputStream、FileOutputStream、FileReader、FileWriter，或者更现代的 Files 工具类。
常见错误现象：file.read() cannot be resolved、NullPointerException（因 File 对象没关联实际内容）。
- 用
File判断路径合法性：file.exists()、file.isDirectory()、file.canWrite() - 创建目录链要用
file.mkdirs()（不是mkdir()，后者只建最后一级） - 删除非空目录需递归：先删子项，再调
file.delete() - 路径分隔符别硬写
"\"或"/"，用File.separator或直接传字符串给File构造函数（它内部自动适配）
用Files工具类替代File做增删改查更安全简洁
JDK 7+ 的 Files 类配合 Path 是推荐做法，避免了 File 的诸多陷阱（如路径拼接易错、符号链接处理不一致、异常粒度粗）。所有操作都抛出明确的 IOException 或其子类，且支持 NIO.2 的原子性语义。
典型场景：复制配置文件、批量重命名、检查磁盘剩余空间。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 创建文件或父目录：
Files.createFile(path)自动创建缺失的父目录；Files.createDirectories(path)只建目录 - 读取全部文本（小文件适用）：
Files.readString(path)（JDK 11+），比FileReader+BufferedReader少 5 行代码 - 复制/移动带覆盖控制：
Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING) - 遍历子项用
Files.list(path)（返回Stream<path></path>），比file.listFiles()更函数式，且不会因权限问题返回null
File对象的路径解析容易误判相对路径
File 构造时若传入相对路径（如 new File("config.txt")），它的“当前目录”是 JVM 启动时的工作目录（user.dir 系统属性），不是 classpath、不是 src 目录，也不是 IDE 的 project root——这点在打包成 JAR 后尤其致命，因为 File 根本找不到资源。
错误现象：开发时正常，部署后 file.exists() 始终返回 false；日志显示路径是 /home/user/config.txt，但你明明想读的是 jar 包里的 resources/config.txt。
- 资源文件（如 JSON、properties）一律用
Class.getResource()或ClassLoader.getResourceAsStream()，不要转成File - 必须用
File时，用绝对路径或显式指定基路径：new File(System.getProperty("user.dir"), "output/log.txt") - 调试路径问题，打印
file.getAbsolutePath()和file.getCanonicalPath()（后者会解析..和符号链接）对比
delete() 和 renameTo() 在跨文件系统时大概率失败
File.delete() 和 File.renameTo(File) 不是原子操作，底层依赖操作系统 API。在 Linux 下跨挂载点（如从 /tmp 移到 /home）、Windows 下跨驱动器（C: → D:），基本都会返回 false，且不抛异常——这是 File 类最隐蔽的坑。
性能影响：即使同分区，renameTo() 在某些 JVM 实现中仍可能退化为“复制+删除”，大文件极慢。
- 替换方案统一用
Files.move(source, target, StandardCopyOption.REPLACE_EXISTING)，它会自动检测是否可硬链接/重命名，否则走复制逻辑 - 删除非空目录不要手写递归，用
Files.walkFileTree()配合SimpleFileVisitor，能正确处理权限拒绝、循环链接等边界 - 如果必须用
File，调用renameTo()后务必检查返回值，失败时 fallback 到复制+删除
真正麻烦的从来不是“怎么写几行代码实现功能”，而是路径语义的理解偏差、跨环境行为差异、以及把 File 当成 I/O 入口的惯性思维——这些地方一旦出错，日志里往往只有一行 false，连异常都没有。
