是，os.Rename在同文件系统内可原子替换文件；它仅封装rename(2)，跨设备时返回EXDEV并退化为非原子拷贝删除，故必须确保临时文件与目标同目录、写后调f.Sync()、再os.Rename。
os.Rename 能否真正原子替换文件？
在 Go 中，os.Rename 本身不保证跨文件系统“原子替换”，它只是对底层 rename(2) 系统调用的封装。只有当源和目标路径位于同一文件系统（即同 mount point）时，os.Rename 才是原子的；否则会返回 syscall.EXDEV 错误，此时 Go 运行时会退化为「拷贝 + 删除」，完全失去原子性。
所以，真正的原子替换必须确保：新文件写入与重命名全程在同一文件系统上完成，且不能依赖 os.Rename 自动处理跨设备场景。
正确实现原子写入+替换的三步流程
典型做法是：先在目标目录同文件系统下创建临时文件 → 写入并 fsync 持久化 → 最后用 os.Rename 替换目标。关键不是“怎么调用”，而是“在哪写、怎么刷盘、怎么换”。
- 临时文件必须和目标文件在同一个目录（或至少同挂载点），推荐用
filepath.Join(filepath.Dir(targetPath), "tmp-"+randString(8)) - 写完后务必调用
f.Sync()（或file.Close()，它隐含Sync），否则重命名后可能读到空/截断内容 - 重命名前不用
os.Remove目标文件——os.Rename会自动覆盖（POSIX 行为），且覆盖是原子的 - 若目标文件不存在，
os.Rename仍成功；但若目标是目录，则失败（EPERM）
常见错误：用 ioutil.WriteFile 或 os.WriteFile 直接覆盖
直接调用 ioutil.WriteFile（或 os.WriteFile）写目标路径，本质是 open(O_TRUNC) + write，不是原子操作：进程崩溃或断电时，文件可能处于中间状态（如只写了一半），且无法回滚。
更糟的是，某些 Linux 文件系统（如 ext4 默认）对 O_TRUNC 的写入不保证元数据立即落盘，即使 WriteFile 返回成功，内容也可能丢失。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
对比示例：
// ❌ 危险：非原子，崩溃后文件损坏
os.WriteFile("config.json", data, 0644)
// ✅ 安全：原子替换（假设 tmp 在同文件系统）
tmp := filepath.Join(filepath.Dir("config.json"), ".config.json.tmp")
f, _ := os.Create(tmp)
f.Write(data)
f.Close() // 触发 Sync
os.Rename(tmp, "config.json")
跨文件系统或需要更高可靠性时怎么办？
如果目标路径所在磁盘空间紧张、或必须支持跨设备（比如 /tmp 是独立 tmpfs），os.Rename 必然失败，这时没有真正的原子替换，只能退而求其次：
- 把临时文件放在目标目录同分区（如用
os.Stat检查Stat.Sys().(*syscall.Stat_t).Dev判断是否同设备） - 使用
filepath.EvalSymlinks解析符号链接，避免因挂载点嵌套误判 - 生产环境建议加校验：写临时文件后计算 SHA256，重命名前比对；或用
os.Link+os.Remove做硬链接切换（仅限同设备，且需注意 inode 引用计数）
最易被忽略的一点：很多开发者以为 os.Rename “成功返回”就万事大吉，其实没检查 Sync 是否真完成，也没验证目标文件权限/属主是否继承自临时文件——这些细节在容器或 NFS 环境下极易出问题。
