默认Zap Logger不能直接用于生产环境，因其development模式日志含颜色、堆栈、展开字段，体积大、难解析、性能差；生产需用zap.NewProduction()或自定义JSON encoder以支持Loki/ELK等结构化采集。
为什么默认的 Zap Logger 不能直接用在生产环境
它默认输出的是 development 模式日志，带颜色、堆栈、字段展开，体积大、解析难、性能差。线上服务需要的是结构化、低开销、可被日志系统（如 Loki、ELK）自动提取字段的日志。
- 开发模式下
zap.NewDevelopment()会启用ConsoleEncoder，每条日志都带换行和缩进，CPU 和 I/O 开销高 - 生产必须用
zap.NewProduction()或手动配置json.Encoder，否则日志字段无法被 fluentd / filebeat 正确解析 - 注意：
zap.NewProduction()默认禁用 caller 字段（即不打文件名和行号），如需保留，得显式开启zap.AddCaller()
如何安全地把 context.Context 中的 traceID 注入到每条 Zap 日志
别用全局变量或包级 logger 塞 traceID —— 并发下会串；也别每次 logger.With(...) 手动传，容易漏。正确做法是封装一个带 context 支持的 logger 实例。
- 从
context.Context中取值推荐用自定义 key 类型（如type ctxKey string），避免字符串 key 冲突 - 封装函数如
WithContext(ctx context.Context) *zap.Logger，内部调用logger.With(zap.String("trace_id", tid)) - 注意：
logger.With()返回新实例，原 logger 不变；但频繁调用会分配小对象，高并发场景建议复用带 traceID 的 logger 实例（比如绑定到 HTTP request scope） - 示例：
logger.With(zap.String("trace_id", getTraceID(ctx))).Info("request handled")
Zap 的 Syncer 配置不当会导致日志丢失
日志写入磁盘不是即时的，Zap 默认用 os.Stdout 或 os.Stderr 的 Syncer，但如果你自己包装了文件句柄，没做 sync 或没调用 Sync()，进程崩溃时最后一段缓冲日志就没了。
- 用
zapcore.AddSync()包装文件时，确保该文件以os.O_SYNC打开，或定期调用logger.Sync()（比如在 HTTP handler 结束后） - 更稳妥的做法是用
lumberjack.Logger做轮转，并传给zapcore.AddSync()，它内部已处理Sync() - 常见错误：直接
os.OpenFile(..., os.O_CREATE|os.O_WRONLY, 0644)后塞给 Zap —— 缺少os.O_SYNC或os.O_APPEND，导致日志覆盖或丢失 - 验证方式：杀掉进程后检查最后几秒日志是否完整，尤其关注 panic 前的最后一条 log
怎么让 Zap 日志兼容 log.Printf 风格的调用又不牺牲结构化能力
直接替换 log 包的 SetOutput 行不通 —— Zap 不接受 io.Writer 接口做底层输出；但你可以用 zap.RedirectStdLog() 把标准库日志桥接到 Zap，前提是 Zap logger 已配置好。
立即学习“go语言免费学习笔记（深入）”；
- 调用顺序很重要：先创建并配置好
*zap.Logger，再调zap.RedirectStdLog(logger)，否则会 panic - 这样之后所有
log.Printf输出都会走 Zap 的 encoder 和 sink，字段变成{"level":"info","msg":"xxx"}格式 - 但注意：标准库日志没有字段，所以无法注入 trace_id、user_id 等上下文信息；适合迁移过渡期，长期仍建议统一用
logger.Info(..., zap.String(...)) - 别忘了关掉 Zap 的采样器（
zap.AddSampler(...)）—— 它对RedirectStdLog生效，可能导致部分 printf 日志被丢弃
logger.Check() 做前置判断来省掉序列化开销。 
