用改名映射表实现可核对的批量回滚

批量改名一旦执行，最麻烦的不是改名本身，而是出错后难以回到执行前状态。PowerShell 的 Rename-Item 不会自动生成撤销记录，尤其当任务中途失败时，文件夹里可能同时存在已改名和未改名文件。此时靠肉眼恢复既慢又容易覆盖新文件。更稳妥的做法是把预览阶段生成的改名计划保留为一张映射表，让回滚有据可依。

映射表至少应包含四列：原名称、新名称、源路径、目标路径。原文例子中的 $plan 已经是这种结构，通过 ForEach-Object 创建的对象保存了 OldName、NewName、Source、Target。执行前，它只是预演；执行后，它才变成唯一的回滚依据。关键不是映射表有多复杂，而是它在执行前有没有被完整保留，以及回滚时是否重新与文件系统核对。如果只在屏幕上预览后就丢弃，等于放弃了可回滚能力。

执行后出现报错时，不能把 NewName 简单当作当前文件名。部分文件可能未改名，源路径仍然存在；另一些已经改名，目标路径才存在。回滚脚本应先对每一行判断当前实际存在的路径：如果 Target 存在，则准备把 Target 改回 OldName；如果只有 Source 存在，说明该文件未改动，无需处理。判断应使用 Test-Path -LiteralPath，而不是字符串匹配，避免路径空格或特殊字符造成误判。恢复原名之前还要检查 OldName 是否已经被其他文件占用；一旦同名文件已经产生，回滚可能失败或覆盖，应该先处理冲突，而不是直接执行。

回滚同样需要预演。可以按反转后的映射生成恢复计划，对每个需要恢复的项运行 Rename-Item 加 -WhatIf，先显示拟恢复的源路径与目标名称。只有在预演输出与映射表一致、且没有目标路径冲突时，才去掉 -WhatIf 执行。回滚顺序也应保守：先核对，再预演，最后批量执行；执行后再次逐行检查恢复后的文件是否存在。这样回滚不再是一次性补救，而是与正向改名同样受控的过程。

需要明确的是，映射表只能回滚它记录的那次操作。若执行后又手动改过文件名、移动过文件，或向文件夹新增了同名文件，映射表不会自动知道这些变化。因此恢复前必须把映射表当作“当时快照”，与当前状态重新对齐。映射表越早保存、保留越完整，后续恢复的可靠性越高。对批量文件操作而言，可核对的前提不是命令本身支持撤销，而是操作者在执行前已经把旧名与新名的对应关系固化成可以复查、反转和校验的数据。这个数据就是映射表；有了它，批量改名才具备可控的退出路径。