Go 的 file.Sync() 不能完全保证数据落盘，仅将内核页缓存脏页刷至块设备驱动层，不控制磁盘控制器或 SSD 是否写入物理介质。
Go 的 file.Sync() 真的能保证落盘吗？
不能完全保证，但它是目前标准库里最接近“真正写入磁盘”的操作。它的作用是把内核页缓存（page cache）里的脏页强制刷到块设备驱动层——至于磁盘控制器或 SSD 是否立刻把数据写进闪存颗粒，Sync() 不管，也管不了。
常见错误现象：Write() 返回成功、Sync() 也返回 nil，但断电后文件内容丢失；或者用 dd if=/dev/zero of=test bs=1M count=100 && sync 手动刷盘后数据还在，而 Go 程序没调 Sync() 就退出，结果没了。
- 必须在
Write()（或WriteString()等）之后、Close()之前调用，否则可能只刷了部分数据 -
Close()内部不自动调Sync()，哪怕你用的是os.Create()或os.OpenFile(..., os.O_SYNC)—— 后者只影响单次Write()行为，不是全程同步 - Windows 下
Sync()对普通文件效果有限，因为 NTFS 默认延迟写入，需配合FILE_FLAG_WRITE_THROUGH（Go 标准库未暴露该 flag）
什么时候必须手动调 Sync()？
不是所有写文件场景都需要它，但以下情况不加就容易出问题：
- 写关键日志（如支付流水、审计记录），要求“写完即持久化”，不能依赖后续
Close()或系统后台刷盘 - 生成配置文件后立刻要被另一个进程读取（比如热重载），且不能接受几秒延迟
- 实现 WAL（预写式日志）或自定义事务逻辑，需要严格控制落盘顺序
- 测试中模拟断电行为（如用
kill -9杀进程），想验证数据一致性
反例：批量写入临时缓存文件、离线数据导出、非关键中间结果——这些场景用 Sync() 反而拖慢性能，得不偿失。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
Sync() 和 O_SYNC、O_DSYNC 的区别在哪？
三者目标一致，但作用层级和开销不同：O_SYNC 是打开文件时的 flag，让每次 Write() 都等数据落盘；Sync() 是显式调用，可控粒度更细；O_DSYNC 只保证数据写入，不保证元数据（如 mtime、size），适合高频小写场景。
-
O_SYNC开销最大，每次Write()都触发一次完整刷盘，不适合循环写多条记录 -
O_DSYNC在 Linux 上可用，Go 中需用syscall.Open()或第三方包（如golang.org/x/sys/unix）设置，os.OpenFile()不支持传入 -
Sync()最灵活：可写完一批再刷一次，也能在关键点单独刷，但得自己记住时机 - macOS 不支持
O_DSYNC，O_SYNC行为等价于O_DSYNC（只刷数据），这点容易踩坑
实际写法：别只写 file.Sync() 就完事
一个看似正确的调用，可能因错误处理缺失或位置不对而失效。
- 必须检查返回值：
if err := file.Sync(); err != nil { /* 处理 error */ }，忽略它等于没写 - 别在
defer file.Close()里塞Sync()——defer是后进先出，Sync()会比Close()先执行，而Close()内部可能还有缓冲写入 - 推荐模式：
Write()→ 检查 err →Sync()→ 检查 err →Close()→ 检查 err - 如果写入量大，考虑用
bufio.Writer+ 定期Flush()+ 关键点Sync()，而不是每行都Sync()
最常被忽略的一点：Sync() 成功只代表数据到了内核块层，不代表磁盘物理介质已更新。真要强一致性，得用带电池缓存的 RAID 卡、禁用磁盘写缓存（hdparm -W0），或者上分布式日志系统——Go 的 Sync() 到不了那层。
