简介：这份源码工具面向需要处理大量文件重命名任务的Java开发者与初学者，提供了一套基于Java标准库的批量重命名实现思路。资源包内仅含1个java源文件，压缩包约1KB，体量轻巧，便于直接阅读与二次修改。代码围绕File类的listFiles()遍历目录，并结合java.nio.file包中的Files.move()方法完成更可靠的重命名操作，同时演示了按序号、替换字符串等规则生成新文件名的常见做法，还涉及异常处理与逻辑封装等工程细节。目前已有574人学习下载，适合想快速掌握文件批量处理技巧、理解传统IO与现代NIO差异的读者参考借鉴，也可作为日常脚本工具的基础模板，按项目需求定制重命名策略。

1. 文件批量重命名：为什么你写的 renameTo 总是静默失败

很多人第一次用 Java 做文件批量重命名，都会经历同一个场景：本地测试跑得好好的，一放到真实目录就出问题——有的文件改了，有的没改，程序还不报错。File.renameTo()返回一个 boolean，你甚至没接返回值，于是它就成了一个黑匣子。这个标题要解决的就是这件事：用 Java 把一批文件按规则改名，规则可控、结果可验证、失败可回滚。

它适合三类人：手里有一堆相机原图、扫描件、导出报表需要按序号或日期重排的；做数据清洗时要把文件名和元数据对齐的；以及想把重命名逻辑封装成可复用工具类的。核心难点从来不是「怎么改一个名字」，而是批量场景下的命名冲突、跨盘移动、并发占用和失败回滚。下面按我实际落地的顺序讲清楚。

2. 先选对 API：File、Files 与 Path 的取舍

2.1 为什么我基本不再用 File.renameTo

File.renameTo是 JDK 1.0 就有的方法，它的行为高度依赖底层文件系统。同一个盘符内改名通常是原子的，但跨盘符时很多平台直接返回 false，而且它不抛异常，你只能靠返回值判断。更麻烦的是，当目标文件已存在时，不同系统表现不一致：有的覆盖，有的失败，有的部分写入。批量场景下这种不确定性是灾难。

java.nio.file.Files.move是 JDK 7 引入的替代方案，它把失败原因通过IOException暴露出来，还支持StandardCopyOption控制覆盖和原子性。批量重命名本质是「同目录改名」或「移动到新名字」，用Files.move能拿到明确的异常类型，排查时不用猜。

