os.Rename不自动处理目标文件存在的情况，会直接报错；正确做法是先用os.Stat检查目标是否存在，再按需生成新名（如加序号）并确保原子性避让。
文件已存在时，os.Rename 直接报错，不自动重命名
Go 标准库的 os.Rename 是原子性系统调用封装，它不会检测目标路径是否已存在，而是直接交由操作系统处理。在大多数系统（Linux/macOS/Windows）上，若 dst 已存在，os.Rename 会返回 rename …: file exists 错误（Linux/macOS）或类似 The file exists 的 Windows 错误。
这意味着：你不能指望 os.Rename 像“保存为”那样自动加后缀——它要么成功移动/重命名，要么失败。
- 常见错误现象：
os.Rename("a.txt", "b.txt")在b.txt已存在时 panic 或忽略错误，导致数据丢失或静默失败 - 正确做法是先用
os.Stat检查dst是否存在，再决定是否生成新名字 - 注意：
os.Stat对不存在路径返回os.IsNotExist(err)为 true；对权限不足等其他错误需单独判断
实现安全重命名：带序号的自动避让逻辑
典型场景是用户上传同名文件、日志轮转、缓存写入等，需要生成如 report.pdf → report_1.pdf → report_2.pdf 这样的序列。
关键点不是“递归尝试”，而是避免竞态和重复计算：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 不要用
for i := 0; ; i++循环 +os.Stat检查——并发写入时可能多个 goroutine 同时判定name_1不存在，然后都去创建，引发冲突 - 更稳妥的方式是：先尝试原名，失败后生成候选名，用
os.OpenFile(..., os.O_CREATE|os.O_EXCL|os.O_WRONLY)创建空文件占位（利用O_EXCL的原子性），成功即表示该名可用 - 若只是重命名（非创建），可改用
os.Link+os.Remove组合模拟“原子替换”，但仅限同一文件系统；跨设备必须拷贝+删除 - 示例片段：
func safeRename(src, dst string) (string, error) { if _, err := os.Stat(dst); os.IsNotExist(err) { return dst, os.Rename(src, dst) } base, ext := trimExt(dst) i := 1 for { candidate := fmt.Sprintf("%s_%d%s", base, i, ext) f, err := os.OpenFile(candidate, os.O_CREATE|os.O_EXCL|os.O_WRONLY, 0644) if err == nil { f.Close() os.Remove(candidate) // 清掉占位文件 return candidate, os.Rename(src, candidate) } if !os.IsExist(err) { return "", err // 其他错误（如权限） } i++ } }
filepath.Base 和 filepath.Ext 处理不当会导致重命名错位
很多人直接用 strings.LastIndex 或正则提取扩展名，结果在 archive.tar.gz 或无扩展名文件（如 Dockerfile）上出错。
filepath.Ext 的行为是：返回最后一个 . 及之后的部分，且当文件名以 . 开头（如 .gitignore）时返回完整字符串——这常被误认为“有扩展名”，实际应视为无扩展名。
- 正确分离名+扩展：用
base := strings.TrimSuffix(filepath.Base(path), filepath.Ext(path))，但注意filepath.Ext("")返回空，filepath.Ext("log")返回"" - 更健壮的做法是先判断是否含
.且不在开头，再切分；或统一用path.Base+ 自定义扩展提取逻辑 - Windows 路径中反斜杠不影响
filepath函数，但拼接时务必用filepath.Join，别硬拼"\"或"/"
并发写入下，重命名逻辑必须考虑 syscall.EBUSY 和 syscall.ENOTEMPTY
在容器环境、网络文件系统（NFS）、或某些杀毒软件介入时，os.Rename 可能返回 EBUSY（设备或资源忙）或 ENOTEMPTY（目录非空，却试图覆盖目录），这些错误无法靠重试序号解决。
-
EBUSY常见于目标文件正被其他进程打开读取（尤其 Windows）；此时应加短延时重试（如 10–100ms），最多 3–5 次 -
ENOTEMPTY表明目标是目录，而你试图用os.Rename覆盖它——这是非法操作，需提前用os.Stat判断IsDir()并清理或拒绝 - 生产级代码建议封装成带上下文取消、指数退避、错误分类的重命名函数，而非裸调
os.Rename
路径冲突的本质不是命名策略问题，而是状态同步问题：你永远无法 100% 确保“检查存在 → 生成名字 → 执行重命名”这一串操作的原子性。真正可靠的方案，是设计时就规避竞争——比如用唯一 ID 命名（UUID / 时间戳+PID），或依赖外部锁服务（Redis lock），而不是在文件层反复修补。
