默认 log 包在高并发下性能差，因其同步写入、每次调用都加锁/格式化/刷盘；zap 通过零分配、异步写入和结构化前置快 4–10 倍，推荐线上用 zap.NewProduction() 配合结构化日志。
为什么默认的 log 包在高并发下会拖慢程序
Go 标准库 log 包底层使用 os.Stderr（或自定义 io.Writer）同步写入，每次调用 log.Println 都会加锁、格式化、写入、刷盘。在 QPS 上千的 HTTP 服务或批处理场景中，这会成为明显瓶颈——你可能观察到 CPU 并不高，但 p99 延迟陡增，pprof 显示大量时间卡在 log.(*Logger).Output 和 syscall.Syscall 上。
关键问题不在“日志内容多”，而在于：同步 I/O + 每次调用都做完整格式化 + 全局互斥锁。
- 避免在 hot path（如 HTTP handler 内部、循环体）直接调用
log.Printf - 不要把
log.SetOutput指向未缓冲的网络连接或慢磁盘文件 - 即使换成
log.SetFlags(0)去掉时间戳，锁和格式化开销仍存在
zap.Logger 为什么比 log 快 4–10 倍
zap 是 Uber 开源的结构化日志库，其性能优势来自三处硬优化：
- 零内存分配（zero-allocation）路径：对常见类型（
int,string,bool）直接写入预分配的 buffer，不触发 GC - 异步写入可选：通过
zap.NewAsync将日志 entry 推入 channel，由后台 goroutine 批量刷盘 - 结构化前置：字段以
zap.String("key", val)形式传入，避免运行时反射或 fmt.Sprintf 解析模板字符串
实测对比（10 万条 INFO 日志，SSD）：
- 标准 log：约 1.2s
- zap.NewDevelopment()：约 280ms
- zap.NewProduction().WithOptions(zap.WithCaller(false))：约 140ms
注意：zap.NewDevelopment() 含堆栈、颜色、caller 信息，适合本地调试；线上请用 zap.NewProduction() 并关闭非必要字段。
立即学习“go语言免费学习笔记（深入）”；
如何安全地替换 log.Printf 为 zap.Sugar()
zap.Sugar() 提供类似 log.Printf 的自由格式接口，是平滑迁移最实用的入口。但它不是“零成本”封装——每次调用仍需将 interface{} 参数转为 zap.Field 数组，有少量反射开销。
- 高频日志（如每请求一次的 trace log）优先用
zap.Logger的结构化方法：logger.Info("request finished", zap.String("path", r.URL.Path), zap.Int("status", w.Status())) - 临时调试可用
sugar.Infow("slow query", "sql", sql, "duration_ms", dur.Milliseconds())，字段名必须是字符串字面量 - 绝对避免
sugar.Infof("user %s logged in at %v", name, time.Now())—— 这会丢失结构化能力，且格式化开销比Infow大 - 初始化时缓存
*zap.Logger或*zap.SugaredLogger，不要每次函数调用都zap.NewXXX()
日志写入层的隐藏瓶颈：文件句柄与 syscall
即使用了 zap，若输出目标是单个文件（如 os.OpenFile(..., os.O_APPEND)），仍可能因系统级串行化导致吞吐下降。Linux 下 O_APPEND 要求每次 write 前 seek 到文件末尾，内核需加锁。
- 生产环境务必启用日志轮转（
lumberjack.Logger或zapcore.AddSync包装） - 避免在日志 writer 中做任何阻塞操作（如网络请求、数据库查询）
- 如果日志量极大（>10MB/s），考虑用
file-rotatelogs等支持原子重命名的轮转器，而非简单 rename - 容器环境中，优先输出到 stdout/stderr，由日志采集器（fluentd / filebeat）统一收集——这比进程内写文件更可靠、更易扩容
真正卡住性能的，往往不是日志内容本身，而是你没意识到：日志最终落盘那一下，正排队等内核调度。
