日志上下文

我在给 HTTP 请求补充 request_id 和模块名时，最容易误解的一点是：log/slog 的 With 看起来像“给当前日志器加字段”，实际却是在创建一个带新 Handler 状态的派生 Logger。之后由这个派生 Logger 写出的记录会带上公共字段，原 Logger 不会被改写。

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

把 Logger 当成上下文分支最稳妥：模块级字段先用 With 固定，请求级字段再从它派生，单条事件字段直接放进本次日志调用。这样既能复用属性，也不会让一次请求的字段意外污染全局日志。

• 作用域：With 影响返回的新 Logger 的后续记录。
• 不变性：旧 Logger 保留原有 Handler 和输出语义。
• 顺序：WithGroup 与 With 的调用顺序决定字段所在命名空间。

为什么 With 会影响后续记录

从使用体验看，logger.With("service", "billing") 更像“复制一个上下文对象”，而不是修改共享变量。官方接口把 Handler.WithAttrs 定义为返回一个新 Handler，它同时拥有接收方已有属性和新增属性；Logger 的 With 会把键值转换成 Attr，再调用这个 Handler 方法。

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

// With 返回派生 Logger；公共字段只进入 billing，不会回写 base。
billing := base.With("service", "billing")

// 这条记录使用派生 Logger，因此会带 service=billing。
billing.Info("charge created", slog.String("order_id", "A-100"))

// 原 Logger 仍然可以输出不带 service 的记录。
base.Info("health check")

这里的“后续”不是把过去已经写出的记录补上字段，而是派生 Logger 持有新的 Handler 语义，后续通过它进入的记录才会看到这些 Attr。对我来说，这种分支模型比在业务函数里反复拼接公共字段更容易维护。

WithGroup 和 With 的顺序为什么重要

当日志字段需要分组时，WithGroup 负责建立命名空间，With 负责把属性放进当前命名空间。官方 Handler 指南特别强调，两者的调用顺序必须保留；先建立哪个组、再加入哪些字段，决定字段归属。

requestLogger := base.
	WithGroup("request").
	With("request_id", "r-42").
	WithGroup("handler").
	With("name", "CreateInvoice")

// request_id 属于 request 组，name 位于 request.handler 语义下。
requestLogger.Info("started")

如果自定义 Handler 只把所有 Attr 放进一个扁平切片，或者忽略了组与属性交错出现的顺序，就可能出现字段被放错层级的问题。使用内置 TextHandler 或 JSONHandler 时，可以把 WithGroup 理解为键前缀或嵌套对象边界，但具体格式由 Handler 决定。

我会怎样安排日志上下文

我的做法通常分三层：应用启动时创建基础 Logger；模块初始化时派生带 service、component 的 Logger；进入请求后再派生带 request_id 的 Logger。真正只描述一次事件的订单号、耗时或错误原因，则留在单条记录的 Attr 中。

这样安排的代价是 Logger 分支会变多，但边界很清楚：共享的字段靠派生，瞬时的字段靠事件。不要把用户隐私、认证凭据或完整请求体当作公共上下文；也不要把“能从 Context 读取”误认为“必须把所有值自动写进日志”。

常见问题

WithAttrs 会修改原来的 Handler 吗？

按 Handler 接口语义，它应返回包含新增属性的新 Handler，并保留原 Handler 的行为。自定义实现也应遵守这个不可变分支约定。

With 添加的字段会补到之前的日志吗？

不会。它只影响使用返回的新 Logger 写出的后续记录，已经写出的记录不会被回溯修改。

WithGroup 和 With 可以随便调换吗？

不建议。两者交错调用时，字段属于哪个组取决于调用顺序；如果需要自定义 Handler，应按官方指南保留这条语义。