Go slog.Handler.WithAttrs 如何给请求日志补充稳定上下文：字段快照与并发输出

线上请求日志最怕两件事：同一条记录缺了 request_id，或者公共字段在不同分支里被重复写入，最后检索出来的 JSON 结构并不稳定。Go 的 log/slog 可以把这些稳定字段提前放进派生 Logger；需要直接操作 Handler 时，Handler.WithAttrs 会返回一个带预绑定属性的新 Handler。关键边界是：绑定的是属性快照，真正随请求变化的字段仍应在每次日志调用时传入。

把服务名、请求 ID 这类“本次请求不变”的字段放进 WithAttrs，把状态码和耗时留给 LogAttrs；这样日志结构更稳定，也更容易做并发验收。

先把请求日志拆成两层字段

这个小项目只做一件事：模拟一个名为 requestHandler 的 HTTP 请求处理器，让每条日志都带上 service、request_id 和 method，再在请求结束时写入 status 与 duration_ms。前三个字段在一次请求内不会变化，后两个字段要等业务处理结束才知道。

slog.Logger 的输出方法会把消息和属性组成 Record，交给关联的 Handler。如果直接使用 logger.With，可以从 Logger 层完成公共字段绑定；本文再把同一条链路展开到 Handler.WithAttrs，方便理解 Handler 装饰器到底保存了什么。

package main

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

func newRequestLogger(service, requestID, method string) *slog.Logger {
    base := slog.New(slog.NewJSONHandler(os.Stdout, nil))
    return base.With(
        "service", service,
        "request_id", requestID,
        "method", method,
    )
}

func handle(ctx context.Context, logger *slog.Logger, status int, durationMS int64) {
    logger.LogAttrs(ctx, slog.LevelInfo, "request finished",
        slog.Int("status", status),
        slog.Int64("duration_ms", durationMS),
    )
}

运行这段代码时，JSONHandler 会输出一行结构化 JSON。验收不要只看文本里“像是有字段”，而要确认同一个 request_id 下，公共字段只出现一次，结束日志同时含有 status 和 duration_ms。

用 Handler.WithAttrs 固定公共字段

当组件拿到的是 slog.Handler 而不是完整 Logger 时，直接调用 WithAttrs 更合适。它返回一个新的 Handler：原 Handler 仍可使用，派生 Handler 在处理后续 Record 时会把预绑定属性一起带上。

func newHandler(service, requestID, method string) slog.Handler {
    base := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{})
    return base.WithAttrs([]slog.Attr{
        slog.String("service", service),
        slog.String("request_id", requestID),
        slog.String("method", method),
    })
}

func writeFinished(ctx context.Context, h slog.Handler, status int, durationMS int64) error {
    record := slog.NewRecord(time.Now(), slog.LevelInfo, "request finished", 0)
    record.AddAttrs(
        slog.Int("status", status),
        slog.Int64("duration_ms", durationMS),
    )
    return h.Handle(ctx, record)
}

这里的 WithAttrs 不是“把属性追加到一个全局可变切片”。内置 Handler 会按自身实现保存这些属性，后续每次 Handle 都能看到它们。业务代码只把结果字段放进当前 Record，避免在每条分支里重复拼接 service 和 request_id。

注意示例中 time.Now 需要补充 time 导入；如果把这段代码复制到项目里，先让编译器完成导入检查，再做日志结构验收。

并发请求时检查字段快照，而不是只看一行输出

请求日志通常来自多个 goroutine。对内置 JSONHandler，可以并发调用派生 Logger，并检查每个请求的 request_id 是否仍与 method 配对。测试重点不是让所有日志按固定顺序出现，而是每个 JSON 对象内部的字段不能串请求。

var wg sync.WaitGroup
for _, req := range requests {
    req := req
    wg.Add(1)
    go func() {
        defer wg.Done()
        logger := newRequestLogger("checkout", req.id, req.method)
        handle(context.Background(), logger, 200, req.durationMS)
    }()
}
wg.Wait()

更严格的验收方式是把输出写入缓冲区，逐行解码 JSON，再按 request_id 建索引。不要用字符串包含判断替代解析：字段顺序不是契约，JSON 中的数值类型也不应被当成字符串比较。

如果换成自定义 Handler，要重新审查它的 Handle、WithAttrs 和内部缓冲区是否支持并发调用。标准接口能表达能力边界，但不会替你给一个带可变状态的自定义实现加锁。

几个容易把日志写乱的细节

不要把变化字段绑定到请求外的共享 Logger

request_id、状态码和耗时必须属于单次请求。把它们写进全局 Logger，下一次请求就可能继承上一条记录的上下文；用派生 Logger 或派生 Handler，让生命周期跟请求一致。

不要把 WithAttrs 当成去重器

如果同一个键既出现在预绑定属性，又出现在当前 Record，最终如何呈现取决于 Handler 的处理方式。字段规范应由调用方约束：公共键在一处绑定，变化字段使用不同键名。

不要用固定输出顺序判断并发正确

并发场景只保证每条记录的内部关联关系，不保证多条日志的完成顺序。测试应验证 request_id、method、status 的同记录一致性，并允许行顺序变化。

把验收标准落到三条断言

这个小项目完成后，可以用三条断言收口：第一，每条“request finished”记录都有 service、request_id、method；第二，结束记录同时有 status 和 duration_ms；第三，并发运行多次后，不存在某个 request_id 对应了另一请求的 method。

Handler.WithAttrs 适合把稳定上下文提前装入 Handler，但它不是业务状态容器，也不会替自定义 Handler 解决数据竞争。把字段生命周期、Handler 实现和 JSON 解析验收放在一起，日志才不会只在开发机上“看起来正常”。

相关问题

Handler.WithAttrs 会修改原来的 Handler 吗？

接口语义是返回一个带属性的 Handler，调用方应把返回值保存为派生 Handler 使用；不要假设原 Handler 会被原地改写。

为什么请求结果不直接放进 WithAttrs？

因为状态码和耗时要到处理结束才确定，而且它们属于当前 Record。提前绑定会扩大生命周期，也容易把一次请求的结果带到下一次请求。

自定义 Handler 需要自己加锁吗？

如果实现内部有可变缓冲区、复用切片或共享状态，就必须根据并发调用路径设计同步或隔离；不能因为外层类型是 slog.Handler 就默认实现天然安全。