生产环境必须用 zap.newproduction() 初始化 logger，因其启用高性能编码器和缓冲策略；newdevelopment() 启用颜色、行号、堆栈等调试功能，导致日志体积大、cpu 高、解析失败率高，性能下降 2–3 倍。
生产环境必须用 zap.NewProduction() 初始化 logger，其他方式基本等于放弃 Zap 的性能优势。
为什么不能直接用 zap.NewDevelopment() 上生产
它不是“开发版”，而是调试专用模式：启用颜色、行号、堆栈、字段展开、换行缩进，日志体积大、CPU 高、ELK/Loki 解析失败率高。哪怕只在中间件里调用一次 logger.Debug()，只要用了 NewDevelopment()，整个 logger 实例就退化成低性能路径——ns/op 高出 2–3 倍，allocs/op 不变但 CPU 持续拉满。
- 开发阶段可用，但上线前必须显式切换为
zap.NewProduction() -
zap.NewDevelopmentConfig().Build()和NewDevelopment()底层都是ConsoleEncoder，只是多一层配置壳，同样不适用于生产 - 如果需要开发时带堆栈，加
zap.AddStacktrace(zap.ErrorLevel)即可，不用依赖NewDevelopment()默认行为
写文件时 lumberjack.Logger 怎么配才不丢日志
直接 os.OpenFile 后塞给 zapcore.AddSync 是危险的：崩溃时缓冲区未刷盘，最后几条日志就丢了；且不支持轮转，磁盘迟早打满。
- 必须用
lumberjack.Logger封装，再套一层zapcore.AddSync -
MaxSize单位是 MB（例如100= 100MB），不是 KB 或字节 - 启动前必须确保目录存在且有写权限：
os.MkdirAll(filepath.Dir("/var/log/app.log"), 0755)，否则静默失败 - 建议开启
Compress: true，但注意老版本lumberjack（如v2.2.1+incompatible）更稳
怎么让每条 HTTP 日志自动带 trace_id 且不抬高分配
别在 handler 里每次调用 logger.With(zap.String("trace_id", tid)) 创建新实例——高频分配会显著增加 allocs/op；也别改全局 logger，会引发并发污染。
- 中间件中提取
X-Trace-ID，为空则生成 UUID，然后调用logger.With(zap.String("trace_id", tid))一次，存入c.Set("logger", reqLogger) - 下游 handler 用
c.MustGet("logger").(*zap.Logger)复用该实例，避免重复构造 - 字段名统一用小写+下划线（如
trace_id），确保能被 Loki/ELK 正确提取 - 不要传结构体指针：
zap.Any("user", &u)可能引发竞态；应传值或实现zap.Object延迟序列化
结构化字段怎么写才真正零分配
zap.String("k", v) 快，是因为它返回一个预构建的 zap.Field 结构体，无反射、无字符串拼接、可内联；而 fmt.Sprintf 或 time.Now().String() 会在每次调用时强制分配，且无法被日志级别过滤掉。
- ❌ 错误：
logger.Info(fmt.Sprintf("user %d login", id), zap.String("err", err.Error())) - ✅ 正确：
logger.Info("user login", zap.Int("id", id), zap.Error(err)) - 不确定是否要记的日志，显式用
logger.Check(zap.DebugLevel, "msg").Write(zap.Int("id", id)) - 高频路径（如 DB 查询钩子、HTTP 中间件）禁用任何预计算表达式，只传原始值
最易被忽略的是 logger.Sync() 的调用时机——它只刷当前 logger 及其所有子 logger 的缓冲区。如果你用 logger.With() 创建了子 logger，又没在进程退出前调用父 logger 的 Sync()，那最后几条日志大概率就留在内存里了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
