Go slog.Handler WithAttrs 如何避免重复分配：属性分组、并发安全与自定义日志输出

自定义 log/slog Handler 时，最容易被忽略的不是如何打印一行日志，而是 WithAttrs 返回的新 Handler 到底保存了什么。属性如果每次都重新拼接，日志量一上来就会产生多余分配；如果直接复用可变切片，并发请求又可能看到互相污染的字段。

先把 WithAttrs 的问题缩小到一个 Handler

设想一个 HTTP 服务给每条日志附加 service、region 和 request_id。服务级字段在整个进程里都不变，请求级字段只属于当前调用。把三类字段混在一个可变数组里，既不好复用，也容易在异步写日志时踩到数据竞争。

一个实用的分界是：WithAttrs 只接收稳定属性，返回一个携带这些属性的新 Handler；Handle 再把当前 Record 的动态属性追加到输出。这样 Handler 可以被多个 goroutine 共享。

用不可变属性切片保存分组结果

下面的最小实现没有追求完整格式化，只展示关键生命周期。重点是复制输入属性，而不是把调用者传入的切片直接挂到 Handler 上。

type compactHandler struct {
    out   io.Writer
    attrs []slog.Attr
}

func (h *compactHandler) WithAttrs(as []slog.Attr) slog.Handler {
    next := make([]slog.Attr, 0, len(h.attrs)+len(as))
    next = append(next, h.attrs...)
    next = append(next, as...)
    return &compactHandler{out: h.out, attrs: next}
}

这里的 next 只在构造新 Handler 时分配一次。实际项目可以先过滤空属性、展开 Group，再按输出协议保存；但不要为了省一次复制而让多个 Handler 共享会被修改的底层数组。

Handle 只处理当前记录，不回写 Handler 状态

Handle 收到的是一条已经带时间、级别和消息的 slog.Record。它可以遍历 Handler 保存的稳定属性，再遍历记录里的动态属性，写入自己的局部缓冲区。局部变量在调用结束后消失，不会把 request_id 带到下一条请求。

func (h *compactHandler) Handle(ctx context.Context, r slog.Record) error {
    var b strings.Builder
    b.WriteString(r.Message)
    for _, a := range h.attrs {
        writeAttr(&b, a)
    }
    r.Attrs(func(a slog.Attr) bool {
        writeAttr(&b, a)
        return true
    })
    b.WriteByte('\n')
    _, err := io.WriteString(h.out, b.String())
    return err
}

如果输出目标本身不支持并发写入，还要在 Writer 外层加互斥保护，或交给具备串行能力的日志管道。属性切片不可变，并不等于底层输出天然线程安全。

性能检查：不要只看 WithAttrs 本身

WithAttrs 的一次分配可能换来很多次 Handle 的重复工作减少。验证时至少比较三种情况：每条记录临时拼接固定属性、先调用 WithAttrs、以及 WithAttrs 后仍然在 Handle 里重复展开 Group。

func BenchmarkLogAttrs(b *testing.B) {
    base := slog.New(&compactHandler{out: io.Discard})
    logger := base.With("service", "billing", "region", "cn-east")
    b.ReportAllocs()
    b.ResetTimer()
    for i := 0; i 

运行 go test -bench=LogAttrs -benchmem ./... 后，先看每次操作的分配次数，再看吞吐量。若换成 strings.Builder 后分配下降但锁竞争上升，说明瓶颈已经从属性整理移到了输出端，不能只凭一个数字下结论。

三个容易误判的边界

WithAttrs 能不能直接改接收者？

不建议。Handler 常被多个 logger 共享，原地 append 可能让不同 logger 互相看到新属性，甚至触发数据竞争。返回独立 Handler 更容易维持调用约定。

请求字段能不能提前放进 WithAttrs？

只有当这个 Handler 确实只服务一个请求生命周期时才可以。全局 logger 或长生命周期 logger 应把请求字段放进单条 Record，避免字段串线。

复制所有 Attr 就一定更快吗？

不一定。低频日志里，构造 Handler 的复制成本可能比省下的整理成本更明显；高频固定字段场景才更适合缓存。用实际日志量和基准结果决定。

把正确性和分配次数一起验收

验收自定义 Handler 时，先用竞态检测确认共享 logger 没有写入冲突，再用基准确认属性分组确实减少了重复工作。最后检查一条请求日志不会带上另一条请求的 request_id，这比单纯追求“零分配”更重要。

相关问题

slog.Handler 的 WithGroup 和 WithAttrs 应该先调用哪个？

取决于输出协议，但实现必须让两者返回的新 Handler 保留完整上下文；建议为每种组合写一条嵌套字段测试，确认组名不会丢失。

自定义 Handler 必须实现 Enabled 吗？

应该实现。根据级别提前返回可以避免低级别日志创建参数和进入格式化路径，尤其是调试日志很多的服务。

怎样确认 Handler 没有数据竞争？

让多个 goroutine 共享同一个 logger，运行 go test -race，同时检查 WithAttrs、WithGroup 和 Handle 是否都没有修改共享切片或共享缓冲区。