默认的zap logger不能直接打结构化日志，因为zap.newproduction()或zap.newdevelopment()返回的*zap.logger不自带字段，所有结构化字段必须显式传入每次日志调用；logger.with()返回新实例，原logger不变，需赋值或链式使用。
为什么默认的 Zap logger 不能直接打结构化日志
因为 zap.NewProduction() 或 zap.NewDevelopment() 返回的是 *zap.Logger，它本身不带字段（field）——所有结构化字段必须显式传入每个日志调用。你写 logger.Info("user login") 只会输出时间、级别、消息，没有 trace_id、user_id 这类上下文。
常见错误是试图在 logger 初始化时“预设”字段，比如：logger.With(zap.String("service", "auth")) 却没保存返回值，导致后续调用仍无字段。
-
logger.With(...)返回新 logger，原 logger 不变，必须赋值或链式使用 - 全局 logger 建议用
zap.NewAtomicLevel()+With()构建带基础字段（如service、env）的实例 - 请求级字段（如
trace_id、user_id）应在 handler 中通过logger.With(...)衍生，避免污染全局
如何给 HTTP 请求注入 trace_id 并透传到日志
Go 微服务里，trace_id 通常从请求头（如 X-Request-ID 或 traceparent）提取，再挂到 context，并在日志中作为字段输出。Zap 本身不处理 context，需手动桥接。
关键点：别把 context.Context 直接塞进 logger.Info() —— Zap 不识别它；得提前从 context 提取字段，再传给 logger.With()。
- 中间件中用
req.Header.Get("X-Request-ID")获取 ID，若为空可生成一个（如用uuid.New().String()） - 用
ctx = context.WithValue(ctx, key, traceID)存入 context（key 建议用私有类型，避免冲突） - handler 内部用
traceID := ctx.Value(key).(string)提取，然后logger.With(zap.String("trace_id", traceID)).Info("login start") - 如果用了 OpenTelemetry，推荐从
otel.GetTextMapPropagator().Extract()解析traceparent，再用trace.SpanFromContext(ctx).SpanContext().TraceID().String()
zap.String() 和 zap.Any() 在微服务日志里的实际区别
微服务日志常要打 struct、map、error、time.Time 等非字符串类型。选错 zap field 函数会导致序列化异常或丢失信息。
zap.String() 只接受 string，传 int 或 struct{} 会 panic；zap.Any() 能自动序列化多数类型，但对自定义 struct 依赖其是否实现了 fmt.Stringer 或被 json.Marshal 支持。
- 打 error：优先用
zap.Error(err)（专为 error 设计，自动展开堆栈）；别用zap.Any("err", err)，可能只显示"<nil>"</nil>或类型名 - 打 map 或 slice：用
zap.Any()安全，例如zap.Any("headers", req.Header) - 打 time.Time：用
zap.Time()，否则zap.Any()会输出完整 struct 字段，冗余且不易读 - 打自定义 struct：确保实现了
MarshalJSON，或用zap.Reflect()（性能略低，但最通用）
如何让 Zap 日志兼容 ELK 或 Loki 的字段解析
ELK（Elasticsearch+Logstash+Kibana）和 Loki 都依赖日志行中的 JSON 键名做字段提取。Zap 默认输出是 JSON 格式，但字段名是驼峰（traceId），而运维侧 pipeline 习惯下划线（trace_id）。不统一会导致 Kibana 里搜不到 trace_id。
Zap 本身不提供字段名重命名机制，只能靠自定义 EncoderConfig 控制键名。
- 初始化 logger 时，用
zap.NewProductionEncoderConfig()，然后改写MessageKey、LevelKey、TimeKey等字段为下划线风格（如config.LevelKey = "level"） - 特别注意
EncodeCaller：默认输出"caller":"main.go:23"，Loki 的packer或 Promtail 的labels提取规则常依赖caller字段，别删它 - 如果用 Loki，建议加
zap.AddStacktrace(zapcore.WarnLevel)并确保stacktrace字段名与 Grafana 查询语句匹配（如{job="auth"} |= "error" | json | stacktrace） - 避免在字段值里嵌套 JSON 字符串（如
zap.String("meta", `{"a":1}`)），会导致外层 JSON 解析失败；应改用zap.Any("meta", map[string]int{"a": 1})
字段命名一致性比日志内容更重要——下游系统靠键名干活，拼错一个下划线，整条链路就查不到。
