log.Printf在高并发下性能瓶颈源于其全局互斥锁、同步格式化及stderr系统调用开销；zap通过无锁写入、结构化日志和预分配缓冲优化，推荐使用NewProduction/Development创建logger并配合lumberjack实现安全轮转。
为什么 log.Printf 在高并发下会成为性能瓶颈
因为默认的 log.Logger 内部使用了全局互斥锁（mu）保护输出，所有 goroutine 都得排队写日志。压测时常见 log.Printf 占用大量 CPU 时间，甚至拖慢主业务逻辑。
- 每次调用
log.Printf都触发一次锁竞争，尤其在日志频繁、goroutine 数量多（如 HTTP handler 每请求打 3–5 条）时尤为明显 - 默认输出到
os.Stderr，系统调用开销不可忽略；若重定向到文件且未设置缓冲，还会叠加 I/O 等待 - 格式化字符串（
sprintf）在调用方 goroutine 中同步执行，无法规避
用 zap 替代标准库日志的实操要点
zap 是目前 Go 生态中性能最接近零分配的日志库，核心优势在于结构化、无锁写入和预分配缓冲区。
- 必须用
zap.NewProduction()或zap.NewDevelopment()创建 logger，避免直接用zap.New(zapcore.NewCore(...))手动拼接——后者容易漏掉zap.AddCaller()或缓冲配置 - 结构化字段优于字符串拼接：
logger.Info("user login", zap.String("user_id", uid), zap.Int64("ts", time.Now().Unix()))，避免运行时反射和临时字符串分配 - 若需兼容旧代码，可用
zap.RedirectStdLog(zap.L())将log.Printf转发过去，但仅限过渡期，因仍会经过log的锁路径
并发写文件时如何避免 write: broken pipe 或阻塞
多个 goroutine 直接往同一个 *os.File 写，即使加锁也容易因底层 fd 被意外关闭（如 logrotate 重命名文件）导致写失败或 panic。
- 不要自己实现“多 writer 复用一个 file”——改用
lumberjack.Logger封装，它内置了 reopen 机制和原子写入，配合zap使用只需传入lumberjack.Logger作为WriteSyncer - 确保日志 writer 启用缓冲：用
zapcore.NewMultiWriteSyncer+zapcore.AddSync包裹lumberjack.Logger，而非裸写os.File - 禁止在信号处理（如
SIGHUP）中直接Close()文件句柄；应通过lumberjack的Rotate()接口触发轮转
什么时候该考虑异步日志（chan + worker）
只有当单条日志构造成本高（如含堆栈、HTTP body 截断、加密脱敏），且可接受毫秒级延迟时，才值得引入 channel 异步模型。多数场景下 zap 同步写已足够快。
立即学习“go语言免费学习笔记（深入）”；
- channel 缓冲区大小建议设为 1024–4096，过小易阻塞生产者，过大增加内存占用和延迟
- worker 必须处理 panic：在
defer中 recover 并记录错误，否则日志 goroutine 崩溃后消息永久丢失 - 不要在异步路径里做任何可能阻塞的操作（如网络请求、数据库查询），否则整个日志队列卡死
真正影响性能的往往不是“写得慢”，而是“写得错”——比如在 hot path 里反复调用 time.Now().String() 或对 map 做深拷贝再打日志。优化前先用 pprof 确认瓶颈在日志本身，而不是日志内容生成过程。
