zap.NewProduction()默认同步写入且无缓冲，高并发下write()系统调用阻塞业务goroutine，需手动配置AddSync、Lock及正确EncoderConfig才能实现真正高性能。
直接用 zap.NewProduction() 不等于高性能，漏掉关键配置时吞吐可能比标准库 log 还低。
为什么 zap.NewProduction() 在高并发下仍会卡住 HTTP handler
zap.NewProduction() 默认仍是同步写入，底层用的是裸 *os.File 或 os.Stderr，没有缓冲、没有 goroutine、不带超时控制。压测时常见 pprof 卡在 syscall.Syscall 或 runtime.futex，本质是 write() 系统调用阻塞了业务 goroutine。
- 磁盘慢（比如云盘 IOPS 不足）或日志目标是网络 sink（如 Kafka、Loki）时，延迟直接传导到接口响应
- 它只优化了编码路径（零分配、无反射），没动 I/O 路径——这是“高性能”的常见误解点
- QPS 超 800 后，日志写入常成为 P99 延迟毛刺主因，尤其在 Gin/Echo 的中间件里高频打点时
必须显式配置的三个 WriteSyncer 组件
真异步不是加个 go logger.Info() 就行，Zap 要求你手动组装 zapcore.Core，缺一不可：
-
zapcore.AddSync()：必须包一层，不能直接传*os.File；否则多 goroutine 写文件会 panic -
zapcore.Lock()：生产环境必须套在AddSync外层，防并发写冲突；lumberjack.Logger自带锁，但裸os.OpenFile不带 - 文件打开模式要含
os.O_APPEND和os.O_SYNC（或依赖lumberjack的LocalTime+Compress配置），否则进程崩溃时最后几条日志大概率丢失
字段命名不一致导致日志平台查不到数据
Zap 默认字段名是小驼峰（httpStatus、reqId），但 Loki、Datadog、阿里 SLS 等默认按蛇形（http_status、req_id）建索引。字段名对不上 → 字段未被提取 → status:500 查不到任何日志。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 别用
zap.Fields手动转字段名，开销大且易漏；应换编码器：EncoderConfig里设FieldKey系列字段，比如LevelKey: "level"、MessageKey: "msg" -
TimeKey设为"t"，EncodeTime用zapcore.ISO8601TimeEncoder，避免time.Now().Format()触发 GC 分配 - 如果用了 Gin 官方中间件
ginzap.Logger()，注意它默认字段是蛇形，但zap.NewProduction()初始化的 logger 是小驼峰——混用会导致字段混乱
Logger 实例复用与 context 注入的坑
HTTP handler 里每次调用 logger.With(zap.String("req_id", ...)) 创建新实例，字段多时每秒分配数万小对象，GC 压力陡增；而用 context.WithValue 传 logger，panic 恢复后上下文可能已失效。
- 更稳做法：把
*zap.Logger塞进 handler struct receiver，比如type APIHandler struct { logger *zap.Logger }，避免闭包捕获或 context 频繁分配 - 通用字段（
service、env、version）应在全局 logger 初始化时就.With()固化，请求级字段（req_id、path）才在 middleware 里叠加 - 切忌在 middleware 里调用
logger.Sync()—— 它会阻塞整个请求链；应在进程退出前统一调用一次，或用lumberjack的Rotate回调自动 flush
最易被忽略的是：Zap 的“高性能”严格依赖初始化时那几行配置，少一个 Lock、错一个 EncoderConfig 字段、漏掉 os.O_SYNC，线上跑三天后就会发现日志延迟越来越高、查不到错误、GC Pause 突然飙升——这不是 bug，是配置没对齐。
