Go 的 os.Rename 同一文件系统内原子，但跨设备失败；临时文件须与目标同目录、用 os.CreateTemp 创建，写完先 tmp.Sync() 再 tmp.Close()，最后 os.Rename，Windows 需处理目标存在情况。
Go 的 os.Rename 在大多数文件系统上确实是原子的，但仅限同目录内
关键判断：直接用 os.Rename 替换目标文件（比如先写到 tmpfile，再重命名为 target.txt）是可行的，但前提是源和目标必须在同一个文件系统、同一挂载点下。跨分区或跨磁盘时，os.Rename 会失败并返回 invalid cross-device link 错误。
常见错误现象：rename /tmp/xxx.tmp /data/xxx.txt: invalid cross-device link —— 这不是 bug，是 POSIX 行为，Go 只是透传了系统调用结果。
- 使用场景：日志轮转、配置热更新、数据库快照保存等需要“要么全写完，要么完全不生效”的场合
- 正确做法：临时文件必须和目标文件放在同一目录（或至少同挂载点），例如都放在
/data/下，而不是一个在/tmp/一个在/data/ - 检查方式：用
df -P /path/to/target和df -P /path/to/temp看是否显示相同文件系统（Filesystem列）
临时文件必须用 os.CreateTemp，不能手拼路径或用 os.OpenFile + os.Chmod
手动生成临时文件名（比如 "config.json." + strconv.FormatInt(time.Now().Unix(), 10)）有竞态风险：两个 goroutine 可能生成相同名字，导致覆盖或 file exists 错误；而用 os.OpenFile 创建后再改权限，中间存在短暂窗口期，可能被其他进程读到未写完的内容。
os.CreateTemp 内部调用 mkstemp(3)，保证文件创建+打开一步完成，且默认权限为 0600（仅属主可读写），天然规避竞态和权限泄露。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 示例：
tmp, err := os.CreateTemp(filepath.Dir(targetPath), "config-*.json") - 写完后务必先
tmp.Close()，再调用os.Rename—— 否则 Windows 下会报The process cannot access the file because it is being used by another process - 不要对
tmp手动os.Chmod：如果目标文件需要特定权限（如0644），应在os.Rename后对新文件调用os.Chmod(targetPath, 0644)
Windows 下 rename 不支持覆盖已有文件，得先删
Windows 的 MoveFileEx（Go 的 os.Rename 底层调用）默认不允许覆盖目标路径。所以如果你的目标文件已存在，os.Rename 会直接返回 Access is denied 或 The system cannot move the file to a different disk drive（即使没跨盘）。
解决方法不是绕开 rename，而是提前清理目标——但必须小心：不能用 os.Remove 后立刻 os.Rename，否则存在极短时间窗口，让其他进程看到“文件消失”状态。
- 标准做法：先
os.Rename临时文件到目标路径；如果失败且错误是os.ErrExist（或 Windows 下的特定 error），再os.Remove目标文件，然后重试os.Rename - 更稳妥的封装：用
golang.org/x/exp/slices或手动循环 2 次，避免无限重试；注意捕获os.IsNotExist和os.IsPermission等真实错误退出 - 别依赖
os.SameFile判断是否要覆盖——它只比较 inode，对原子写入无意义
写入内容前记得 sync，否则 rename 后可能读到脏数据
Linux/macOS 下，os.Rename 原子的是“目录项修改”，不是“数据落盘”。如果只调用 Write 就 Rename，而没 Sync，那重命名后的文件在系统崩溃或断电时，可能内容仍是空或截断的。
这不是 Go 特性，是所有语言共有的 fsync 语义问题。尤其在 SSD 或带 write-back cache 的 RAID 卡上更明显。
- 必须在
tmp.Close()前调用tmp.Sync()（或tmp.Write后立即tmp.Sync()） - 不要省略：虽然慢一点，但这是换取原子性的必要代价；若性能敏感，可考虑用
fsync替代sync（需syscall调用），但普通场景tmp.Sync()足够 - 注意：Windows 下
Sync()对*os.File是空操作（文档明确说明），但为了跨平台一致性，仍建议保留 —— 它不会出错，只是没效果
真正容易被忽略的是 sync 时机：很多人以为 close 就等于刷盘，其实不是。close 只关闭 fd，数据还在 page cache 里。原子性链条是 “write → sync → close → rename”，漏掉 sync，整个原子保证就垮了。
