os.writefile 默认原子写入仅在同文件系统内有效；跨分区时因临时文件与目标不在同一挂载点，rename 会失败并退化为非原子的删旧+拷贝流程。
os.WriteFile 默认就做原子写入，但只在**同文件系统内有效**，跨分区、Windows 上目标被占用、权限不匹配时都会退化为非原子行为——别盲目信任它。
为什么 os.WriteFile 有时不原子
它内部确实是先写临时文件再 os.Rename，但这个“临时文件”默认建在系统临时目录（如 /tmp），而你的目标文件可能在 /home/app/config.json。一旦两者不在同一挂载点，os.Rename 就会返回 invalid cross-device link 错误，此时 Go 会 fallback 到“删旧→拷贝→重命名”流程，中间态完全可见。
- Linux/macOS 下用
df -P /path看 Filesystem 字段是否一致 - Windows 下注意：NTFS 卷内才安全；跨卷或 FAT32 不保证原子
-
os.WriteFile不检查目标是否被其他进程打开读取，Windows 下直接rename会失败并报Access is denied
自己实现原子写入的最小可靠路径
绕过系统临时目录，把临时文件和目标文件放在同一目录下，手动控制生命周期：
- 用
os.CreateTemp(filepath.Dir(target), "prefix-*.tmp")创建临时文件（自动带随机后缀，防并发覆盖） - 写完后必须调
f.Sync()——f.Close()不保证数据落盘，断电就丢 - 重命名前，Windows 建议先
os.Remove(target)（但要 catch error，避免目标不存在时报错） - 重命名后，再用
os.Chmod(target, perm)显式设权限；不要对临时文件Chmod，那会破坏 0600 安全隔离
Windows 下 rename 失败怎么办
不是 bug，是 Windows 文件锁机制使然：os.Rename 底层调 MoveFileW，默认不覆盖已打开的文件。遇到 The process cannot access the file because it is being used by another process 时：
- 先检查错误是否为
syscall.ERROR_ACCESS_DENIED（需导入syscall包） - fallback 到
syscall.MoveFileEx，传MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH - 别用“删旧→写新”逻辑：删成功但写失败，文件就彻底消失了
大文件或高并发场景的坑
单次 os.WriteFile 把整个 []byte 加载进内存，100MB+ 就容易 OOM；多个 goroutine 共用一个临时文件名（比如硬编码 "config.tmp"）会导致相互覆盖。
- 超大字节数组改用
os.Create+io.Copy或分块Write，边读边写 - 并发写同一目标文件时，临时文件名必须带唯一标识（
os.CreateTemp自带） - 若需多进程安全（不止是多 goroutine），得加
syscall.Flock排他锁，否则 rename 可能被并发读进程看到中间态
Sync。其余都是围绕这两条展开的容错和适配。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
