Go slog 日志如何稳定关联请求：组级属性、With 与并发字段验收

线上排查请求时，最难受的不是日志少，而是同一个请求的 request_id、路由和耗时散落在不同记录里，甚至在并发压力下看起来像串到了另一个请求。Go 标准库的 log/slog 可以把请求级字段绑定到派生 Logger，再让后续日志自动继承；关键是分清 With 的扁平属性和 WithGroup 的分组属性。

入口处创建一个请求专属 Logger，先用 With 绑定稳定字段；需要避免字段名冲突或表达嵌套对象时，再用 WithGroup。不要把可变请求字段塞进全局 Logger。

问题现场：日志能看到，却拼不回一次请求

一个常见的故障复盘场景是：入口日志带有 request_id，数据库日志只带 SQL，响应日志又只剩状态码。开发者为了补字段，往往在多个函数签名之间来回传值，或者把字段写进一个全局 Logger。单请求时看不出问题，一上并发就可能出现字段遗漏、键名覆盖和请求之间的误关联。

这次我们把边界收窄说清楚：Logger 是不可变风格的派生对象，但 Handler 是否并发安全、字段值会不会被意外改写，仍然需要业务代码自己保证。我们的目标不是做完整链路追踪，而是让一条请求内的所有结构化日志都具备稳定的最小上下文。

最小修复：在请求入口派生 Logger

把请求字段绑定逻辑放在请求入口处，后续所有业务函数只接收派生出来的 Logger 实例。下面的代码使用 JSON Handler，便于直观观察字段结构；生产环境也可以换成文本 Handler，这套派生规则完全不变。

package main

import (
    "log/slog"
    "os"
)

func handle(logger *slog.Logger) {
    logger.Info("load profile", "profile_id", 42)
}

func serveRequest(requestID, route string) {
    base := slog.New(slog.NewJSONHandler(os.Stdout, nil))
    reqLog := base.With("request_id", requestID, "route", route)
    reqLog.Info("request started")
    handle(reqLog)
    reqLog.Info("request finished", "status", 200)
}

func main() {
    serveRequest("req-7f3a", "/profiles/42")
}

这段代码的验收点很具体：三条记录都应有同一个 request_id 和 route，而 profile_id 只出现在业务日志。不要在 handle 里重新创建一个没有请求字段的 Logger，否则上下文会在函数边界丢失。

With 和 WithGroup 的差别，决定字段长什么样

With 适合扁平字段，例如 request_id、route 和 status。多个属性可以一次传入，也可以分多次调用；派生 Logger 会保留之前绑定的属性。

reqLog := base.With("request_id", requestID)
reqLog = reqLog.With("route", route)
reqLog.Info("started")

当一组字段需要明确归属时，用 WithGroup：

reqLog := base.WithGroup("http")
reqLog = reqLog.With("method", "GET", "route", route)
reqLog.Info("request", "status", 200)

JSON 输出会把后续属性放入 http 组中。分组适合多个来源都可能出现 id、status 这类通用键的场景，但不要为了“看起来整齐”把所有字段都嵌一层；查询日志时，字段路径本身也是约定，改动会影响检索规则。

根因定位：全局 Logger 和可变字段最容易制造假线索

如果把当前请求 ID 放到全局变量，再让多个 goroutine 读取，日志串行输出时看不出问题，协程交错执行时就会把 A 请求的字段串到 B 请求的日志里。另一个隐蔽问题是把 map、slice 或自定义对象作为属性值之后继续修改它，Handler 真正记录时看到的内容可能不是绑定瞬间的快照。

更稳妥的落地规则是：请求字段优先用字符串、数字这类不可变值绑定；复杂值先做拷贝或转换成稳定的基础日志属性。全局 Logger 只保留服务名、版本等进程级字段，请求级字段永远从全局根 Logger 派生。

并发验收：证明字段没有跨请求污染

不要只测一条手工构造的单条日志。启动两个请求同时执行，让业务逻辑故意留出等待时机，再检查每个请求打出的所有记录是否始终携带自己的专属ID。测试可以把 Handler 接到内存日志收集器，也可以先用 JSON 输出再解析校验，验收逻辑的严谨性比输出格式更重要。

func serve(base *slog.Logger, requestID string, ready, done chan struct{}) {
    logger := base.With("request_id", requestID)
    logger.Info("started")
    ready 

实际项目里建议再加三项检查：请求取消后是否仍能写出必要的收尾状态；异常日志是否沿用同一个派生 Logger；Handler 的级别过滤是否让关键字段只出现在部分日志记录里。只要其中一项不一致，后续排查工具就会把同一次请求拆成多条互不相干的线索。

回滚与防复发：把日志字段当作接口契约

上线前先定好统一的字段契约：进程级字段、请求级字段和业务级字段分别包含哪些，分组路径怎么设计，哪些字段允许为空。迁移时先让旧字段继续输出，再逐步切换检索规则，避免日志格式改动后，告警查询和排障脚本同时失效。

如果新 Handler 导致输出量或字段体积明显上升，先回退 Handler 配置，不要直接推翻之前定好的请求 Logger 边界设计。字段绑定规则和输出格式是两层独立逻辑，拆开处理更容易定位影响。

相关问题：几个容易混淆的边界

With 会修改原来的 Logger 吗？

不会。它返回带有附加属性的派生 Logger，原 Logger 仍可供其他请求继续派生。应用代码仍应避免把带请求字段的 Logger 放到全局变量。

WithGroup 只是给字段名加前缀吗？

不应简单理解成字符串拼接。具体嵌套形式由 Handler 处理，JSON Handler 会表现为对象层级，文本 Handler 的展示方式可能不同。查询规则要以实际 Handler 输出为准。

需要用 slog 代替分布式追踪吗？

不需要。slog 解决结构化日志和字段继承问题，不能自动提供跨服务 trace、span 和采样策略。跨服务场景仍应接入专门的追踪方案，并让日志字段与追踪标识保持约定一致。

把 Logger 的派生位置、字段分组和并发隔离先固定下来，slog 才会真正成为排障可靠证据，而不是另一种格式更漂亮的字符串日志。