Go的log.Printf写文件不实时，因默认使用带缓冲的os.Stderr/Stdout，改写文件时若未显式设置无缓冲或强制刷新，日志会滞留缓冲区；解决方法包括用os.O_SYNC标志直落磁盘，或用bufio.NewWriter配合手动Flush()。
为什么直接用 log.Printf 写文件不实时？
Go 的 log 默认使用带缓冲的 os.Stderr 或 os.Stdout，写入文件时若用 os.File 但没显式设置无缓冲或强制刷新，日志会卡在缓冲区里，尤其进程未退出时根本看不到最新内容。常见现象是：程序还在跑，但文件里日志停在几秒前。
- 默认
log.SetOutput(file)不等于“实时”，只是把输出目标换了 -
file.Sync()能刷磁盘缓存，但太重；file.Write()后不file.Flush()（如果包装了bufio.Writer）照样不生效 - 真正实时的关键是：绕过缓冲，或控制缓冲行为
用 os.OpenFile + log.SetOutput 配合 O_SYNC
最轻量、无第三方依赖的方案：打开文件时带上 os.O_SYNC 标志，让每次写都直落磁盘（跳过内核页缓存）。适合低频日志（如调试、配置变更记录），不推荐高频场景（性能损耗明显）。
file, err := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND|os.O_SYNC, 0644)
if err != nil {
log.Fatal(err)
}
defer file.Close()
log.SetOutput(file)
log.Println("this appears immediately")
-
O_SYNC是系统级保证，比用户层Flush()更彻底 - 注意 Windows 下部分版本对
O_SYNC支持不稳定，可降级为O_WRONLY | O_APPEND+ 手动file.Sync()（见下条） - 别漏掉
os.O_APPEND，否则日志会覆盖而非追加
用 bufio.NewWriter 控制刷新时机
想兼顾性能和可控实时性，就自己包一层带缓冲的写入器，按行或按大小触发刷新。这是生产环境更常见的做法。
w := bufio.NewWriterSize(file, 4096)
log.SetOutput(w)
log.Println("buffered line")
w.Flush() // 手动刷一次
- 调用
w.Flush()立即写出缓冲内容，适合关键日志后立刻落盘（如错误、状态切换） - 也可以启动 goroutine 定期
Flush()（比如每 200ms），避免频繁刷盘又不至于延迟太久 - 切记：如果用
bufio.Writer，必须自己管理Flush()，log包不会帮你调 - 缓冲区大小设太小（如 128）反而增加系统调用次数，4KB~8KB 是较稳妥起点
为什么不用 logrus 或 zap 的文件写入器？
它们内置的 FileHook 或 WriteSyncer 确实封装了刷新逻辑，但默认仍可能缓冲——比如 logrus 的 FileHook 用的是普通 os.File，不自动 Sync()；zap 的 os.File 实现默认也走内核缓冲。
立即学习“go语言免费学习笔记（深入）”；
- 用
logrus时，需配合logrus.WithField(...).Info(...)后手动file.Sync()，或改用rotatelogs这类支持Sync的轮转库 -
zap推荐用zapcore.Lock(zapcore.AddSync(file))，它内部已做file.Sync()，但要注意并发安全 - 第三方库解决的是轮转、分级、结构化等需求，不是“实时”这个底层问题本身
实时的本质是 I/O 模式选择，不是日志库功能多寡。缓冲策略一旦选错，再好的库也白搭。
