os.rename能原子替换文件是因为其在同文件系统上本质是修改目录项inode指针，由内核保证单一不可中断；跨文件系统则退化为拷贝+删除并报invalid cross-device link错误，必须确保临时文件与目标同目录、用os.createtemp生成唯一名、写完调f.sync()再f.close()，windows下需捕获error_access_denied并fallback至movefileex。
os.Rename 为什么能原子替换文件
因为 os.Rename 在同文件系统上本质是修改目录项的 inode 指针，由内核保证为单一、不可中断的元数据操作。只要临时文件和目标路径在同一个挂载点（比如都位于 /data/ 下），就「要么全替换成功，要么完全失败」，不会出现半新半旧状态。
这不是 Go 的特性，而是 ext4、XFS、NTFS、APFS 等主流文件系统的底层语义。跨文件系统（如临时文件在 /tmp、目标在 /home）时，os.Rename 会直接返回 invalid cross-device link 错误——此时它已退化为拷贝+删除，彻底失去原子性。
验证是否同挂载点：运行 df -P /path/to/target 和 df -P /path/to/temp，比对输出中 Filesystem 列是否一致。
临时文件必须用 os.CreateTemp 且同目录
手拼路径（比如 "config.json." + time.Now().String()）在高并发或容器重启场景下极易冲突：两个 goroutine 可能生成相同名字，导致后写覆盖前写，或 file exists 报错。
os.CreateTemp 调用 mkstemp(3)，一步完成“创建+打开+权限设为 0600”，天然规避竞态与权限泄露。关键点：
- 第一个参数必须是
filepath.Dir(dst)，确保临时文件与目标同目录 - 第二个参数建议含通配符，如
"config-*.json"，让系统生成唯一后缀 - 不要手动
os.Chmod临时文件——它的 0600 是安全设计，目标文件权限应在os.Rename后单独设置
f.Sync() 不可省略，尤其对关键数据
f.Close() 不等于落盘。Linux/macOS 下 close() 仅释放 fd，不刷缓存；Windows 下甚至不保证 mtime 或权限已写入磁盘。跳过 f.Sync() 就 os.Rename，可能 rename 成功，但读出来仍是旧内容、时间戳错乱、或权限丢失。
os.WriteFile 内部不调 Sync()，也不暴露文件句柄，无法控制落盘时机，不适合需持久性的场景。
适用权衡：
- 配置文件、数据库快照、用户关键数据 → 必须
f.Sync() - 日志缓冲、临时缓存 → 可省略，靠 OS 缓冲策略即可
Windows 下 rename 失败要 fallback 到 MoveFileEx
Windows 对正在被其他进程打开读取的目标文件加共享锁，此时 os.Rename 直接返回 ERROR_ACCESS_DENIED（不是 bug，是设计如此）。标准库不自动处理该 case。
正确做法：
- 捕获错误：
if errors.Is(err, syscall.ERROR_ACCESS_DENIED) - fallback 调用：
syscall.MoveFileEx(tmp, dst, syscall.MOVEFILE_REPLACE_EXISTING|syscall.MOVEFILE_WRITE_THROUGH) - 不要先
os.Remove(dst)再写 —— 中间存在极短窗口，其他进程可能看到“文件消失”状态
Linux/macOS 不需要这步，但统一封装时建议按平台分支处理。真正容易被忽略的是：临时文件写完后必须先 f.Close()，否则 Windows 下 os.Rename 会报 The process cannot access the file because it is being used by another process。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
