slog为请求添加结构化上下文

如果一条请求日志只能看到“查询失败”，排查时还要回头翻找 URL、用户、请求编号，日志很快就会失去价值。Go 的 log/slog 适合把这些字段变成结构化属性：请求级字段由中间件统一准备，业务事件再追加自己的字段。

官方文档：https://pkg.go.dev/log/slog

最稳妥的组合是：有 context.Context 就使用 InfoContext 或 LogAttrs，跨同一请求都不变的字段使用 Logger.With。不要把 logger 本身偷偷塞进 context；让处理函数显式接收 logger，边界更清楚。

先分清两种“上下文”

InfoContext 的 context 参数是给 Handler 读取请求相关信息的入口，例如链路追踪信息；它不会自动把 context 里的所有键值变成日志字段。真正要输出 request_id，仍然需要把它作为 slog 属性传给 logger。

Logger.With 返回一个带固定属性的新 logger，适合 method、path、request_id 这类同一请求内重复出现的字段；LogAttrs 适合单次事件的 status、duration_ms 或 error。

中间件只做一次请求级组装

下面的中间件把请求固定字段放到 logger 中，再通过显式参数交给业务处理函数。示例使用标准库随机数生成一个演示用请求标识；生产系统若已有网关或链路追踪 ID，应优先沿用可信的上游值，并按安全策略限制可记录字段。

package main

import (
    "context"
    "fmt"
    "log/slog"
    "net/http"
    "os"
    "time"
)

func requestLogger(next func(*slog.Logger, http.ResponseWriter, *http.Request)) http.Handler {
    base := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo}))
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 请求固定字段只组装一次，避免业务层每条日志重复拼接。
        requestID := r.Header.Get("X-Request-ID")
        if requestID == "" {
            requestID = fmt.Sprintf("local-%d", time.Now().UnixNano())
        }
        logger := base.With(
            slog.String("request_id", requestID),
            slog.String("method", r.Method),
            slog.String("path", r.URL.Path),
        )
        // context 继续沿请求传递，logger 用显式参数传递给业务函数。
        next(logger, w, r)
    })
}

func handle(logger *slog.Logger, w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    started := time.Now()
    // LogAttrs 让一次事件的动态字段保持明确的类型。
    logger.InfoContext(ctx, "request started", slog.String("component", "handler"))
    defer func() {
        // 结束日志只追加本次事件的数据，固定字段仍来自 logger.With。
        logger.LogAttrs(ctx, slog.LevelInfo, "request finished",
            slog.Int64("duration_ms", time.Since(started).Milliseconds()),
            slog.Int("status", http.StatusNoContent),
        )
    }()
    w.WriteHeader(http.StatusNoContent)
}

这里的关键不是“把所有东西都放进 context”，而是把请求生命周期分成两类数据：跨多个日志事件稳定不变的数据进入 With，当前事件才有的数据作为 Attr 传入。Handler 收到 context 后使用 InfoContext，因此以后接入能读取 trace ID 的 Handler 时仍保留扩展点。

用指标判断是否值得这样组织

结构化日志的收益应通过指标说话。先保留一个最小基线：每次日志调用都显式传入 request_id、method、path；再与请求级 Logger.With 方案比较。关注三组数据：

• 重复属性数量：同一请求的多条记录是否都包含相同字段，便于检索的同时避免业务代码散落字符串键。
• 分配与延迟：用 testing.B 比较每次日志的 ns/op 和 allocs/op；不要把一次机器上的数字写成普遍结论。
• 日志体积：比较同样请求量下的 JSON 字节数。固定字段不会消失，With 主要减少调用端重复组装，不等于网络传输自动变小。

若请求只有一条日志，直接使用 logger.LogAttrs(ctx, ...) 往往更直观；若一个请求会写入多条日志，先构造请求级 logger 更容易保持字段一致。高频路径还应避免把大对象直接作为属性，必要时使用稳定 ID，或让自定义 LogValuer 控制展开和脱敏。

常见误区与速查

还要留意交替键值写法的拼写错误，例如少写一个值会产生异常键。稳定字段建议使用 slog.String、slog.Int 等显式构造；需要性能测量时固定 Handler、输出目标和日志等级，只改变一种变量。

相关问题

slog 的 context 会自动生成 request_id 吗？

不会。context 是传递请求状态的容器，Handler 是否读取其中的追踪信息由实现决定；request_id 需要由中间件提取或生成，再作为 slog 属性加入 logger。

Logger.With 和每次传属性哪个更快？

没有脱离 Handler、字段数量和调用频率的固定答案。重复字段较多时 With 可以让 Handler 预处理属性；最终应以同一基准下的 ns/op、allocs/op 和日志字节数决定。