os.Rename在Linux上并非总是原子的，因其仅在同文件系统内调用rename(2)实现原子性；跨设备时Go会退化为非原子的copy+remove，且不自动检查目标存在性或提供RENAME_NOREPLACE语义。
为什么 os.Rename 在 Linux 上不是原子的？
很多人默认 os.Rename 是原子操作，但实际它在跨设备（比如从 /tmp 移动到 /home）时会退化为“copy + remove”，中间状态可见、可中断。Linux 的 rename(2) 系统调用本身是原子的，但 Go 标准库做了兼容性兜底：当 renameat2(AT_SYMLINK_NOFOLLOW) 不可用或跨设备时，os.Rename 会 fallback 到非原子实现。
验证方式很简单：strace -e trace=rename,renameat,renameat2 go run main.go，能看到跨设备时根本没有系统调用，而是走的 io.Copy + os.Remove 路径。
- 只在同文件系统内（同一 mount point）才能保证原子性
-
os.Rename不检查目标是否存在——若目标已存在，Linux 下直接覆盖（无提示），Windows 下则报ERROR_ACCESS_DENIED - 不提供“如果目标存在则失败”的语义（即类似
renameat2(..., RENAME_NOREPLACE)）
用 syscall.Renameat2 实现真正的原子替换
Linux 3.15+ 支持 renameat2 系统调用，配合 RENAME_NOREPLACE 可实现“仅当目标不存在时重命名”，避免竞态覆盖；RENAME_EXCHANGE 还能实现无间隙的 swap（如配置热更新）。Go 1.19+ 的 syscall 包已暴露该接口，但需手动构造参数。
关键点：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 必须用绝对路径，且两个路径需在同一挂载点（否则 syscall 返回
EXDEV） -
olddirfd和newdirfd通常传AT_FDCWD（-100），表示相对当前工作目录 - 错误码
syscall.ENOENT表示源不存在，syscall.EEXIST表示目标已存在（用了RENAME_NOREPLACE时）
// 示例：安全原子替换
func atomicRename(oldpath, newpath string) error {
olddirfd := syscall.AT_FDCWD
newdirfd := syscall.AT_FDCWD
flags := syscall.RENAME_NOREPLACE
return syscall.Renameat2(olddirfd, oldpath, newdirfd, newpath, flags)
}
跨平台原子写入：先写临时文件再 os.Rename
真正可移植的原子写入方案，仍是“写临时文件 → os.Rename”模式。但要注意三个细节：
- 临时文件必须和目标文件在**同一文件系统**（否则
os.Rename会 copy）——用filepath.Dir(target)构造临时名，不要用/tmp - 写入后必须调用
file.Sync()（刷数据）和file.Close()（刷元数据），否则 rename 后可能读到空或截断内容 - 目标路径的父目录需提前确保存在且可写，否则
os.Rename失败时临时文件残留，需手动清理
典型流程：
tmp := filepath.Join(filepath.Dir(dst), "."+filepath.Base(dst)+".tmp")
f, err := os.OpenFile(tmp, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)
if err != nil { return err }
if _, err = f.Write(data); err != nil { f.Close(); os.Remove(tmp); return err }
if err = f.Sync(); err != nil { f.Close(); os.Remove(tmp); return err }
if err = f.Close(); err != nil { os.Remove(tmp); return err }
if err = os.Rename(tmp, dst); err != nil { os.Remove(tmp); return err }
并发场景下如何避免 os.Rename 竞态？
多个 goroutine 同时对同一目标路径做原子写入，即使每一步都正确，仍可能因 os.Rename 覆盖彼此而丢失数据。这不是 syscall 层问题，而是业务逻辑层缺失互斥。
- 简单场景：用
sync.Mutex或sync.Once控制单个路径的写入序列 - 高并发路径分散场景：用
map[string]*sync.Mutex+sync.Pool管理 per-path 锁，避免锁爆炸 - 更健壮做法：改用唯一临时名（如加随机后缀或时间戳），然后用
RENAME_NOREPLACE尝试提交，失败则重试（最多几次）——这样无需全局锁
容易被忽略的是：临时文件名冲突虽小，但在容器或 tmpfs 环境下，os.CreateTemp 的默认前缀（""）可能导致哈希碰撞，建议显式指定有意义的前缀，例如 os.CreateTemp(filepath.Dir(dst), "update-*.tmp")。
