os.rename并非总能原子生效，因其底层调用rename(2)系统调用，仅在同一文件系统（挂载点）内原子；跨设备时返回syscall.exdev错误，需降级为复制+删除并同步元数据。
os.Rename 为什么不是总能原子生效
因为 os.Rename 底层调用的是系统 rename(2) 系统调用，它只在**同一文件系统（挂载点）内**保证原子性。一旦源路径和目标路径跨设备（比如 /tmp 和 /home 属于不同磁盘分区）、跨 Docker volume、跨 WSL 路径或 Windows 下跨盘符（C:\ → D:\），就会立刻失败，错误是 invalid cross-device link，对应 Go 中的 syscall.EXDEV。
这不是权限或路径拼写问题——检查错误时，第一反应应该是「是否跨设备」，而不是反复 chmod 或 mkdir。
- 用
errors.Is(err, syscall.EXDEV)显式捕获该错误，不要靠字符串匹配 - 跨设备时必须降级为
io.Copy+os.Remove，且顺序不能颠倒：先复制成功，再删源 - 复制后必须补全元数据：
os.Chmod(newpath, info.Mode())和os.Chtimes(newpath, info.ModTime(), info.ModTime())
批量重命名前必须校验路径合法性
直接拼接新文件名并调用 os.Rename 是高危操作。用户上传的原始文件名可能含 ../evil.txt、空字符 \x00 或控制字符，导致路径遍历或静默截断。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对每个待处理的
oldName先调用filepath.Clean，再用strings.HasPrefix(cleaned, targetDir)确保仍在目标目录下 - 拒绝含
..、\x00或 Unicode 控制字符（正则[\x00-\x08\x0b\x0c\x0e-\x1f]）的文件名 - 用
os.Stat确认源是普通文件（info.Mode().IsRegular()），避免误操作目录或符号链接
如何实现单步原子 + 可逆的重命名
批量操作中，第 3 个文件失败时，前 2 个已改名，状态不一致。文件系统不支持事务回滚，只能靠每步自身可逆。
- 每步重命名前生成唯一临时名，如
fmt.Sprintf("%s.%d.tmp", base, time.Now().UnixNano()) - 执行两阶段 rename：
os.Rename(old, tmp)→os.Rename(tmp, new) - 若第二步失败，保留
.tmp文件，便于后续扫描清理；不要用os.Create+io.Copy模拟 rename，会丢失权限、atime/mtime、xattrs，且慢一个数量级
filepath.WalkDir 为什么比 filepath.Walk 更安全
filepath.Walk 默认跟随符号链接，遇到循环软链或挂载点可能卡死、遍历出意料之外的路径；而 filepath.WalkDir 提供 fs.DirEntry，能精确控制行为。
- 用
entry.Type().IsRegular()排除非文件项，跳过目录、设备文件等 - 通过
entry.IsDir()判断是否进入子目录，避免递归污染 - 权限不足时返回
filepath.SkipDir，而非panic或中断整个流程
最常被忽略的一点：原子性只在同文件系统内成立，且仅限于 rename 操作本身；一旦引入 copy/remove，就必须手动同步权限、时间戳，并面对“复制成功但删除失败”的中间态——这个状态无法自动恢复，得靠日志+残留扫描兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
