Go slog 属性怎么统一注入：With、分组字段与日志成本边界

线上排查一条订单请求时，最有用的字段通常不是“这是一条错误日志”，而是 request_id、tenant_id、order_id 和处理阶段。Go 的 log/slog 能把这些字段写成结构化记录，但字段放错层级，结果仍然会很乱：请求 ID 可能漏记，用户字段可能被重复拼接，调试字段还可能在生产环境白白消耗 CPU。

请求字段应该在哪一层注入

先看一条真实请求链路：HTTP 中间件拿到请求 ID，处理器知道用户身份，订单服务知道订单号，底层仓储知道 SQL 耗时。把所有字段都塞进最底层，既会让函数签名变长，也会让日志失去“字段是谁提供的”这个线索。

更稳定的做法是按生命周期分层：

用 With 固定请求上下文，用 Group 管理命名空间

With 会返回一个带固定属性的 logger。它适合请求 ID 这种在一次请求内不变的值：

func requestLogger(base *slog.Logger, r *http.Request) *slog.Logger {
    requestID := r.Header.Get("X-Request-ID")
    return base.With(
        slog.String("request_id", requestID),
        slog.String("route", r.URL.Path),
    )
}

func handleOrder(ctx context.Context, log *slog.Logger, orderID int64) {
    log = log.With(slog.Group("order", slog.Int64("id", orderID)))
    log.InfoContext(ctx, "order check started")
}

当 JSON handler 输出时，分组字段会变成类似 {"order":{"id":1001}} 的结构。这样做的价值不在于多了一层括号，而在于不同领域都能使用短而稳定的字段名：user.id 和 order.id 不会混为一谈。

不要把可变字段误当成固定字段。订单状态在服务调用前后会变化，适合在对应事件上记录；把初始状态放进 With 后继续复用，容易让后来的人误以为它仍然是当前状态。

动态字段不要每条日志都提前算完

日志调用本身可能被禁用，但参数表达式仍然会先求值。下面的代码在 DEBUG 未开启时，仍然会构造完整诊断快照：

log.DebugContext(ctx, "payload inspected",
    slog.Any("snapshot", buildLargeSnapshot(payload)),
)

如果快照很重，可以先判断级别：

if log.Enabled(ctx, slog.LevelDebug) {
    log.DebugContext(ctx, "payload inspected",
        slog.Any("snapshot", buildLargeSnapshot(payload)),
    )
}

另一种方式是实现 slog.LogValuer，让 handler 在真正需要输出时再解析值。这个方式适合可复用的领域对象，但要注意：LogValuer 不是隐私过滤器，返回的属性仍然要经过字段审查。

错误日志要保留原因，也要避免重复字段

func loadOrder(ctx context.Context, log *slog.Logger, id int64) (Order, error) {
    order, err := repo.Find(ctx, id)
    if err != nil {
        log.ErrorContext(ctx, "find order failed",
            slog.Int64("order_id", id),
            slog.Any("err", err),
        )
        return Order{}, fmt.Errorf("find order %d: %w", id, err)
    }
    return order, nil
}

如果仓储层已经记录了一次错误，上层再无条件记录同一个错误，日志平台里可能出现两条看似不同的失败。常见的取舍是：底层记录可定位的技术细节，上层只在改变语义时记录，例如把“数据库超时”映射成“订单查询失败”，并携带稳定业务字段。

错误字段建议统一使用 err，不要一个模块叫 error、另一个模块叫 exception。稳定字段名比更长的描述更利于检索和告警规则复用。

日志级别是接口契约，不是装饰

把所有信息都写成 Info 会让线上日志膨胀；把真正需要告警的故障写成 Debug，又会在默认配置下完全消失。可以把级别和读者动作对应起来：

• Debug：只用于复现和开发期诊断，允许包含较重但经过脱敏的上下文。
• Info：请求完成、状态变化、批处理摘要等正常运营事件。
• Warn：有降级、重试或可恢复异常，需要观察但不一定触发故障响应。
• Error：当前请求或任务未完成，需要人工或自动化处理。

这套约定还要写进 logger 初始化和测试。否则某个新模块把每个循环项都写成 Info，问题通常要等日志费用或采集延迟上升后才暴露。

字段设计最后要过隐私和成本两道检查

结构化日志方便检索，也更容易把敏感字段持久化到多个系统。上线前至少检查：

• 令牌、密码、Cookie、完整银行卡号不进入属性列表。
• 用户标识优先使用内部 ID 或脱敏值，避免把完整手机号当作检索键。
• 大对象只在确有诊断价值且级别开启时计算，并设置大小上限。
• 同一字段只由一个明确层级负责，避免中间件和业务层重复覆盖。

可以为自定义对象写一个只暴露安全字段的 LogValue 方法，但还应该在测试中检查输出键集合。日志不是临时字符串，它通常会被索引、复制和长期保存。

常见问题

With 会修改原来的 slog.Logger 吗？

不会。它返回一个带附加属性的新 logger，原 logger 仍可用于其他请求。共享一个基础 logger，再按请求派生，是常见用法。

Group 字段一定比加前缀更好吗？

不一定。JSON 或支持嵌套字段的采集系统适合 Group；如果下游只支持扁平键，order_id 这类明确前缀可能更容易查询。关键是全项目统一。

为什么日志里有 request_id，但业务函数没有传它？

如果 logger 已经在中间件派生并沿调用链传递，业务函数不需要重复传 request_id 字符串。若依赖 context 自动取 logger，也要明确约定取值键，避免测试和异步任务丢失上下文。

日志字段越多，排查就越快吗？

不是。字段越多，成本、隐私风险和检索噪声也越高。优先保留能回答“哪次请求、哪个租户、哪个对象、哪一步失败”的字段，其余信息按级别和采样策略补充。

slog 的关键不是把 printf 换成 JSON，而是让字段拥有清晰的生命周期：请求级字段在入口固定，业务级字段在动作附近出现，昂贵值在确实需要时才计算，敏感值永远不进日志。这样写出的记录，才同时服务于排障、告警和长期运营。