os.writefile 不保证数据落盘，需额外调用 sync() 或使用同步标志；其原子性仅限文件内容替换，写入停留在页缓存，未达物理介质。
os.WriteFile 写完就完事？不，它不保证落盘。真要“写入即持久”，必须额外加 Sync() 或改用同步标志——否则断电、崩溃、云盘缓存透传失败，数据大概率丢。
为什么 os.WriteFile 不能当持久化用
os.WriteFile 是原子覆盖操作，但仅限于“文件内容替换”层面的原子性，和物理落盘无关。它内部等价于：os.OpenFile + file.Write + file.Close()，而 Close() 不触发 fsync(2)。
- 写入数据只进内核页缓存（page cache），没进块设备缓存，更没到 NAND/磁盘介质
- SSD/云盘若开启 write-back 缓存（
hdparm -I /dev/sdX | grep "Write cache"可查），Sync()都可能空转 - 文件系统挂载参数如
data=writeback（ext4）或barrier=0，会让元数据也不保序 - 错误现象：程序退出后文件内容“回滚”到旧版本；日志看似写入，实则重启后消失
真正落地的三种刷盘路径
没有银弹，只有按场景选对组合：
-
简单覆盖 + 强持久：不用
os.WriteFile，改用os.OpenFile手动控制流程：os.O_CREATE | os.O_WRONLY | os.O_TRUNC→file.Write→file.Sync()→file.Close() -
追加写 + 低开销持久：开文件时用
unix.Open（golang.org/x/sys/unix）传unix.O_DSYNC标志，每次Write后隐式fdatasync(2)，跳过元数据刷盘，比O_SYNC快 10%–30% -
原子更新 + 安全兜底：写入临时文件（如
data.json.tmp）→file.Sync()→os.Rename()。注意：os.Rename()在同分区 ext4/xfs/NTFS 上是原子的，但跨分区会退化为 copy+delete，不可靠
Sync() 调用前必须检查的三件事
file.Sync() 返回 nil ≠ 数据已落盘。它只代表内核接受了 fsync(2) 请求，后续是否真刷下去，取决于下层栈：
- 确认 SSD/NVMe 支持并启用了 flush 命令（
nvme get-feature -H -f 0x08 /dev/nvme0n1查 FLUSH；SATA 用hdparm --fibmap+FLUSH CACHE EXT） - 云盘或 RAID 卡需明确文档是否透传
fsync；AWS gp3/io2、GCP pd-ssd 默认透传，但某些托管 Kubernetes 存储插件会拦截 - 务必在
file.Sync()前调用file.Write的返回值检查——如果Write本身只写了部分字节（如磁盘满、权限错），Sync()会成功，但数据不全
最容易被忽略的硬件层失效点
所有软件层的 Sync()、fdatasync()、O_SYNC，在以下情况都会静默失效：
- 主板 BIOS 中 SATA/AHCI 模式下启用了 “Native Command Queuing + Write Cache”，且未配
hdparm -W0 - NVMe 设备固件禁用了 volatile write cache flush（可通过
nvme get-feature检查 bit 5 of feature 0x08） - 使用
bufio.Writer时忘了先wr.Flush()——Sync()只刷内核缓存，buf 里的数据还在内存里
真要验证，得做断电测试：写完 Sync() 后立刻拔电源，重启看数据是否一致。日志、WAL、密钥文件这类，别信文档，只信实测结果。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
