filepath.Walk遍历与重命名必须分离，因Windows下路径变更会导致后续遍历失效，Linux/macOS跨设备重命名会失败且无法fallback；应先收集路径再统一重命名，并严格校验路径、防跨设备、避覆盖。
直接用 filepath.Walk 遍历 + 收集文件列表再重命名，是最稳的起点；别在遍历回调里调 os.Rename，尤其 Windows 下容易出错。
为什么不能在 filepath.Walk 回调里直接重命名
Windows 下文件系统对路径变更敏感：重命名一个文件可能改变其父目录的 inode 或句柄状态，导致后续 Walk 调用拿到失效路径，报 ERROR_PATH_NOT_FOUND 或静默跳过；Linux/macOS 虽稍好，但跨文件系统重命名会失败并返回 syscall.EXDEV，而回调里没机会 fallback 处理。
- 遍历和重命名必须分离：先用
filepath.Walk把所有待处理文件路径存进[]string或结构体切片 - 遍历阶段只做判断和收集，不修改任何文件系统状态
- 重命名阶段统一走
for循环，每个文件单独 try-catch（即if err != nil检查） - 若需递归处理子目录，
filepath.Walk本身已支持，无需手动递归
filepath.WalkDir 和 filepath.Walk 怎么选
二者不是简单新旧替代关系：filepath.WalkDir 更轻量、不自动 stat、能精确控制是否进入子目录；filepath.Walk 自动处理符号链接循环、默认跳过权限不足目录（只要你在回调里返回 nil），更适合“信任目录结构”的批量任务。
- 如果你要处理用户上传的不可信目录（含软链、挂载点、
.git等），优先用filepath.WalkDir，配合entry.Type().IsRegular()和entry.IsDir()显式过滤 - 如果你只是清理自己项目下的日志或资源文件，
filepath.Walk更省心：遇到os.ErrPermission时 returnnil就继续，不用管filepath.SkipDir对非目录是否有效 - 别混用：用
WalkDir就别依赖os.FileInfo的ModTime()或Mode()，除非显式调entry.Info() - 两者都不自动校验路径合法性——
../evil.txt这类名字必须手动 clean + prefix check
重命名前必须做的三件事
漏掉任意一项都可能导致文件丢失、覆盖关键配置、或被注入攻击。
立即学习“go语言免费学习笔记（深入）”；
- 调
filepath.Clean(oldPath)，再用strings.HasPrefix(cleaned, targetRoot)确保没逃出目标目录 - 拒绝含
..、\x00或控制字符（正则[\x00-\x08\x0b\x0c\x0e-\x1f]）的原始文件名，用utf8.ValidString先筛一遍 - 用
os.Stat(oldPath)确认是普通文件（info.Mode().IsRegular()），防止把目录、设备文件或符号链接当普通文件重命名 - 目标路径存在性检查不能少：
if _, err := os.Stat(newPath); err == nil→ 加序号或报错，别让os.Rename静默覆盖
跨盘符或原子性怎么保障
os.Rename 仅在同文件系统内原子；跨盘符时它会失败，必须 fallback 到 copy + remove，且元数据（mtime/atime/perm/xattrs）不会自动继承。
- 先试
os.Rename(old, new)，若错误是syscall.EXDEV或os.ErrInvalid，再走 copy 流程 - copy 后立即
os.Chmod(new, info.Mode())和os.Chtimes(new, info.ModTime(), info.ModTime())补权限和时间戳 - 原子性靠临时名：重命名前生成唯一
tmpName := fmt.Sprintf("%s.%d.tmp", base, time.Now().UnixNano())，先os.Rename(old, tmp)，再os.Rename(tmp, new)；第二步失败就留个 .tmp 文件，可人工识别 - 别用
os.Create+io.Copy替代 rename——慢、丢元数据、且无法保证原子性
最易被忽略的是路径校验和跨文件系统 fallback：很多人测试时都在单一分区跑通了，上线后一碰到 Docker volume 或 NFS 挂载就失败，而且没有日志提示 EXDEV，只看到 “rename failed”。
