defer f.Close() 不总是安全：它不检查错误、不保证落盘，需显式调用f.Sync()并检查Close()返回值；多goroutine共享文件句柄须加锁；panic时defer可能未注册。
defer f.Close() 不总是安全的
很多人以为只要在 os.Open() 后紧跟 defer f.Close() 就万事大吉，但这是错觉。如果 f.Close() 失败（比如磁盘只读、NFS 挂载异常、文件系统已卸载），defer 会静默吞掉错误，你完全感知不到资源是否真正释放成功。
- 必须检查
f.Close()的返回值，尤其在关键写入流程后 -
defer只保证调用，不保证成功；它适合「尽力而为」场景，不适合「必须成功」场景 - 若函数提前 return，
defer仍会执行，但错误无处上报 —— 除非你把它显式赋给命名返回值或记录日志
写文件后 close 前必须显式 sync
调用 f.Close() 并不等于数据已落盘。Go 的 *os.File 底层使用系统 write 缓冲，Close() 只触发内核 flush，但不等待 fsync。遇到断电或 crash，刚写的内容可能丢失。
- 需要持久化保障时，务必在
f.Close()前调用f.Sync() -
f.Sync()会阻塞直到数据和元数据（如 mtime）都刷入磁盘，性能有代价，但不可省略 - 注意：某些文件系统（如 ext4 默认）对
fsync行为有差异；O_SYNC打开可绕过用户缓冲，但会显著降低吞吐
fd, err := os.OpenFile("data.txt", os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
log.Fatal(err)
}
defer fd.Close() // 这里 defer 仅用于兜底，主逻辑不能依赖它
_, err = fd.Write([]byte("hello"))
if err != nil {
log.Fatal(err)
}
if err := fd.Sync(); err != nil { // 关键：确保落盘
log.Fatal("sync failed:", err)
}
if err := fd.Close(); err != nil { // 再检查 close 是否成功
log.Fatal("close failed:", err)
}
多 goroutine 共享文件句柄要加锁
Go 的 *os.File 本身是并发安全的（read/write 方法内部有锁），但「业务语义上的共享」常带来隐性竞争：比如多个 goroutine 轮流 Write 后都打算 Close()，就可能触发 double-close 或写入截断。
- 不要让多个 goroutine 都持有同一
*os.File并各自决定何时关闭 - 推荐模式：由创建者统一管理生命周期，用 channel 或
sync.WaitGroup协调写入完成，再集中Close() - 若必须分散关闭，用
sync.Once包裹Close()，避免重复调用导致EBADF
panic 场景下 defer 可能来不及执行
当 goroutine 因 panic 而终止，且未被 recover() 拦截时，该 goroutine 中所有 defer 仍会执行 —— 但前提是 panic 发生在 defer 注册之后。如果 open 失败直接 panic，defer f.Close() 根本没注册上。
- 更稳妥的方式是：open 成功后立即注册 defer，或用带错误检查的封装函数
- 在测试中模拟 panic（如
defer func(){ if r := recover(); r != nil { /* close here */ } }()）无法替代真实资源清理逻辑 - 长期运行服务中，建议用
runtime.SetFinalizer做最后防线（但不保证及时性，仅作兜底）
实际项目里最常被忽略的是：close 错误未检查 + sync 缺失。这两点加起来，会让「文件已保存」变成「大概率保存了」。
