Go中os.File.Write仅写入内核缓冲区，不保证落盘；需显式调用Sync()或Close()（后者隐式Sync）确保数据写入磁盘，关键场景推荐临时文件+Sync+原子重命名。
为什么 os.File.Write 返回成功却没写入磁盘？
Go 的 Write 方法只负责把数据拷贝到内核缓冲区，不保证落盘。系统可能延迟刷盘，进程崩溃或断电时，缓冲区数据就丢了。
常见现象：程序退出前没报错，但文件内容比预期少；用 cat 看文件是空的或截断的；在容器或 NFS 挂载点上更频繁。
- 调用
Write后必须跟Close()或Sync()，否则无法强制刷盘 -
Close()会隐式调用Sync()（仅当文件以写模式打开且未出错时），但不是所有场景都适用——比如你得复用文件句柄 - 别依赖
defer f.Close()就万事大吉：如果Write出错后提前 return，defer仍会执行，但此时Close()可能掩盖真正的写入失败
正确使用 Sync() 和 Close() 的顺序
最稳妥的做法是：每次关键写入后调用 Sync()，最后再 Close()。尤其适用于日志、配置保存、事务性写入等不能丢数据的场景。
示例片段：
立即学习“go语言免费学习笔记（深入）”；
f, err := os.OpenFile("config.json", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0644)
if err != nil {
log.Fatal(err)
}
defer f.Close() // 这里 defer 只保底，不替代显式 Sync
data := []byte(`{"mode": "prod"}`)
_, err = f.Write(data)
if err != nil {
log.Fatal("write failed:", err) // 不要忽略 write 错误
}
err = f.Sync() // 强制刷盘，检查是否成功
if err != nil {
log.Fatal("sync failed:", err) // 这才是数据落地的关键检查点
}
-
Sync()成本比Write高得多（触发磁盘 I/O），别在循环里无脑调用 - 若需高性能+可靠性折中，可批量写入后一次
Sync()，但得确保批量逻辑本身不丢失中间状态 - Windows 上
Sync()行为与 Linux 一致，但某些网络文件系统（如 SMB）可能忽略Sync()，需额外验证
用 os.O_SYNC 打开文件能省事吗？
可以，但代价明确：所有 Write 调用都会同步落盘，性能下降显著，且部分文件系统（如 ext4 默认挂载）会退化为 O_DSYNC（只同步数据，不保证元数据）。
- 启用方式：
os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_SYNC, 0644) - 它让每个
Write都等磁盘确认，相当于自动在每次写后加Sync()，但无法绕过内核调度延迟 - 不推荐用于高频小写入（如每毫秒写一行日志），容易拖垮吞吐；适合低频、关键单次写入（如保存用户最后操作位置）
-
O_SYNC在容器中可能被挂载选项覆盖（例如mount -o sync已启用），此时重复设置无额外效果
临时文件 + 原子重命名才是真保险
即使 Sync() 成功，如果写入中途崩溃，文件也可能处于中间状态（比如只写了一半 JSON）。真正防丢的惯用法是：写入临时文件 → Sync() → os.Rename()。
原因：Rename() 在同一文件系统下是原子操作，不会出现“只有部分更新”的情况。
- 临时文件路径建议用
filepath.Join(os.TempDir(), "myapp-"+uuid+".tmp")，避免硬编码/tmp - 务必检查
Rename()返回值：失败可能是跨设备移动（不允许），或目标被占用 - 写临时文件时仍要
Sync()，否则重命名后读到的仍是脏数据 - 注意清理残留临时文件：程序启动时扫描并删除旧的
*.tmp文件（需加锁或用唯一前缀避免误删）
数据是否真正落盘，不取决于你有没有调用 Write，而取决于你有没有确认 Sync() 成功，以及是否规避了覆盖写带来的中间态风险。临时文件 + 原子重命名是生产环境最常被忽略也最关键的一步。
