Go slog 如何把请求信息带进日志：上下文、Handler 过滤与字段规范

接口出了问题，单看一行 request failed 往往不够：它属于哪个请求、哪个租户、耗时多久、是业务错误还是下游超时，都需要从同一条日志里顺着查下去。Go 1.21 引入标准库 log/slog 后，可以把这些字段放进 context.Context，由统一的 Handler 在输出前完成筛选和格式化。

先把请求现场收敛成一条可检索记录

下面的例子假设服务有一个订单查询接口。入口中生成或读取请求 ID，随后把它放入上下文；处理函数只负责业务判断，日志由同一个 slog.Logger 输出。

package main

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

type requestKey struct{}

func withRequestID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, requestKey{}, id)
}

func requestID(ctx context.Context) string {
    id, _ := ctx.Value(requestKey{}).(string)
    return id
}

func orderHandler(log *slog.Logger) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        started := time.Now()
        ctx := withRequestID(r.Context(), "req-7f31")

        log.InfoContext(ctx, "order lookup started",
            "route", r.URL.Path,
            "method", r.Method,
        )

        if requestID(ctx) == "" {
            log.ErrorContext(ctx, "request id missing")
            http.Error(w, "bad request", http.StatusBadRequest)
            return
        }

        log.InfoContext(ctx, "order lookup finished",
            "duration_ms", time.Since(started).Milliseconds(),
            "status", http.StatusOK,
        )
        w.WriteHeader(http.StatusOK)
    })
}

func main() {
    log := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        Level: slog.LevelInfo,
    }))
    _ = http.ListenAndServe(":8080", orderHandler(log))
}

这段代码的关键不是把所有变量塞进上下文，而是让请求边界成为字段边界。request_id、路由和耗时属于一次请求，适合随上下文传递；订单金额、完整 Cookie、Authorization 内容则不应因为“方便排查”而直接写入。

为什么字段应该由 Handler 统一补齐

如果每个业务函数都手工写 request_id、用户标识和服务名，很快会出现同一含义多个名字的情况：requestId、req_id 和 request_id 同时存在，检索规则会变得脆弱。更稳妥的方式是用 With 创建带公共字段的 logger，再把它传给当前请求链路。

func requestLogger(base *slog.Logger, r *http.Request) *slog.Logger {
    return base.With(
        "request_id", requestID(r.Context()),
        "route", r.URL.Path,
        "method", r.Method,
    )
}

func queryOrder(ctx context.Context, log *slog.Logger) error {
    log.DebugContext(ctx, "query order repository")
    return nil
}

需要注意，With 返回的是带属性的新 logger，不会改变原 logger。把它放在请求入口创建一次即可，避免在循环或深层函数里反复追加相同字段。

用 Leveler 处理生产日志的噪声

开发环境可以看到 DEBUG，生产环境通常从 INFO 开始。不要在每个调用点加环境判断，让 HandlerOptions 集中处理级别更容易复查。

var minLevel = new(slog.LevelVar)

func newLogger() *slog.Logger {
    minLevel.Set(slog.LevelInfo)
    return slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        Level: minLevel,
    }))
}

// 仅在受控配置变更后调用，避免每条请求修改全局级别。
func enableDebug() {
    minLevel.Set(slog.LevelDebug)
}

LevelVar 适合需要运行期间调整级别的服务，但配置入口必须有权限边界和审计记录。若只是固定生产级别，直接使用 slog.LevelInfo 更简单。

三种常见写法为什么会让日志失去价值

把 context 当成通用参数包

context 适合放取消信号、截止时间和请求范围的公共数据，不要往里面塞完整订单对象或者可选配置这类重内容。大对象存进上下文之后会隐藏依赖关系，后续很难追溯每个字段的写入责任人。

把原始 URL 当成 route

/orders/10086 和 /orders/10087 会被统计成两个路径。日志字段应尽量记录 /orders/:id 这样的路由模板，必要时单独保留经过脱敏的资源标识。

只记录错误文本，不记录错误类型

错误消息适合给人看，稳定的事件名和状态字段更适合检索。可以同时写 event、status 和 err，但不要把堆栈、口令或完整上游响应原样打出。

一条成功和一条失败请求怎么验收

本地启动服务之后，分别走一遍正常成功逻辑和缺少请求 ID 的异常逻辑，检查 JSON 日志是否符合下面的校验清单：

• 两条记录都有同一格式的 request_id、route 和 method。
• 成功记录包含 status=200 和 duration_ms，失败记录包含可检索的事件名。
• 切换到 INFO 日志级别后，调试类日志不再输出，但错误类日志仍然正常保留。
• 输出内容里没有 Authorization、Cookie、完整手机号或者其他未脱敏的业务敏感参数。

相关问题

slog 和传统 printf 日志能混用吗？

日志能力可以逐步迁移落地，但同一条请求链路里最好统一字段名和输出格式。新写的业务代码优先用结构化字段，历史遗留的旧日志可以通过边界层逐步替换兼容。

request_id 应该放在 context 还是 logger 里？

请求入口处可以从 context 取出公共字段，生成附带这些字段的 logger；跨函数传递的时候仍然保留 context。两者的职责完全不一样，不要拿 logger 代替 context 做取消信号和截止时间的传播。

生产环境是否应该完全关闭 DEBUG？

调试级别的全链路字段默认可以关闭，遇到很难复现的线上问题时，再通过受控配置短时开启，同时要限制开启范围、持续时长和输出内容。

小结

Go slog 的核心价值就是把请求上下文、稳定字段规则和输出级别控制放到同一套约束里。先定好全局字段命名规范，再在请求入口生成绑定当前请求属性的 logger，最后用 HandlerOptions 过滤冗余日志噪声，后续排查问题时就能顺着一条日志里的 request_id 捞到全链路的完整记录。