Go slog.Handler WithGroup 怎么组织结构化日志：字段继承、覆盖顺序与请求边界

服务里的日志字段一多，最先变乱的通常不是日志级别，而是命名空间：请求、数据库和业务结果都可能各自写一个 status。Go 的 log/slog 可以用 WithGroup 把字段放进稳定的分组，再配合 With 复用固定属性；关键是记住，调用顺序决定字段属于哪一层。

先看一个可复现的最小写法

下面这段代码故意只保留请求方法、路径和响应状态三个字段。把它放到一个临时 Go 1.21+ 模块里运行，就能直接看到 request 分组怎样承接固定属性与单次事件属性。

package main

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

func main() {
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{AddSource: false})
    logger := slog.New(handler)
    requestLogger := logger.WithGroup("request").With(
        slog.String("method", "GET"),
        slog.String("path", "/orders/42"),
    )

    requestLogger.LogAttrs(context.Background(), slog.LevelInfo, "request finished",
        slog.Int("status", 200),
    )
}

输出中，method、path 和 status 会位于 request 对象内。若换成 slog.NewTextHandler，同一层级通常会显示为 request.method、request.status。这不是两套日志语义，而是 Handler 对分组的展示方式不同。

With 和 WithGroup 到底谁先生效

可以把 Logger 看成一条按顺序追加的操作记录，而不是一个最后统一合并的 map。先进入分组，再追加属性，属性就落在该分组里；先追加属性，再进入分组，前面的属性仍然保持在原来的层级。

base := slog.New(slog.NewJSONHandler(os.Stdout, nil))

left := base.With(slog.String("service", "checkout"))
left = left.WithGroup("request").With(slog.String("method", "GET"))

right := base.WithGroup("request")
right = right.With(slog.String("service", "checkout"))

left 的 service 在顶层，method 在 request 内；right 则会把 service 也放到 request 内。两种结果都合法，但通常更适合把服务名放在顶层，把一次请求的字段放进请求组。

这条规则也解释了为什么中间件要在边界处创建新的 Logger：请求级字段应当从进入请求的那一刻开始归组，而不是在业务函数里凭习惯再补一层。

嵌套分组如何避免字段撞名

真实服务经常同时记录请求状态和数据库状态。如果两边都直接写 status，平铺文本还勉强能靠上下文阅读，JSON 消费者却容易遇到重复键或字段覆盖。分组后，路径本身就表达了归属。

logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
logger.WithGroup("request").WithGroup("user").LogAttrs(
    context.Background(),
    slog.LevelInfo,
    "authorized",
    slog.String("id", "u-42"),
)

这里的 id 位于 request.user 下。若再在 request 下记录一个业务状态，它和数据库组里的 status 不会混成同一个名字。分组名称应当稳定、短一些，最好能对应日志消费端已经约定的字段层级。

自定义 Handler 不能只实现一半语义

如果项目要把日志送到自定义缓冲区、测试收集器或多路输出 Handler，最容易漏掉的是 WithAttrs 与 WithGroup 的组合语义。Handler 不应修改接收者后返回自己，而应该返回带有新状态的 Handler；否则同一个基础 Logger 被不同请求复用时，字段可能串到下一条记录。

实现时至少核对三件事：

• WithAttrs 传入的属性要和已有属性按调用顺序保留。
• WithGroup 新增的分组要作用于之后的属性和 Record 字段。
• 空分组名应保持标准库约定，不能凭自定义实现生成一个空对象层。

Go 官方的 Handler 指南还特别强调，WithGroup 和 WithAttrs 是交织的。比如先进入 g1、加一个属性，再进入 g2、再加一个属性，两个属性的路径不应被实现成同一层。

用输出核对，而不是凭感觉改字段

调试日志结构时，我更建议同时跑一遍 JSONHandler 和 TextHandler。先确认 JSON 的对象层级，再看文本输出的点号路径，能很快发现“字段在错误分组里”与“字段值写错”是两类不同问题。

func makeLogger(w io.Writer, jsonOutput bool) *slog.Logger {
    var h slog.Handler
    if jsonOutput {
        h = slog.NewJSONHandler(w, nil)
    } else {
        h = slog.NewTextHandler(w, nil)
    }
    return slog.New(h)
}

核对时可以固定一组断言：请求方法和路径只能出现一次；响应状态必须在请求组内；服务名不应随着请求组的创建而移动；同一个 Logger 连续写两条请求日志时，第一条的用户字段不能出现在第二条。

常见问题

WithGroup 会修改原来的 Logger 吗？

不会。它返回一个带有新 Handler 状态的 Logger，原 Logger 仍可用于其他层级。正因为如此，可以把基础 Logger 作为服务级配置，再为请求、数据库等边界创建派生 Logger。

TextHandler 和 JSONHandler 的分组结果一样吗？

语义一致，展示形式不同。JSONHandler 通常使用嵌套对象，TextHandler 通常使用带点号的限定名。日志检索规则要按实际输出格式编写。

为什么不能把所有字段最后一次性合并？

因为调用顺序本身就是字段边界信息。最后合并会丢掉属性是在进入哪个分组前还是之后加入的，尤其在自定义 Handler 或中间件组合时容易产生错层。

把分组规则固定成团队约定

对大多数 HTTP 服务，可以约定服务级字段留在顶层，请求字段进入 request，调用下游的字段进入 upstream，业务结果再进入自己的组。新字段先问“它属于哪条边界”，再决定 key 名；这样日志结构会比单纯禁止重复 key 更容易维护。

最后用一条最小检查收尾：查看 Logger 派生顺序、运行 JSON 和文本两种 Handler、检查重复字段和跨请求污染。只要这三步都通过，WithGroup 就不只是让日志看起来整齐，而是真正给日志消费者提供了稳定的字段路径。