import java.io.IOException; import java.nio.file.*; public class RenameBasic { public static void main(String[] args) throws IOException { Path source = Paths.get("/data/photos/IMG_0001.jpg"); Path target = Paths.get("/data/photos/2024_001.jpg"); // ATOMIC_MOVE 保证同盘改名要么成功要么不变，避免中间态 // REPLACE_EXISTING 明确覆盖语义，不依赖平台默认行为 Files.move(source, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING); } }

逻辑说明：ATOMIC_MOVE在支持的文件系统上保证操作原子性，失败会抛AtomicMoveNotSupportedException，这时可以降级为普通 move。REPLACE_EXISTING让覆盖行为显式化，避免「有的覆盖有的不覆盖」的玄学。参数上，如果目标目录和源目录不在同一存储卷，ATOMIC_MOVE会失败，需要捕获后去掉该选项重试。

2.2 Path 与 Files 的组合更适合批量

批量操作里，路径拼接、扩展名提取、父目录判断这些动作会反复出现。Path提供了getFileName、getParent、resolveSibling等方法，比字符串拼接安全得多。比如给文件加前缀，用resolveSibling可以避免手写分隔符在 Windows 和 Linux 上的差异。

Path dir = Paths.get("/data/photos"); try (DirectoryStream<Path> stream = Files.newDirectoryStream(dir, "*.jpg")) { for (Path p : stream) { String name = p.getFileName().toString(); // 用 resolveSibling 生成同目录下的新路径，不碰分隔符 Path renamed = p.resolveSibling("batch_" + name); Files.move(p, renamed, StandardCopyOption.REPLACE_EXISTING); } }

逻辑说明：newDirectoryStream的第二个参数是 glob 过滤，只拿 jpg，避免把子目录也当文件处理。resolveSibling保证新路径和原文件同目录，不会因为字符串拼接把路径拼错。参数上，glob 语法支持*、?、{}，但注意它不递归子目录，需要递归时得自己写Files.walk。

2.3 选型对照表

提示：如果项目还在 JDK 6 或更早，只能用 File，但务必检查返回值并记录失败文件，不要静默忽略。

3. 命名规则引擎：把「怎么改」和「改哪些」拆开

3.1 用函数式接口定义重命名策略

批量重命名的规则千变万化：加前缀、按序号、按日期、按元数据。如果每换一个规则就改一遍遍历逻辑，代码会迅速腐化。我的做法是把「生成新文件名」抽成一个函数式接口，遍历和移动的逻辑保持不变。

@FunctionalInterface public interface NameStrategy { // index 是当前文件在批次中的序号，从 0 开始 String apply(Path file, int index); } public class BatchRenamer { public static void rename(Path dir, String glob, NameStrategy strategy) throws IOException { List<Path> files = new ArrayList<>(); try (DirectoryStream<Path> stream = Files.newDirectoryStream(dir, glob)) { for (Path p : stream) { if (Files.isRegularFile(p)) files.add(p); } } // 排序保证序号稳定，否则目录流顺序不保证 files.sort(Comparator.comparing(p -> p.getFileName().toString())); for (int i = 0; i < files.size(); i++) { Path src = files.get(i); String newName = strategy.apply(src, i); Path dst = src.resolveSibling(newName); if (src.equals(dst)) continue; // 名字没变就跳过，避免无意义 IO Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING); } } }

逻辑说明：先把文件收集到 List 再排序，是因为DirectoryStream的遍历顺序由文件系统决定，不排序的话序号会乱。src.equals(dst)判断能跳过那些规则算出来和原名相同的文件，减少不必要的系统调用。参数上，glob决定处理范围，strategy决定命名规则，两者正交，换规则不用动核心逻辑。

3.2 三种常用策略的实现

序号补零是最常见的需求，比如把a.jpg、b.jpg改成img_001.jpg、img_002.jpg。补零位数要根据文件总数动态算，否则超过 999 个文件序号就错位了。

// 策略一：按序号补零，位数根据总数动态计算 int width = String.valueOf(files.size()).length(); NameStrategy seq = (file, index) -> { String ext = getExtension(file.getFileName().toString()); return String.format("img_%0" + width + "d%s", index + 1, ext); }; // 策略二：加统一前缀，保留原名 NameStrategy prefix = (file, index) -> "2024_" + file.getFileName(); // 策略三：按最后修改时间命名，适合照片归档 NameStrategy byTime = (file, index) -> { try { FileTime t = Files.getLastModifiedTime(file); LocalDateTime dt = LocalDateTime.ofInstant(t.toInstant(), ZoneId.systemDefault()); String ext = getExtension(file.getFileName().toString()); return DateTimeFormatter.ofPattern("yyyyMMdd_HHmmss").format(dt) + "_" + index + ext; } catch (IOException e) { throw new UncheckedIOException(e); } };

逻辑说明：序号策略里width由文件总数决定，保证排序后字典序和数字序一致。时间策略里加了index后缀，是因为同一秒内可能有多个文件，纯时间戳会冲突。getExtension需要自己实现，注意处理没有扩展名的文件，返回空字符串而不是抛异常。

3.3 扩展名提取的边界处理

扩展名提取看着简单，坑不少：archive.tar.gz算不算双扩展名、.gitignore这种以点开头的隐藏文件、文件名里带多个点的情况。我的经验是只取最后一个点之后的部分，且点不能在开头。

static String getExtension(String name) { int dot = name.lastIndexOf('.'); // dot > 0 排除 .gitignore 这类隐藏文件，dot 在末尾说明没有扩展名 if (dot > 0 && dot < name.length() - 1) { return name.substring(dot); } return ""; }

逻辑说明：dot > 0而不是>= 0，是为了让.gitignore被当作无扩展名文件，避免把它改成.gitignore之外的东西。dot < length - 1排除file.这种结尾是点的异常名。参数上没有可调的，但调用方要清楚这个函数不处理双扩展名，需要时得单独写规则。

4. 冲突、回滚与并发：批量重命名的三个硬骨头

4.1 命名冲突的检测与消解

批量重命名最危险的情况是目标名已被占用。比如把1.jpg改成2.jpg，而2.jpg本来就在目录里，REPLACE_EXISTING会直接覆盖，数据就没了。正确做法是先算出所有目标名，检测冲突，再决定策略。

// 先预演，收集所有目标名，检测重复和已存在 Map<String, Path> planned = new LinkedHashMap<>(); for (int i = 0; i < files.size(); i++) { Path src = files.get(i); String newName = strategy.apply(src, i); Path dst = src.resolveSibling(newName); if (planned.containsKey(newName) || (Files.exists(dst) && !files.contains(dst))) { throw new IllegalStateException("命名冲突: " + newName); } planned.put(newName, src); } // 预演通过后再执行移动

逻辑说明：planned用 LinkedHashMap 保留插入顺序，方便定位是哪个文件出的问题。Files.exists(dst) && !files.contains(dst)这个条件很关键：如果目标文件本身也在待处理列表里，那它稍后会被改名，不算冲突；如果不在列表里，就是真冲突。参数上，冲突时是抛异常还是自动加后缀，取决于业务，我一般抛异常让调用方决定。

4.2 失败回滚的实现思路

批量操作执行到一半失败，已经改了的文件怎么办？没有回滚的话，目录会处于半完成状态，比不改还糟。回滚的核心是记录每一步的「源→目标」，失败时逆序改回去。

Deque<Path[]> done = new ArrayDeque<>(); try { for (Map.Entry<String, Path> e : planned.entrySet()) { Path src = e.getValue(); Path dst = src.resolveSibling(e.getKey()); if (src.equals(dst)) continue; Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING); done.push(new Path[]{src, dst}); // 记录，用于回滚 } } catch (IOException ex) { // 逆序回滚，先改的后面回滚，避免中间名冲突 while (!done.isEmpty()) { Path[] pair = done.pop(); try { Files.move(pair[1], pair[0], StandardCopyOption.REPLACE_EXISTING); } catch (IOException rollbackEx) { // 回滚失败只能记录，无法再补救 System.err.println("回滚失败: " + pair[1] + " -> " + pair[0]); } } throw ex; }

逻辑说明：用栈记录已完成的操作，回滚时后进先出，这样能避免「A 改成 B、B 改成 C」这种链式改名回滚时的中间冲突。回滚本身也可能失败，这时只能打日志，因为已经没有更好的补救手段。参数上，回滚不保证 100% 成功，所以重要数据操作前建议先备份或先做 dry-run。

4.3 文件被占用时的重试

Windows 上文件被其他进程打开时，移动会抛FileSystemException。批量处理时偶尔撞上一两个被占用的文件很正常，直接失败太粗暴，加个有限重试更实用。

static void moveWithRetry(Path src, Path dst, int maxRetry) throws IOException { IOException last = null; for (int i = 0; i < maxRetry; i++) { try { Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING); return; } catch (FileSystemException e) { last = e; try { Thread.sleep(200L * (i + 1)); // 退避，给占用进程释放时间 } catch (InterruptedException ie) { Thread.currentThread().interrupt(); throw new IOException("重试被中断", ie); } } } throw last; }

逻辑说明：退避时间随重试次数递增，避免密集重试加剧资源竞争。只捕获FileSystemException，其他异常直接抛出，不掩盖真正的问题。参数上，maxRetry我一般设 3，再多说明文件被长期占用，重试也没意义，应该报出来让人处理。

5. 避坑与排查：那些让我加班到深夜的细节

5.1 目录流遍历时改名导致漏文件

现象：一批 100 个文件，只改了 60 多个就结束了，剩下的没动。原因：在DirectoryStream遍历过程中直接改名，改变了目录项，导致迭代器状态错乱。解决：先把所有文件收集到 List，关闭流之后再执行改名，这也是前面代码里先收集再排序的原因。

5.2 大小写不敏感文件系统上的假冲突

现象：在 Windows 或 macOS 默认文件系统上，把Photo.jpg改成photo.jpg，程序报冲突或行为异常。原因：这些文件系统大小写不敏感，Files.exists对两个名字返回相同结果。解决：改名时先判断src.equals(dst)之外，还要用Files.isSameFile确认是否真的是同一个文件，是则跳过。

5.3 序号补零位数不够导致排序错乱

现象：文件总数 1200，序号补到 3 位，结果img_1000排在img_999前面。原因：字符串排序下1小于9。解决：补零位数用String.valueOf(total).length()动态计算，1200 个文件就补 4 位，保证字典序等于数字序。

5.4 跨盘移动时 ATOMIC_MOVE 直接抛异常

现象：从 C 盘改到 D 盘，程序抛AtomicMoveNotSupportedException。原因：原子移动要求源和目标在同一存储卷，跨卷无法保证。解决：捕获该异常后去掉ATOMIC_MOVE重试，或者提前用Files.getFileStore判断两个路径是否同卷。

5.5 中文文件名在不同平台编码不一致

现象：Linux 上生成的中文名文件，拿到 Windows 上显示乱码。原因：文件系统编码和 JVM 默认字符集不一致。解决：启动参数显式指定-Dfile.encoding=UTF-8，并且读写文件名时统一用 UTF-8，不要依赖平台默认值。

6. 进阶：把重命名做成可 dry-run 的可验证工具

真正在生产里用，我会给批量重命名加一个 dry-run 模式：只打印「谁改成谁」，不实际动文件。这样在真正执行前能肉眼检查规则对不对，尤其是正则替换这种容易写错的规则。实现上就是把移动那一步换成日志输出，其余逻辑完全复用。

public static void rename(Path dir, String glob, NameStrategy strategy, boolean dryRun) throws IOException { List<Path> files = collect(dir, glob); Map<String, Path> planned = plan(files, strategy); // 预演，含冲突检测 if (dryRun) { planned.forEach((newName, src) -> System.out.println(src.getFileName() + " -> " + newName)); return; } execute(planned); // 带回滚的执行 }

逻辑说明：plan和execute拆开，dry-run 只走 plan，保证预演和实际执行的规则完全一致，不会出现「预演看着对、执行却不同」的情况。参数上，dryRun建议默认 true，让调用方显式传 false 才真正执行，这是一种防手滑的设计。

验证方法上，我习惯在 dry-run 输出里做两件事：一是检查目标名是否有重复，二是检查目标名是否符合预期的正则。可以用一段简单的断言脚本跑一遍输出，确认无误再执行。

还有一个我踩过的坑：正则替换规则里用了贪婪匹配，把文件名里的日期也吃掉了。后来养成习惯，所有正则规则先在 dry-run 输出上跑一遍，用眼睛扫一遍前 20 条和后 20 条，中间随机抽几条。批量操作没有后悔药，预演是唯一低成本的安全网。希望帮到你。

本文还有配套的精品资源，点击获取