Go slog 怎么统一添加请求 ID 和业务字段

在 HTTP 服务里，最怕的不是少打一条日志，而是同一个请求经过网关、Handler 和业务服务后，日志看起来像三件互不相关的事。用 Go 的 log/slog 时，可以把 request_id 放进请求的 context.Context，再把稳定的业务字段绑定到派生 logger。这样每条日志只补充当前动作，查询时仍能沿着同一个请求串起来。

先把日志字段分成三层

统一字段前，先做一个简单约定：应用级字段例如 service、env 在进程启动时绑定；请求级字段例如 request_id、route 随请求变化；动作级字段例如 order_id、duration_ms 只在对应日志附近出现。这个划分能避免把上一次请求的 ID 泄漏到下一次请求。

把请求 ID 放进 context，再让 Handler 读取

slog 不会自动从 context 猜出请求 ID。中间件负责把值写入 context，日志调用负责把同一个 context 传给 Handler。下面的 requestIDKey 使用私有类型，避免和其他包的 context 键冲突：

type requestIDKey struct{}

func withRequestID(next http.Handler, logger *slog.Logger) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        id := r.Header.Get("X-Request-ID")
        if id == "" {
            id = newRequestID() // 示例：接入项目已有的 ID 生成器
        }

        ctx := context.WithValue(r.Context(), requestIDKey{}, id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

func requestLogger(ctx context.Context, base *slog.Logger) *slog.Logger {
    id, _ := ctx.Value(requestIDKey{}).(string)
    if id == "" {
        return base
    }
    return base.With(slog.String("request_id", id))
}

这里的中间件只负责请求边界，业务层不需要知道 ID 是从请求头接收还是本地生成。若项目还有链路追踪，也可以在同一个边界生成或提取 trace_id，但应先明确可信来源和脱敏规则。

用 InfoContext 和 LogAttrs 传递当前请求

在 Handler 或服务方法里，拿得到 context 就不要退回无上下文的 Info。基础 logger 可以在启动时创建：

base := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
    Level: slog.LevelInfo,
}))

func handleOrder(ctx context.Context, base *slog.Logger, orderID string) {
    logger := requestLogger(ctx, base).WithGroup("order")
    logger.LogAttrs(ctx, slog.LevelInfo, "order lookup",
        slog.String("order_id", orderID),
        slog.String("result", "hit"),
    )
}

LogAttrs 接收已经构造好的属性，字段较多或调用频繁时更清楚，也能避免交替键值参数写错。需要注意的是，传入 context 主要是给 Handler 使用；取消 context 并不会替你撤销日志记录，因此不要把“日志必须成功写出”建立在请求是否已经取消之上。

用 With 和 WithGroup 分层绑定业务字段

固定字段用 With，例如服务启动后创建一个带服务名的 logger，请求进入后再派生一个带租户和请求 ID 的 logger。订单字段则靠近订单动作绑定：

serviceLogger := base.With(
    slog.String("service", "checkout"),
    slog.String("env", "prod"),
)

func checkout(ctx context.Context, tenantID, orderID string) {
    logger := requestLogger(ctx, serviceLogger).
        WithGroup("checkout").
        With(slog.String("tenant_id", tenantID))

    logger.InfoContext(ctx, "payment started",
        slog.Group("order", slog.String("id", orderID)),
    )
}

用组可以把相同的 id 放到不同命名空间里，例如 order.id 和 user.id。不要把 order_id 这类每次变化的值绑定在一个跨请求共享的 logger 上；logger 本身可以并发使用，但它携带的字段应该是不可变的。

发布前检查字段边界和可检索性

至少检查四件事：没有 request ID 的后台任务是否仍能正常打日志；外部传入的 ID 是否限制长度并过滤换行；密码、Cookie、Authorization 和完整支付载荷是否被排除；JSON 输出中字段名是否保持稳定。若日志平台按点号展开字段，确认 WithGroup 的层级与查询语法一致。

实践中可把“请求开始、关键业务动作、失败原因、请求结束”作为最小集合，而不是每个函数都输出一条。读者遇到字段缺失时，先确认调用的是 InfoContext 还是 Info，再确认 requestLogger 是否在当前 context 上派生，最后检查 Handler 是否确实支持上下文读取。

常见问题

为什么把 logger 放进 context 不推荐？

这种做法会隐藏函数依赖，调用者看不出方法需要日志对象。更直观的方式是显式传递 logger，context 只携带请求范围的数据。

request_id 应该从请求头直接信任吗？

不应无条件信任。内部网关可以约定来源，但边界服务仍应校验长度、字符集和覆盖策略；不合规时重新生成。

With 和单条 slog.String 有什么区别？

With 会让字段出现在该派生 logger 的后续输出中，适合稳定公共字段；单条属性只影响当前记录，适合动态动作字段。

最终可以把规则记成一句话：请求数据沿 context 走，稳定业务数据沿派生 logger 走，当前动作数据留在 LogAttrs 调用里。层级清楚，日志才既能按 request_id 检索，也不会因为复用对象而串数据。