用 filepath.WalkDir 遍历 + 预收集文件列表 + safeRename 封装重命名，是当前最稳的批量重命名组合；因在 Walk 回调中直接 os.Rename 会干扰路径解析、触发 Windows 缓存问题、导致跨设备错误且缺乏校验，故必须预收集再统一处理。
直接说结论：用 filepath.WalkDir 遍历 + 预收集文件列表 + safeRename 封装重命名，是当前最稳的批量重命名组合。别在 Walk 回调里直接 os.Rename，尤其 Windows 下极易出错。
为什么不能在 filepath.Walk 或 filepath.WalkDir 回调里直接 os.Rename
遍历过程中改名，会干扰后续路径解析逻辑。Windows 下尤其明显：重命名后父目录项可能被系统缓存或锁住，导致后续 filepath.Join 拼出的路径失效、os.Stat 返回 No such file or directory，甚至整个 Walk 中断。
- Windows 文件系统对重命名后目录项刷新有延迟，Walk 内部仍按旧路径继续递归
-
filepath.WalkDir虽支持跳过子目录，但若你在回调中改了某层目录名，下一层DirEntry的Name()仍是旧名，容易误判 - 跨设备重命名（如从 /home 到 /mnt/usb）会直接报
invalid cross-device link，而 Walk 不会帮你拦截
filepath.WalkDir 比 filepath.Walk 更适合多级目录重命名
核心差异在符号链接和控制粒度：filepath.Walk 默认跟随软链，遇到循环软链或挂载点可能卡死；filepath.WalkDir 提供 fs.DirEntry，让你能精确判断是否进入子目录，且不隐式读取内容。
- 用
entry.Type().IsRegular()排除非普通文件（目录、设备、套接字），比info.Mode().IsRegular()更轻量、更早失败 - 遇到
os.ErrPermission时返回filepath.SkipDir，而非nil，避免权限不足目录中断整个遍历 - 对每个
DirEntry显式调用entry.IsDir()判断是否跳过——比如只处理当前层，就直接return nil，不用进子目录
重命名前必须做的三重路径校验
用户上传或脚本生成的文件名里，../evil.txt 不是假设，是真实风险。拼接新路径后不做校验，os.Rename 可能把你整个项目目录拖进黑洞。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 对原始路径调用
filepath.Clean(oldPath)，再用strings.HasPrefix(cleaned, targetDir)确保没逃出目标根目录 - 拒绝含
..、\x00或控制字符（[\x00-\x08\x0b\x0c\x0e-\x1f]）的文件名，可用utf8.ValidString+ 正则快速过滤 - 调用
os.Stat(oldPath)确认源路径存在且是普通文件——防止把符号链接或目录当文件重命名，也避免软链被意外展开
如何安全封装 os.Rename：设备判断 + 存在性检查 + 错误映射
os.Rename 在 Linux/macOS 是 rename(2) 系统调用，不支持跨设备；且默认不检查目标是否存在，静默覆盖或报错都不可控。
- 用
filepath.Dir(oldPath)和filepath.Dir(newPath)获取父目录，再用os.Stat拿sys.Dev对比是否同设备；不同设备时改用io.Copy+os.Remove - 重命名前先
_, err := os.Stat(newPath)，若err == nil表示已存在，按策略决定跳过、加序号后缀或强制覆盖 - 封装成
safeRename(old, new string, overwrite bool) error，内部统一处理设备、存在性、错误类型（比如把invalid cross-device link映射为自定义错误便于提示）
真正容易被忽略的是路径校验和设备判断——多数人只记得检查目标文件是否存在，却忘了 ../ 可以绕过目录限制，也忘了 os.Rename 根本不跨设备。这两点不处理，脚本跑得越快，破坏力越大。
