zap.NewProduction()默认仍用ConsoleEncoder输出伪JSON，非标准JSON；必须手动构造EncoderConfig并调用NewJSONEncoder，设置ISO8601TimeEncoder等参数才能输出Loki/ELK可解析的合法JSON日志。
直接用 zap.NewProduction() 不能保证输出标准 JSON 日志，它默认仍是可读文本格式；真要结构化采集，必须显式配置 JSONEncoder 并校准时间、字段名、空值等细节。
为什么 zap.NewProduction() 输出的不是合法 JSON
很多人看到 zap.NewProduction() 输出里有 {"level":"info","ts":1717784567.123,...} 就以为是 JSON，其实不是——那是 ConsoleEncoder 模拟的伪结构化格式。真实问题包括：
- 字符串值不加双引号（如
msg: hello而非"msg":"hello"） - 时间字段是 float64 类型的 Unix 时间戳，不是 ISO8601 字符串
- 布尔值写成
true/false但缺少引号，JSON 解析器会报错 - 空值被省略或写成
null但上下文缺失，Loki 或 Fluent Bit 可能丢弃整行
根本原因：Zap 不会自动“猜”你要 JSON，zap.NewProduction() 默认仍用 ConsoleEncoder，只是开了采样和压缩字段名（"m" 代替 "msg"），不是编码格式切换。
如何构建真正可被 Loki/ELK 解析的 JSON 日志
必须手动构造 zapcore.EncoderConfig + zapcore.NewJSONEncoder，绕过所有开箱即用的工厂函数。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
Encoding必须设为"json"（不是默认的"console"） -
EncodeTime设为zapcore.ISO8601TimeEncoder，否则时间字段是纳秒整数，多数日志平台无法识别 -
EncodeLevel推荐用zapcore.LowercaseLevelEncoder，和 Loki 的level字段约定一致 -
MessageKey、LevelKey等必须显式对齐你日志系统的 schema（比如 ELK 常用log.level，就得改LevelKey） - 避免用
zap.AddCaller()上线——文件路径在容器里无意义，还增大体积；真要调试，用trace_id关联更可靠
示例关键片段：
cfg := zapcore.EncoderConfig{
TimeKey: "time",
LevelKey: "level",
NameKey: "logger",
CallerKey: "caller",
MessageKey: "msg",
StacktraceKey: "stacktrace",
EncodeTime: zapcore.ISO8601TimeEncoder,
EncodeLevel: zapcore.LowercaseLevelEncoder,
EncodeDuration: zapcore.SecondsDurationEncoder,
EncodeCaller: zapcore.ShortCallerEncoder,
}
encoder := zapcore.NewJSONEncoder(cfg)
core := zapcore.NewCore(encoder, zapcore.AddSync(os.Stdout), zap.InfoLevel)
logger := zap.New(core)
结构化字段写法与常见 panic 场景
字段类型不匹配或传 nil 是最常导致 panic 的地方，尤其在 HTTP 请求参数、DB 查询结果这类易空场景。
-
zap.String("id", id)对id == ""安全，但对id == nil *string会 panic -
zap.Stringer("user", u)会直接调u.String()，如果u是 nil 指针，立刻崩溃 - 错误对象必须用
zap.Error(err)，不是zap.String("err", err.Error())—— 后者丢失堆栈，且err为 nil 时 panic - HTTP handler 中注入 trace_id 应统一用
logger.With(zap.String("trace_id", reqID))，别混用SugaredLogger.Infow和Logger.Info，字段名大小写/下划线风格不一致会让日志查询变地狱
容器环境下的 stdout 写入与进程退出陷阱
在 Kubernetes 或 Docker 中，os.Stdout 看似简单，但有两处极易丢日志：
- 用
os.Exit(0)或未捕获 panic 直接退出，zap缓冲区里的日志不会刷出——必须在退出前调logger.Sync() - 多 goroutine 并发写同一个 logger 是安全的，但若你在 defer 里只调了一次
logger.Sync()，而主 goroutine 已 exit，其他 goroutine 的日志可能永远卡在缓冲区 - K8s 的
livenessProbe失败触发 kill -9 时，Sync()根本没机会执行；更稳妥的是用信号监听（os.Interrupt,syscall.SIGTERM）触发 flush 后再退出
真正容易被忽略的是：JSON 日志每行必须严格合法，不能有多余换行、逗号或控制字符；哪怕一个 \r 插入字段值中，Loki 就会整行丢弃——所以对用户输入、HTTP header、URL 参数等不可信内容，务必先 sanitize 再进日志字段。
