Go slog.Logger.With 如何避免共享字段污染：日志上下文、并发与测试隔离

线上日志里出现过一次很难抓的错：请求 A 的 tenant_id 偶尔出现在请求 B 的记录里。排查后发现，问题不在 slog 的 JSON 输出，而是团队把带请求字段的 logger 放进了共享变量。理解 Logger.With 的返回值和生命周期，才能把这类串线彻底挡住。

先看清 Logger.With 到底改变了什么

With 的直觉误区是“给 logger 增加字段”。更准确的说法是：它构造并返回一个附带属性的新 Logger，原来的 Logger 仍可被其他请求安全复用。下面的最小例子把两条日志的字段关系直接固定下来。

package main

import (
    "log/slog"
    "os"
)

func main() {
    base := slog.New(slog.NewJSONHandler(os.Stdout, nil))
    orderLog := base.With("request_id", "req-1001", "tenant_id", "acme")

    base.Info("health check")
    orderLog.Info("order loaded", "order_id", "o-9")
}

预期结果是第一条只有事件自身字段，第二条才有 request_id、tenant_id 和 order_id。如果调用 With 后基础变量本身也出现了请求字段，通常是把另一个可变日志封装层误当成了 slog.Logger，或者在外层重新覆盖了共享变量。

并发请求为什么会出现字段串线

最危险的写法不是调用 With，而是把派生结果赋回共享 logger：

var log = slog.Default()

func handle(requestID, tenantID string) {
    log = log.With("request_id", requestID, "tenant_id", tenantID)
    log.Info("handle request")
}

两个 goroutine 同时进入时，谁先覆盖 log 没有稳定顺序；即便没有立刻触发数据竞争，后一个请求也可能继承前一个请求的字段。请求级 logger 应该是局部变量：

var baseLog = slog.Default()

func handle(requestID, tenantID string) {
    requestLog := baseLog.With(
        "request_id", requestID,
        "tenant_id", tenantID,
    )
    requestLog.Info("handle request")
}

这里的检查点很简单：baseLog 只保存服务级字段，例如 service 和 version；requestLog 只在当前请求函数里存在。不要用锁把共享 logger 的覆盖动作包起来，那只是把串线从“同时发生”变成“按顺序污染”。

用两个请求把并发隔离跑出来

要验证修复是否有效，别只跑一次串行调用。让两个请求使用明显不同的字段，并把输出写到内存缓冲区，再逐行解码 JSON。重点不是比较日志顺序，而是比较每条记录中的字段归属。

var output bytes.Buffer
handler := slog.NewJSONHandler(&output, nil)
baseLog := slog.New(handler)

var wg sync.WaitGroup
for _, item := range []struct{ id, tenant string }{
    {"req-a", "tenant-a"},
    {"req-b", "tenant-b"},
} {
    item := item
    wg.Add(1)
    go func() {
        defer wg.Done()
        baseLog.With(
            "request_id", item.id,
            "tenant_id", item.tenant,
        ).Info("handle request")
    }()
}
wg.Wait()

真实测试中应避免多个 goroutine 直接同时写同一个普通 bytes.Buffer，可以使用带同步保护的写入器或逐条收集记录。验收结果至少包括：req-a 只能对应 tenant-a，req-b 只能对应 tenant-b，并且基础 logger 没有动态字段。

测试用例之间也需要重新派生 logger

测试污染通常更隐蔽：测试包里有一个全局 logger，某个用例为了方便把 case_id 加进去，后续用例就带上了不属于自己的字段。每个用例都从不变的 testBaseLog 派生一次，日志字段的边界就清楚了。

func TestOrder(t *testing.T) {
    testLog := testBaseLog.With("case_id", t.Name())
    testLog.Info("arrange")
    // 调用被测函数，并检查输出中的 case_id
}

如果被测函数接收的是 *slog.Logger，把派生 logger 作为参数传进去；如果它只接收 context.Context，则把取消信号和请求数据放在上下文里，同时保持 logger 的构造位置明确。不要为了“省一个参数”把测试 logger 藏进包级变量。

几种看似合理的修复其实不够

只在输出前删除动态字段

删除字段治标不治本：字段可能已经被错误地用于日志级别判断、采样或下游关联。正确边界是从源头让请求 logger 局部化。

把所有字段都放进 Context

Context 适合取消、截止时间和请求范围的数据，不适合承载完整 logger 或大对象。日志器应该按依赖关系显式传递，别让隐藏依赖扩大。

看到输出顺序不同就判定串线

并发日志的顺序本来就不稳定。判断依据应是同一条记录内的字段是否匹配，而不是 req-a 是否总在 req-b 之前。

发布前的四项反向确认

• 基础 logger 在健康检查日志中没有 request_id、tenant_id 这类动态字段。
• 请求入口每次都用局部变量接住 baseLog.With(...) 的返回值。
• 并发测试同时覆盖至少两组互不相同的请求号、租户和测试用例名称。
• 日志下游按字段归属验收，不把输出先后顺序当成并发正确性的证据。

相关问题

Logger.With 返回的新 logger 能跨请求复用吗？

可以复用，但前提是它只包含稳定的服务级字段。带有请求号、租户号等动态属性的派生 logger 应限制在对应请求链路内。

是否需要给每个 logger 加互斥锁？

通常不需要靠业务层锁保护 slog.Logger 的正常调用；真正要避免的是把请求级派生 logger 重新写回共享变量，以及让不安全的自定义写入器并发接收数据。

怎么快速发现测试字段泄漏？

让每个测试使用明显不同的 case_id，然后断言日志中只出现当前用例的值。再用 go test -race 检查是否存在共享变量竞争。

小结

slog.Logger.With 的安全用法可以归结为一句话：共享基础 logger，局部派生请求 logger。把派生结果赋回共享变量，问题就从字段管理变成了生命周期和并发边界问题；把它留在请求或测试用例内部，再用字段配对断言验证，日志串线就有了明确的发现路径。