Go slog 怎样把公共字段分组输出

在服务日志里，service、request_id、user_id 经常一起出现。如果所有字段都放在 JSON 顶层，检索时容易撞名，阅读时也看不出哪些字段属于请求、用户还是业务结果。Go 的 log/slog 可以用 Group 把一条记录的字段嵌套起来，再用 WithGroup 给后续日志建立稳定的分组前缀。

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

这篇只讨论 Group、GroupAttrs 与 Attrs 的组合。先记住一个判断：只影响当前记录时用 slog.Group；同一组字段会跟着日志器反复出现时，用 logger.WithGroup(...)；字段已经是 []slog.Attr 时，再用 slog.GroupAttrs 组装。

先看扁平字段为什么会变乱

假设订单服务每条日志都带请求和用户信息，最初的写法可能是下面这样。它能工作，但 method、id、role 等短键会逐渐变多，跨模块组合时还可能发生重名。

package main

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

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

	// 先用扁平字段记录同一条事件，便于对比分组前后的 JSON 层级。
	logger.LogAttrs(context.Background(), slog.LevelInfo, "order created",
		slog.String("service", "checkout"),
		slog.String("request_id", "req-42"),
		slog.String("method", "POST"),
		slog.String("user_id", "u-7"),
		slog.String("role", "buyer"),
	)
}

这条记录的字段都在同一层。真正的问题不是字段数量，而是字段的归属不清：以后订单也可能有 id，用户又可能有 role，检索条件很难表达“请求里的 method”和“用户里的 role”。分组的目标是先稳定键路径，再谈字段是否公共。

用 Group 让一条日志保持清晰层级

slog.Group 返回一个 Attr，所以它适合直接放进 LogAttrs。下面的 request 和 user 只属于这条“订单创建”日志，不会改变原来的 logger。

package main

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

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

	// Group 只包住当前记录的相关 Attr，不会给后续所有日志加前缀。
	logger.LogAttrs(context.Background(), slog.LevelInfo, "order created",
		slog.String("service", "checkout"),
		slog.Group("request",
			slog.String("id", "req-42"),
			slog.String("method", "POST"),
		),
		slog.Group("user",
			slog.String("id", "u-7"),
			slog.String("role", "buyer"),
		),
	)
}

JSON 结构会接近 {"request":{"id":"req-42","method":"POST"},"user":{"id":"u-7","role":"buyer"}}。这里两个分组都可以有自己的 id，因为完整键路径已经不同。若一组字段来自动态切片，不要手写一长串参数，下一节再处理。

公共字段用 WithGroup，动态字段用 GroupAttrs

当每条请求日志都会带同一组 request 字段时，可以先得到一个带分组前缀的日志器。WithGroup 影响返回的新日志器；原来的日志器仍可用于其他层级。With 则把公共属性附加到这个日志器的后续输出。

package main

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

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

	// 返回一个新 logger，把后续 Attr 放进 request 分组；不修改 base。
	requestLogger := base.WithGroup("request").With(
		slog.String("id", "req-42"),
		slog.String("method", "POST"),
	)

	// 动态字段先整理成 []slog.Attr，再用 GroupAttrs 组成一个 Attr。
	userAttrs := []slog.Attr{
		slog.String("id", "u-7"),
		slog.String("role", "buyer"),
	}
	requestLogger.LogAttrs(context.Background(), slog.LevelInfo, "order created",
		slog.GroupAttrs("user", userAttrs...),
		slog.String("order_id", "o-1001"),
	)
}

这段组合的关键是顺序：WithGroup("request") 先建立 request 前缀，With 放进去的 id 和 method 会归入 request；当前记录里的 GroupAttrs("user", userAttrs...) 再建立 user 子对象，order_id 则保持在当前 logger 的 request 分组下。

用键路径和基准指标检查分组是否值得

分组不是为了让 JSON 看起来更复杂，而是为了让下游查询有稳定的键路径。发布前可以先列出预期结构：service 在顶层，request.id、request.method 属于公共请求信息，request.user.id 或 user.id 则按你的日志器层级二选一，不能一边写嵌套一边在查询侧猜测。

性能方面，先记录相同日志量下的 ns/op、allocs/op 和日志字节数，再比较“每条记录重新构造 Group”和“公共字段放进 With/WithGroup”。下面是一个最小基准骨架；它只负责定义测量口径，输出数字应由你的 handler、字段数量和采样策略产生。

func BenchmarkGroupedLog(b *testing.B) {
	logger := slog.New(slog.NewJSONHandler(io.Discard, nil))
	ctx := context.Background()
	b.ReportAllocs()
	b.ResetTimer()

	for i := 0; i 

如果公共字段在一个请求生命周期内完全不变，可以把它们提前放到 WithGroup 和 With；如果字段只出现一次，直接 Group 往往更直观。比较时不要只看单个 ns/op：输出格式、handler 是否丢弃日志、Group 深度和字段数量都会改变结果。

几个容易踩到的边界

• 把分组当成字符串拼接：request.id 字符串键和真正的嵌套对象不是一回事，下游 JSON 查询也不同。
• 忘记 Attr 切片的展开：动态切片要写成 slog.GroupAttrs("user", attrs...)，不能把 []slog.Attr 当作一个普通值传入。
• 误以为 WithGroup 会修改原 logger：它返回新的 logger，建议用有语义的变量接住，避免后续代码误用扁平 logger。
• 嵌套过深：分组应该服务检索和阅读。稳定的 request、user、order 三层已经足够，再深就要重新评估字段是否真的属于同一对象。

最终可以用一句话做选择：一次性事件用 slog.Group，重复公共字段用 WithGroup 配合 With，动态属性集合用 GroupAttrs；然后用键路径和基准数据确认这层结构确实帮助了日志消费方。

相关问题

Group 和 WithGroup 有什么区别？ Group 是当前记录中的一个 Attr，WithGroup 返回带持久分组上下文的新 logger，影响该 logger 后续输出。

为什么需要 GroupAttrs？ 当字段已经收集在 []slog.Attr 中时，它能把切片展开成一个命名分组，适合中间件或字段装配函数。