Go slog 怎样给结构化日志加入请求字段

给 Go slog 日志加入请求字段，最短路径是用 base.With(...) 得到请求专属 Logger，再把它交给业务函数。请求标识、方法和路由只绑定一次，事件名称、条数等变化字段留在具体日志调用处。本文围绕“字段没出现”与“不同请求串号”两个现象说明这种写法。

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

字段丢失时先看调用的是哪个 Logger

常见情况是入口已经执行 With，业务函数却仍调用顶层 slog.Info。顶层调用使用默认 Logger，不会自动继承某个局部变量中的属性。另一种情况是忽略 With 返回值，后面依旧拿原来的 base 写日志。

本例把属性分成三个层级：服务级 service 固定为 report-demo；请求级 request 分组包含 id、method、route；事件级 event、rows、status 随每条记录变化。这个划分是示例的接口约定，不是 slog 自动识别出来的分类。

为请求创建独立的日志器

把以下原创示例保存为 main.go。它只依赖标准库，使用 slog 基础接口，面向 Go 1.21 及以上环境。代码和后面的观察条件是供读者尝试的方案，未在本文制作过程中启动服务器或执行测试。

package main

import (
    "context"
    "crypto/rand"
    "encoding/hex"
    "log/slog"
    "net/http"
    "os"
)

func writeReport(ctx context.Context, logger *slog.Logger) {
    // 业务函数使用请求日志器，不退回全局 slog.Info。
    logger.InfoContext(ctx, "report prepared",
        slog.String("event", "report_ready"),
        slog.Int("rows", 12))
}

func reportHandler(base *slog.Logger) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        var token [16]byte
        // 标识由本服务生成；失败时不产生空标识的正常业务日志。
        if _, err := rand.Read(token[:]); err != nil {
            base.ErrorContext(r.Context(), "request id failed",
                slog.String("error", err.Error()))
            http.Error(w, "internal error", http.StatusInternalServerError)
            return
        }
        requestID := hex.EncodeToString(token[:])
        // 接收 With 的返回值；仅绑定白名单字段，不写查询串或认证头。
        logger := base.With(slog.Group("request",
            slog.String("id", requestID),
            slog.String("method", r.Method),
            slog.String("route", "/report")))
        w.Header().Set("X-Request-ID", requestID)
        writeReport(r.Context(), logger)
        logger.InfoContext(r.Context(), "report response selected",
            slog.Int("status", http.StatusNoContent))
        w.WriteHeader(http.StatusNoContent)
    })
}

func main() {
    // 初始化服务级日志器；本示例不切换进程的默认 Logger。
    base := slog.New(slog.NewJSONHandler(os.Stdout, nil)).
        With(slog.String("service", "report-demo"))
    mux := http.NewServeMux()
    mux.Handle("/report", reportHandler(base))
    server := &http.Server{Addr: "127.0.0.1:8080", Handler: mux}
    // 示例聚焦字段归属，实际部署另行配置超时、关闭与访问控制。
    if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed {
        base.Error("server failed", slog.String("error", err.Error()))
        os.Exit(1)
    }
}

这里的 requestID 来自随机字节，适合演示关联标识生成，不代表业务主键、用户身份或绝对唯一性证明。route 写固定模板而不记录原始 URL，避免把查询参数直接送入日志。返回头允许调用方取得当前标识，但生产代理是否转发这个头需要自行配置。

writeReport 里的 rows=12 只是固定示例数据，并没有实际查询报表。status=204 记录的是本 Handler 选择的响应码，不能据此宣称客户端已经成功收完响应。示例不包装 ResponseWriter，也不是通用访问日志中间件。

Context 和分组分别负责什么

代码同时传入 r.Context() 和 logger，前者承载请求上下文，后者承载已经绑定的日志属性。InfoContext 把 Context 交给 Handler；内置 JSONHandler 不会任意遍历 Context.Value 并把其中内容变成字段。需要输出的 request.id 在这里由 With 明确加入。

如果团队坚持把 Logger 放入 Context，应提供私有键类型和统一取值函数，并保证每层使用该函数；那属于另一种传参约定，不是 slog 的默认功能。本文直接传 *slog.Logger，便于看到哪里丢失了关联。

使用 slog.Group("request", ...) 是为了把三项请求属性组织在同一个对象下。JSONHandler 将其呈现为 request 对象；使用 TextHandler 时则采用带点号的限定名。本文不在请求日志器上调用 WithGroup("request")，否则后续业务字段也会落入该分组范围，容易与想保留在顶层的 status、event 混淆。

按字段归属排查串号与重复键

不要用“同一个键后写的必然覆盖前面的”作为业务契约。日志采集器、JSON 解析器及索引规则对重复键的处置可能不同。本例用 request.id 与事件字段分离，从源头减少歧义。

字段白名单应在绑定时执行。不要整包记录 Header、Cookie、认证令牌或请求体，也不要把任意对象交给 slog.Any 后假设它已经脱敏。本例只绑定不可变字符串，避免传入可变 map 或指针后又并发修改其内容。

用两组请求做反向确认

读者可在独立示例目录中尝试下列命令。先启动服务，再在另一个终端发起两次请求；这些命令尚未在本文中执行，没有附上伪造的运行记录。

# 在保存 main.go 的目录启动示例，完成后用 Ctrl+C 停止。
go run main.go
# 在另一个终端分别发起请求，并观察各自响应头中的 X-Request-ID。
curl -i http://127.0.0.1:8080/report
curl -i http://127.0.0.1:8080/report

按代码逻辑，正常路径下同一次请求的两条业务记录应共享 request.id、method、route 和 service；只有 report prepared 带 event 与 rows，另一条带 status。两次请求预期获得不同随机标识；若看到相同值，应检查标识生成与采集链路，不能仅凭两次观察证明全局唯一。

可以临时把 writeReport 中的 logger.InfoContext 改成 slog.Info，观察那条记录是否失去请求属性。这是定位传参断点的反向操作，完成后应恢复。再检查实际查询路径是否使用 request.id，而不是误把 request 当作字符串字段搜索。

一定要自定义 Handler 才能加入请求标识吗？

不需要。本例用显式 With 与参数传递完成。只有要按团队约定从 Context 提取特定值时，才考虑包装 Handler，并承担额外实现和维护成本。

应该在每个请求里调用 SetDefault 吗？

不应该用这种方式传播请求字段。进程默认 Logger 是共享入口，不适合担当某个请求的局部状态。

Logger 可以传给后台任务吗？

可以显式传递作为关联信息，但要先定义任务自己的生命周期与 task.id，不要把 HTTP 请求的取消时点等同于后台任务结束；也不要把整个 Request 长期保存在任务对象中。

最终清单很短：保存 With 返回值、局部派生、显式传递、固定字段归属、避免敏感原始对象，并根据实际日志格式检查嵌套查询路径。

接口语义参考：Logger.With、Contexts、Group。示例业务和排查方案为原创组织。