renameTo返回false的主因是目标文件存在、跨分区、权限不足或父目录不存在；listFiles返回null需先校验exists()和isDirectory()；推荐用Files.move替代renameTo以获得明确异常。
renameTo 为什么总返回 false
Java 的 renameTo 不是“重命名失败就抛异常”，而是静默失败、只返回 false。常见原因不是路径写错，而是目标文件已存在、源/目标跨磁盘分区、权限不足或目标父目录不存在。
- Windows 下跨盘符（如
C:\→D:\）必失败；Linux/macOS 跨挂载点同理 -
renameTo不会自动创建目标路径的父目录，new File("out/a/b/c.txt").mkdirs()得自己提前做 - 目标文件若已存在，多数 JVM 实现直接返回
false（不覆盖），得先delete()再操作 - 注意文件锁：用
FileInputStream打开后未关闭，renameTo在 Windows 上大概率失败
listFiles 返回 null 怎么办
listFiles 在目录不存在、非目录、无读权限时返回 null，而不是空数组——这是新手最常踩的空指针雷。
- 调用前必须先
file.isDirectory() && file.exists()双重校验 - 不要直接遍历
listFiles()结果，先判空：if (files == null) { /* 处理错误 */ } - 如果只想过滤特定后缀，别手写 for 循环筛，用
listFiles(FileFilter)更安全，比如file -> file.getName().endsWith(".log") - 注意：
listFiles不递归，子目录里的文件不会出现，要递归得自己写栈或队列
批量重命名时中文名乱码或报错
问题不在 renameTo，而在文件系统编码和 JVM 启动参数。Windows 默认 GBK，但 IDE 或终端可能用 UTF-8，导致 File 构造时字节解码错位。
- 确认当前 JVM 编码：
System.getProperty("file.encoding")，不是UTF-8就得加启动参数-Dfile.encoding=UTF-8 - 避免用字符串拼接路径，改用
Paths.get(dir, oldName).toFile()，它更健壮 - 如果路径含中文且
renameTo失败，临时改用Files.move（Java 7+），它对编码更宽容，且能抛出具体异常：Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING) - 别依赖 IDE 控制台输出判断文件名是否正确——控制台字体/编码可能掩盖真实问题，用
file.getName().getBytes(StandardCharsets.UTF_8)看原始字节
renameTo 和 Files.move 到底选哪个
renameTo 是旧 API，轻量但行为不一致；Files.move 是 NIO.2 标准，可移植性强，但默认不跨文件系统。
立即学习“Java免费学习笔记（深入）”；
-
renameTo：适合单机、确定不跨盘、追求极简的脚本场景；失败不报错，调试成本高 -
Files.move：推荐用于所有新代码，失败会抛IOException（比如AccessDeniedException或FileSystemException），容易定位问题 - 跨文件系统移动（即“复制+删原”）需显式指定：
Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.COPY_ATTRIBUTES)，否则默认只尝试原子重命名 - 注意：
Files.move的src和dst必须是Path，别混用File；转法是file.toPath()
真正麻烦的从来不是写几行 rename 逻辑，而是搞清当前环境里文件系统怎么认路径、JVM 怎么解码字节、以及哪一层在静默吞掉错误。这些细节不盯住，批量跑几百个文件时，可能只有最后三个出错，还找不到原因。
