file.exists()返回false的常见原因包括路径未转义、相对路径工作目录不清、windows下反斜杠被误解析为转义字符；mkdir()失败不报异常需检查返回值；delete()在windows下因文件被占用而静默失败；length()可能滞后于实际大小，应优先使用files api。
File.exists() 返回 false 但文件明明存在？
常见原因是路径没转义或用了相对路径却没搞清工作目录。Java 的 File 不自动处理路径分隔符，Windows 下写 "C: est ile.txt" 会因 被当制表符解析，直接报错或路径错乱。
- 一律用双反斜杠
"C:\test\file.txt"或正斜杠"C:/test/file.txt" - 用
new File("config.json").getAbsolutePath()打印出来看实际解析路径，确认是不是在你预期的位置 -
File不检查父目录是否存在，exists()对空目录也返回false，得先用isDirectory()配合判断
mkdir() 失败却不报异常？
File.mkdir() 和 mkdirs() 都只返回 boolean，失败静默——这是最常踩的坑。比如父目录不存在时 mkdir() 必定失败，而 mkdirs() 才会递归创建。
- 永远检查返回值：
if (!dir.mkdir()) { throw new IOException("创建目录失败: " + dir); } - 权限问题在 Linux/macOS 上更明显：如果父目录不可写，
mkdirs()也会返回false - JDK7+ 建议改用
Files.createDirectory(Paths.get("..."))，失败直接抛IOException，不用手动判空
File.delete() 在 Windows 下总失败？
Windows 锁文件机制严格：只要有任何进程（包括 Java 自己的 FileInputStream、IDE 控制台、甚至资源管理器预览窗格）还持有着句柄，delete() 就返回 false，且不提示原因。
- 确保流已关闭：用 try-with-resources，别依赖
finalize()或手动close()后忘判 null - 不要在 delete 前调用
listFiles()并缓存数组——某些 JVM 实现会让目录句柄残留 - 临时文件建议用
Files.deleteIfExists(Paths.get(...))，它比File.delete()更可靠，还会抛出具体异常（如AccessDeniedException）
File.length() 返回 0 却能读到内容？
这不是 bug，是 File.length() 只反映「上次写入完成时」的大小。如果文件正被其他进程追加写入（比如日志系统），或者 Java 自己用 RandomAccessFile 指针跳着写，length() 就可能滞后。
立即学习“Java免费学习笔记（深入）”；
- 读取前别依赖
length()判断是否为空，改用Files.size(Paths.get(...))（JDK7+），它底层调用系统 stat，更准 - 对正在写的日志文件做轮转时，
length()可能比实际小几 KB，别拿它做精确分片依据 -
File类本身不提供刷新元数据的方法，查实时大小必须走Files或原生 API
File 类的很多行为都依赖底层 OS 的实现细节，跨平台时尤其要注意路径、权限和锁机制的差异。真要稳定操作文件，JDK7 引入的 Files 和 Path 才是现在该盯住的主力。不过老项目里绕不开 File，那就得把每个返回值和边界条件都当成可能出事的地方来防。
