log/slog 如何为一次请求绑定嵌套属性组

我在给 HTTP 服务补结构化日志时，最容易失控的不是日志级别，而是字段层级：一条记录叫 request_id，另一条又叫 id，上游字段还可能覆盖业务字段。log/slog 的做法是先从基础 logger 派生请求级 logger，再用 WithGroup 给字段划定命名空间。

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

一次请求可以固定在 request 组下，再把 HTTP 信息放到 request.http、上游调用放到 request.upstream。JSONHandler 会输出嵌套对象，TextHandler 会用点号表达层级。

下面的例子只关注绑定关系，不把图中的说明输出当作真实运行截图。两张配图分别展示 logger 派生关系与最终字段树。

先把请求公共字段固定到 request 组

WithGroup 返回一个新的 logger，不会修改原 logger；随后调用 With 绑定的属性，会被限定在这个组里。这样可以在 handler 入口建立一次请求上下文，后续日志只写事件本身。

package main

import (
    "context"
    "log/slog"
    "os"
)

func requestLogger(base *slog.Logger, requestID, method, route string) *slog.Logger {
    // request 组承载一次请求内不变的公共字段，避免每条日志重复传参。
    return base.WithGroup("request").With(
        slog.String("request_id", requestID),
        slog.String("method", method),
        slog.String("route", route),
    )
}

func main() {
    // JSONHandler 会把组写成对象，便于日志系统按层级检索。
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
    reqLog := requestLogger(logger, "req-7f3a", "GET", "/orders/{id}")
    reqLog.InfoContext(context.Background(), "request accepted")
}

这里的关键不是把字段名改成长前缀，而是让 handler 维护一个派生 logger。JSON 输出的核心形状类似 {"request":{"request_id":"req-7f3a","method":"GET","route":"/orders/{id}"}}；同一请求的后续日志可以继续复用 reqLog。

用 WithGroup 继续建立嵌套属性组

如果请求日志还要记录 HTTP 细节或上游调用，不要再次把 status、method 等键平铺到同一级。对请求 logger 再调用一次 WithGroup，就能得到独立的子 logger。

func logUpstream(ctx context.Context, reqLog *slog.Logger, status int, elapsedMS int64) {
    // 子 logger 只负责 upstream 命名空间，避免与 request.status 混淆。
    upstreamLog := reqLog.WithGroup("upstream")
    upstreamLog.LogAttrs(ctx, slog.LevelInfo, "dependency response",
        slog.Int("status", status),
        slog.Int64("elapsed_ms", elapsedMS),
    )
}

func logHTTP(ctx context.Context, reqLog *slog.Logger, userAgent string) {
    // HTTP 组保存本次事件需要的动态字段，userAgent 为空时也能按策略过滤。
    reqLog.WithGroup("http").LogAttrs(ctx, slog.LevelDebug, "request detail",
        slog.String("user_agent", userAgent),
    )
}

在 JSONHandler 下，前一段事件的结构会落在 request.upstream.status 这条路径，后一段则落在 request.http.user_agent。LogAttrs 只接收 Attr，适合已经明确字段类型的高频日志；需要快速拼接时也可以使用 InfoContext(ctx, msg, "key", value)。

slog.Group 适合一次性构造一组属性

WithGroup 适合派生一个可复用的 logger；如果只是某一条记录要带一个完整的小对象，可以使用 slog.Group。两者都能产生层级，但生命周期不同。

func logCacheResult(ctx context.Context, logger *slog.Logger, hit bool, key string) {
    // Group 只附着在这一条记录上，不改变 logger 后续的默认组路径。
    logger.LogAttrs(ctx, slog.LevelInfo, "cache lookup",
        slog.Group("cache",
            slog.Bool("hit", hit),
            slog.String("key", key),
        ),
    )
}

经验上可以这样取舍：请求 ID、路由、租户这类多条日志都要用的字段，用 With 固定；某一次缓存查询、数据库查询的成组结果，用 slog.Group 临时封装。若多个子系统都使用 id，给每个子系统分配自己的 WithGroup，能减少同名键歧义。

四个边界决定日志是否可靠

第一，组名不是数据校验。空组、重复组和字段覆盖的最终表现取决于 Handler，字段命名仍要在团队内约定。第二，能传 context 就传。使用 InfoContext 或 LogAttrs，自定义 Handler 才有机会读取调用点的 context。

第三，敏感字段要在入口脱敏。密码、Cookie、访问令牌不要因为放进 request 组就自动安全；必要时为类型实现 LogValuer，或通过 HandlerOptions.ReplaceAttr 删除或替换字段。第四，注意无效日志的计算成本。即使某级别日志被丢弃，调用参数也会先求值；昂贵对象应延迟到启用时计算，或用 LogValuer 封装。

最终可以把规则压缩成一句话：复用的公共字段用 WithGroup + With，单条记录的小对象用 slog.Group，动态事件字段用 LogAttrs，敏感内容在进入 logger 前处理。

常见问题

WithGroup 和 slog.Group 有什么区别？前者派生 logger，后续多条日志都沿用组路径；后者只为当前日志记录创建一个 Group 属性。

TextHandler 会不会丢失嵌套关系？不会。它通常用点号连接组名和字段名，例如 request.upstream.status=200；需要 JSON 对象时再选择 JSONHandler。

小结

为一次请求绑定嵌套属性组，核心是先建立请求级 logger，再按 HTTP、上游依赖等责任边界继续派生子组。这样既减少重复参数，也让 JSON 日志保留可查询的层级；至于脱敏、空值和昂贵计算，则需要配合 Handler 与 LogValuer 另行处理。