默认 log.Logger 因无缓冲致高并发下 syscall 过多而卡顿；应封装 bufio.Writer 并主动 Flush，或改用 zap 等异步日志库。
为什么默认的 log.Logger 会卡住你的高并发服务
Go 标准库的 log.Logger 默认使用 os.Stderr（或你传入的 io.Writer）直接写入，不带缓冲。在高频日志场景下，每次 logger.Println() 都触发一次系统调用，CPU 花在 syscall 上远多于业务逻辑。更隐蔽的问题是：若底层 Writer 是带缓冲的（比如 bufio.Writer），但没做 Flush() 控制，日志可能滞留在内存里迟迟不落盘，出问题时根本看不到最后几条关键日志。
用 bufio.Writer 包一层，但必须手动控制 Flush
这是最轻量、兼容性最好的优化方式，无需引入第三方日志库。核心是把原始 io.Writer（如文件句柄）包进 bufio.Writer，再传给 log.New()；但切记：不能依赖程序退出自动 flush —— 进程崩溃或被 kill -9 时缓冲区内容直接丢弃。
- 写入频率高（如每秒百次以上）：建议每 10–100 条日志
Flush()一次，或用定时器每 100ms 强制刷一次 - 写入频率低但日志关键（如错误/告警）：对
logger.Printf("ERROR: %v", err)后立即调用bufWriter.Flush() - 避免在 goroutine 中无锁共用同一个
bufio.Writer：它不是并发安全的，要么加锁，要么每个 goroutine 持有独立实例
file, _ := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
bufWriter := bufio.NewWriterSize(file, 64*1024) // 64KB 缓冲区
logger := log.New(bufWriter, "[INFO] ", log.LstdFlags)
// 日志写入后主动刷盘
logger.Println("request processed")
bufWriter.Flush() // 关键：不能省
zap 的 WriteSyncer 为什么比手写缓冲更可靠
如果你已用 zap，别自己套 bufio —— 它的 zapcore.LockWrap() 和内置的 BufferedWriteSyncer（在 zapcore.AddSync() 中隐式启用）已经处理了并发写、缓冲区复用、panic 安全 flush 等细节。真正要注意的是配置项：
-
EncoderConfig.EncodeLevel和EncodeTime开销不小，生产环境建议用zapcore.CapitalLevelEncoder和zapcore.ISO8601TimeEncoder，避免字符串拼接 - 日志级别过滤必须在
Core层做（如zap.LevelEnablerFunc），不要靠外围 if 判断，否则仍会进编码和缓冲流程 - 文件轮转（
lumberjack.Logger）本身不带缓冲，要确保它被包在zapcore.AddSync()里，否则轮转瞬间可能丢日志
什么时候该放弃缓冲，改用异步队列
当单机 QPS 超过 5k，且日志字段复杂（含 JSON 序列化、堆栈捕获）、落地目标是网络存储（如 Loki、ES）或磁盘 I/O 已成瓶颈时，同步缓冲收益急剧下降。此时应切换为「采集端异步」模型：
立即学习“go语言免费学习笔记（深入）”；
- 用无锁环形队列（如
github.com/Workiva/go-datastructures/queue）暂存日志结构体 - 单个后台 goroutine 消费队列，批量序列化 + 批量写入，失败时本地暂存重试
- 注意背压：队列满时，
logger.Error()可降级为fmt.Fprintln(os.Stderr, ...)直写 stderr，避免阻塞主流程
缓冲只是权衡：多留 100ms 日志延迟，换 CPU 和 I/O 减负；但线上故障排查时，最后 100ms 往往就是关键上下文。这个边界得根据你的 SLA 和可观测性要求来划。
