Go 怎么安全地批量重命名文件并支持失败回滚

批量改文件名最容易出事故的地方，不是字符串拼接，而是“改到一半”时目录里已经出现了新旧名称的混合状态。更稳妥的做法是先检查计划，再把所有源文件移到同目录的唯一临时名，最后提交为正式目标名；任何一步失败，都按成功日志的倒序恢复。这样可以处理文件互换、链式改名和中途目标冲突，但本文明确限定在同一文件系统内。

为什么批量重命名不能只循环调用 os.Rename

os.Rename(oldpath, newpath) 负责一次移动，不知道你的批次还有多少项，也不会替你保存撤销信息。Go 官方文档说明：目标已存在且不是目录时，Rename 会替换它；跨目录还可能受操作系统限制，非 Unix 平台即使同目录也不保证是原子操作。因此，下面的批处理先把“目标已经存在”视为冲突，而不是依赖平台差异。

名称互换是最直观的反例：a.txt → b.txt、b.txt → a.txt。直接按列表执行，第一步就可能覆盖第二个源文件。临时名方案把占用关系拆开：先保存每个源文件，再统一写入目标。

先把批量重命名拆成临时名和正式名

预检查至少做四件事：路径不能为空、源和目标不能相同、目标不能重复、源文件必须存在。若目标是一个既不在源集合中、又已经存在的路径，直接拒绝本批次，避免把 os.Rename 的平台行为变成数据覆盖。

import (
	"errors"
	"fmt"
	"io/fs"
	"os"
)

type RenameItem struct {
	From string
	To   string
}

type moveRecord struct {
	From string // 已经移动过的起点
	To   string // 已经移动到的位置
}

func preflight(items []RenameItem) error {
	sources := make(map[string]struct{}, len(items))
	targets := make(map[string]struct{}, len(items))
	for _, item := range items {
		if item.From == "" || item.To == "" || item.From == item.To {
			return fmt.Errorf("invalid rename pair: %q -> %q", item.From, item.To)
		}
		if _, ok := sources[item.From]; ok {
			return fmt.Errorf("duplicate source: %s", item.From)
		}
		if _, ok := targets[item.To]; ok {
			return fmt.Errorf("duplicate target: %s", item.To)
		}
		if _, err := os.Lstat(item.From); err != nil {
			return fmt.Errorf("source %s: %w", item.From, err)
		}
		sources[item.From] = struct{}{}
		targets[item.To] = struct{}{}
	}
	for target := range targets {
		if _, inSources := sources[target]; inSources {
			continue // 目标是本批次的另一个源，交给临时名处理
		}
		if _, err := os.Lstat(target); err == nil {
			return fmt.Errorf("target already exists: %s", target)
		} else if !errors.Is(err, fs.ErrNotExist) {
			return fmt.Errorf("check target %s: %w", target, err)
		}
	}
	return nil
}

这一步只检查名称和文件状态，不试图用“先删目标再改名”解决冲突。删除会让回滚失去原文件，尤其不适合批量任务。

失败时按倒序回滚，别把恢复当成重试

核心是把两阶段的每一次成功移动都写入同一个日志：源文件移到临时名，记一条；临时名提交到目标，继续记一条。失败时从最后一条开始，把记录的 To 移回 From。倒序很重要，因为后移动的路径可能暂时占用着前一条记录要恢复的位置。

func BatchRename(items []RenameItem) error {
	if err := preflight(items); err != nil {
		return err
	}
	records := make([]moveRecord, 0, len(items)*2)
	temps := make([]string, len(items))

	rollback := func(cause error) error {
		var rollbackErr error
		for i := len(records) - 1; i >= 0; i-- {
			r := records[i]
			if err := os.Rename(r.To, r.From); err != nil {
				rollbackErr = errors.Join(rollbackErr,
					fmt.Errorf("rollback %s -> %s: %w", r.To, r.From, err))
			}
		}
		return errors.Join(cause, rollbackErr)
	}

	for i, item := range items {
		// 临时名和源文件同目录，避免跨文件系统移动。
		tmp := fmt.Sprintf("%s.__rename_tmp_%d", item.From, i)
		if _, err := os.Lstat(tmp); err == nil {
			return rollback(fmt.Errorf("temporary path exists: %s", tmp))
		} else if !errors.Is(err, fs.ErrNotExist) {
			return rollback(fmt.Errorf("check temporary path %s: %w", tmp, err))
		}
		if err := os.Rename(item.From, tmp); err != nil {
			return rollback(fmt.Errorf("stage %s -> %s: %w", item.From, tmp, err))
		}
		temps[i] = tmp
		records = append(records, moveRecord{From: item.From, To: tmp})
	}

	for i, item := range items {
		if err := os.Rename(temps[i], item.To); err != nil {
			return rollback(fmt.Errorf("commit %s -> %s: %w", temps[i], item.To, err))
		}
		records = append(records, moveRecord{From: temps[i], To: item.To})
	}
	return nil
}

示例使用 errors.Join 同时返回原始失败和回滚失败；如果回滚也失败，目录可能仍处于中间状态，调用方应把日志和错误交给人工处理，而不是自动再跑一遍。

上线前检查冲突、跨盘和并发写入边界

另一个容易忽略的点是大小写敏感性：在大小写不敏感的文件系统上，a.txt 和 A.txt 可能不是两个独立目标。若任务来自用户输入，应先按目标平台做规范化比较，再把最终路径写入计划。对于跨盘移动，os.Rename 不等价于复制后删除；要换成复制、校验、落盘和删除的事务化流程，不能套用这里的回滚代码。

常见问题

为什么不先判断目标存在，再直接调用 os.Rename？

判断只能降低一部分冲突，不能阻止并发进程在判断后抢先创建目标。批次内部的互换问题仍要靠临时名解决；有并发写入时还要增加锁或单写者约束。

回滚失败后能不能立即重试整批？

不建议。先依据每条 moveRecord 确认目录当前状态，修复权限或占用问题，再从未完成记录恢复；盲目重试可能把已经恢复的文件再次移动。

临时名应该放到系统临时目录吗？

不应该把它作为默认方案。系统临时目录可能与源文件不在同一文件系统，优先在源文件同目录生成不可冲突的临时名，并在任务完成后不留下临时文件。