Go zap.Logger 复用上下文字段并降低日志分配

在 Go 服务里，request_id、路由和分片信息往往会出现在同一请求的多条日志中。更稳妥的做法是用 zap.Logger.With 派生一个请求级 Logger，把稳定字段只构造一次；对可能很少真正写出的结构化字段，再考虑 WithLazy。这样既能让日志上下文完整，也能避免每个调用点重复拼装字段。

先把稳定字段放到请求级 Logger

先假定应用已经创建了名为 logger 的 zap Logger。在进入请求处理函数时派生子 Logger：

requestLog := logger.With(
    zap.String("request_id", reqID),
    zap.String("service", "order-api"),
    zap.String("shard", shardName),
)

requestLog.Info("request started")
requestLog.Info("order loaded", zap.String("order_id", orderID))

后续两条日志都会带上三个稳定字段，只有第二条额外增加 order_id。With 不会把字段写回父 Logger，因此并发请求各自派生子 Logger 时，不会因为一次请求而污染另一条请求的上下文。

字段放置可以按下面的边界判断：

With 和 WithLazy 的成本边界

With 适合已经确定要长期附加到子 Logger 的字段。WithLazy 的价值在于：字段的评估可以推迟到 Logger 真正写出日志时。它尤其适合实现了 zapcore.ObjectMarshaler 的对象，或者编码成本明显高于普通字符串的调试上下文。

type orderDebug struct {
    Items []Item
}

func (d orderDebug) MarshalLogObject(enc zapcore.ObjectEncoder) error {
    enc.AddInt("item_count", len(d.Items))
    return nil
}

debugLog := requestLog.WithLazy(
    zap.Object("order_debug", orderDebug{Items: items}),
)
debugLog.Debug("order detail")

这里不要把 buildDebug() 直接写进 WithLazy(zap.Object("order_debug", buildDebug()))，因为 Go 会先求出函数参数，延迟只覆盖字段后续的评估和编码。若对象本身的构造就很昂贵，应先用日志级别或 logger.Check 判断，再决定是否构造它。

请求边界和并发安全要一起考虑

不要把用户、租户或请求 ID 写进一个全局共享的 Logger 再复用。共享的应该是没有请求状态的根 Logger；请求进入时派生子 Logger，请求结束后让它自然离开作用域。字段只通过参数传递给 With 或日志调用，不要在多个 goroutine 之间修改同一组可变数据。

用基准和检查清单确认优化有效

这类优化的目标不是让所有日志都使用 WithLazy，而是让字段生命周期和日志级别匹配。可以围绕以下四项做一次小型 benchmark：

• 普通级别启用时，父 Logger 和子 Logger 是否都保留预期字段。
• 日志级别禁用时，延迟对象的 MarshalLogObject 是否没有被调用。
• 请求 ID 是否只出现在当前请求的日志中。
• 对比重复 zap.String、请求级 With 和 WithLazy 的分配次数，而不是只看耗时。

如果字段很小、日志几乎总会写出，直接使用 With 往往更容易读；如果字段大、只在调试级别使用，延迟评估才有明确收益。

延伸问答

With 会修改原来的 Logger 吗？

不会。它返回一个带附加字段的子 Logger，父 Logger 仍保持原来的上下文。

WithLazy 能延迟任意函数调用吗？

不能。作为参数传入的 Go 函数会先执行；它主要延迟字段在日志写出过程中的评估或编码。

每条日志都创建一个 With 子 Logger 合适吗？

不建议把同一组稳定字段在每条日志里重复创建。把请求级字段提到请求边界，事件字段直接放到具体日志调用中。

为什么还要关注字段数量？

字段越多，编码、传输和检索成本越高。只保留能帮助定位请求、判断结果和复现问题的字段，通常比无差别附加对象更稳。