别把直接调用 log.Println() 理解成“异步写盘”——它内部本质上还是同步执行 file.Write()，既没有缓冲，也没有批量处理，更谈不上背压控制。

结果很直接：一旦遇到高 QPS，P99 延迟就容易明显飙升；进程退出时，日志也可能来不及落盘而丢失。

更稳妥的做法是，采用带缓冲的 channel + 单写 goroutine + bufio.WriterSize(16KB) + 按需 Sync 这一套组合，同时还要保证 writer 本身具备线程安全。

为什么直接 go log.Println() 不算异步写盘

说白了，它只是把 goroutine 挪到了调用这一侧。log.Println() 在内部该同步调用 file.Write()，还是同步调用。

它既没有缓冲，也没有批量处理，更谈不上背压控制。

结果也很直观：一旦 QPS 拉高，P99 延迟就会明显飙升。pprof 里还能看到大量时间耗在 syscall.Syscall 上。

更麻烦的是，进程退出时，那些没来得及落盘的日志会直接丢掉。单靠 defer file.Close()，根本补不回来。

必须设带缓冲的 channel + 单写 goroutine

这是避免并发写冲突和 OOM 的底线。多 goroutine 直接往同一个 *os.File 写，即使开了 O_APPEND，ext4/xfs 下仍可能因内核页缓存导致行粘连或截断。

缓冲大小不能拍脑袋定。

• make(chan *LogEntry, 1024) 是安全起点，低于 256 容易满丢日志
• 高于 8192 会拉高 P99 延迟（尤其磁盘慢时），实测 4096 是多数服务的平衡点
• 别用无缓冲 channel —— 一卡全卡，主流程直接被拖死

bufio.Writer 必须显式指定 buffer size

默认 bufio.NewWriter(file) 只给 4KB 缓冲，攒不满就 flush。这样会导致频繁系统调用，反而更慢。

关键点如下：

• 用 bufio.NewWriterSize(file, 16*1024)，16KB 能较好平衡延迟与内存占用
• w.Flush() 只刷到内核 buffer，对 ERROR/audit 级别日志，后面必须跟 file.Sync()
• 别在每次写完都 Sync() —— 那就退化成同步写，每秒 3k 条日志时毛刺明显

Zap 的 NewAsyncCore 不是套个 goroutine 就完事

很多人以为 go logger.Info() 就是异步，其实 zap.NewProduction() 底层仍是同步写。

真要异步，必须用 zapcore.NewAsyncCore。

• 传入的 writer 得是 zapcore.WriteSyncer，比如 zapcore.AddSync(zapcore.Lock(lumberjackLogger))
• bufferSize 设 4096～8192，太小丢日志，太大延迟不可控
• 高频行为日志（如点击、评分）可走异步通道，但 DB 连接失败这类关键错误，得单独配一个 os.O_SYNC 的文件直写

最易被忽略的是 writer 的并发安全性。*os.File 本身不支持并发写，必须包一层 zapcore.Lock 或用 lumberjack.Logger 这类线程安全封装。

否则，哪怕用了 NewAsyncCore，日志内容照样错乱。

《夸克》非常好用的免费AI浏览器

下载APP查看