直接 os.WriteFile 不安全，因缺乏原子性：崩溃致文件损坏，并发读写现脏数据；应先写同目录临时文件再 os.Rename，必要时加 tmpFile.Sync() 保障落盘。
为什么直接 os.WriteFile 不够安全
直接覆盖原文件会丢失原子性：写入中途崩溃，文件就变成半截内容；并发读写时可能读到损坏状态。Linux/macOS 的 rename 系统调用是原子的，但必须确保源路径和目标路径在同一个文件系统上——跨分区 rename 会失败并回退为拷贝+删除，失去原子性。
- 检查是否同分区：
stat -f -c "%d" /path/to/dir（Linux）或stat -f -c "%f" /path/to/dir（macOS），对比两个路径的 device ID - 临时文件必须与目标文件在同一目录下，否则
os.Rename可能 silently 失败（尤其在 Windows 上行为不一致） - 不要用
filepath.Join(os.TempDir(), "tmp")——它几乎肯定不在目标目录所在分区
标准做法：先写临时文件再 os.Rename
核心逻辑是三步：1）在目标目录创建带随机后缀的临时文件；2）写入完整内容；3）调用 os.Rename 替换原文件。这能保证要么全成功，要么原文件完好无损。
tmpFile, err := os.Create(filepath.Join(filepath.Dir(targetPath), "."+filepath.Base(targetPath)+".tmp"))
if err != nil {
return err
}
defer os.Remove(tmpFile.Name()) // 失败时清理，但注意：成功后需手动清除残留（见下一条）
if _, err := tmpFile.Write(data); err != nil {
tmpFile.Close()
return err
}
if err := tmpFile.Close(); err != nil {
return err
}
if err := os.Rename(tmpFile.Name(), targetPath); err != nil {
return err
}
- 临时文件名加点号前缀（如
.config.json.tmp）可避免被其他程序误读 -
defer os.Remove在函数退出时清理，但os.Rename成功后不会触发——必须显式删除旧临时文件（如果存在）或依赖下次调用覆盖 - 写入后务必
Close()，否则os.Rename在某些系统上会失败（资源占用）
Windows 下的额外陷阱
Windows 对正在打开的文件禁止 rename，哪怕只是只读打开。如果目标文件被其他进程（比如文本编辑器、日志轮转工具）以共享模式打开，os.Rename 会返回 Access is denied 错误。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 无法绕过——这是 Windows 文件系统语义限制，不是 Go 实现问题
- 常见缓解方式：重试 + 退避（例如 3 次，每次间隔 10ms），但不能无限等
- 若业务允许，改用
os.WriteFile配合文件锁（flock不可用，可用golang.org/x/sys/windows调用CreateFile加锁），但复杂度陡增 - 别指望
os.Chmod或os.Symlink替代——它们都不提供原子替换语义
要不要 fsync？什么时候必须加
默认情况下，WriteFile 和 os.File.Write 不保证数据落盘，断电或内核崩溃可能导致临时文件内容丢失，进而让 os.Rename 替换出空/损坏文件。
立即学习“go语言免费学习笔记（深入）”；
- 关键场景（如配置、数据库快照、金融交易记录）必须在
Close()后调用tmpFile.Sync() - 注意顺序：
Write→Close→Sync（Sync必须在Close后，否则无效） - 性能代价明显：一次原子更新从微秒级升至毫秒级，SSD 上约 1–5ms，HDD 更长
- 不是所有场景都需要：日志缓冲、临时缓存等可接受丢失，就不必
Sync
原子性只解决“全有或全无”，不解决“落盘可靠性”。这两层保护要分开评估，漏掉 Sync 是生产环境最常被忽略的环节。
