Go log/slog Record.Clone 怎样复制结构化日志记录

在自定义 log/slog.Handler 里，如果只是把 Record 原样交给一个下游处理器，普通值传递通常就够了；但只要准备给记录追加属性、把它分到多个处理分支，或者让某个分支继续持有它，就应该先调用 Record.Clone。原因是 Record 的公开字段只是其中一部分，属性集合还可能通过隐藏状态共享。

先看清 Record 为什么不能只当普通结构体复制

slog.Record 包含 Time、Level、Message 和 PC 等公开字段，同时还维护属性列表。官方文档特别提醒：Record 的复制品可能共享状态，因此对简单副本调用 Add 或 AddAttrs，可能产生对原记录也可见的意外影响。

下面的例子只展示风险来源，不建议把这种普通赋值当成“独立副本”：

func addRouteField(r slog.Record, route string) slog.Record {
    // 值复制只复制 Record 外层值，不能自动切断属性列表的共享状态。
    copied := r
    copied.AddAttrs(slog.String("route", route))
    return copied
}

理解这件事的关键不是把所有字段都手动拷贝一遍，而是把“记录元数据”和“属性状态”分开看。图 1 用两个静态分组表示这层关系：公开元数据可以随值传递，属性集合则需要由 Clone 明确切断共享。

修改前调用 Record.Clone，得到真正可独立追加的副本

Record.Clone 返回一个不与原记录共享状态的副本。原记录和克隆记录都可以继续修改而不互相干扰，这正适合 Handler 在转发前补充内部字段：

func withHandlerMeta(r slog.Record, handlerName string) slog.Record {
    // 先切断属性状态共享，再给当前处理分支添加字段。
    cloned := r.Clone()
    cloned.AddAttrs(slog.String("handler", handlerName))
    return cloned
}

这里的 handler 不是业务日志原始字段，而是当前处理分支的元数据。把它追加到克隆上，可以保证原始记录仍保持调用方看到的内容；另一个分支也可以追加自己的字段。

需要注意，Clone 解决的是 Record 内部属性状态的共享问题，不会替你复制属性值指向的任意业务对象。若属性值本身包装了可变指针，仍要按该对象自己的所有权规则处理。

只读检查用 Attrs，修改操作集中在克隆记录上

当 Handler 只是判断某个属性是否存在、统计字段或把属性映射到另一个输出结构时，不需要修改原 Record。可以使用 Attrs 遍历属性；回调返回 false 时会提前停止：

func hasTenant(r slog.Record, want string) bool {
    found := false
    r.Attrs(func(attr slog.Attr) bool {
        // 只读遍历不会改变 Record；找到目标后停止后续扫描。
        if attr.Key == "tenant" && attr.Value.String() == want {
            found = true
            return false
        }
        return true
    })
    return found
}

一个实用的分工是：先用 Attrs 做只读决策，确定需要改写时再 Clone。这样可以把复制成本限制在真正需要修改或分发的路径上，同时让代码明确表达“读”和“写”的边界。

多个 Handler 分支怎样避免互相污染

如果一个 Handler 同时把记录送往文本分支、审计分支和指标分支，每个分支都有自己的追加字段，最容易出错的方式是让分支共享同一个可修改副本。更稳妥的做法是：原记录保持只读，每个会修改属性的分支各自 Clone。

func fanOut(ctx context.Context, r slog.Record, audit, text slog.Handler) error {
    // 审计分支和文本分支各自拥有独立的属性状态。
    auditRecord := r.Clone()
    auditRecord.AddAttrs(slog.Bool("audit", true))

    textRecord := r.Clone()
    textRecord.AddAttrs(slog.String("format", "text"))

    // 两个分支都完成自己的 Handle，错误按调用方策略返回。
    if err := audit.Handle(ctx, auditRecord); err != nil {
        return err
    }
    return text.Handle(ctx, textRecord)
}

这段代码的重点不是“必须串行调用两个 Handler”，而是每个会修改记录的所有者都有自己的 Clone。真实系统若要并行处理，还应另外设计错误聚合、取消信号和 Handler 的并发安全性；这些问题不由 Record.Clone 自动解决。

什么时候用 NewRecord，而不是继续 Clone

Clone 适合“保留原记录的时间、级别、消息和来源，只额外补充属性”。如果要把事件改造成另一条日志，例如替换时间、级别或消息，使用 NewRecord 会更直观：

func rewriteMessage(r slog.Record, message string) slog.Record {
    // 保留原记录的时间、级别和程序计数器，只替换消息文本。
    rebuilt := slog.NewRecord(r.Time, r.Level, message, r.PC)

    // 通过只读遍历把原属性重新追加到新 Record。
    r.Attrs(func(attr slog.Attr) bool {
        rebuilt.AddAttrs(attr)
        return true
    })
    return rebuilt
}

这条路径的成本是要重新遍历和追加属性，但意图很清楚：新记录的基础元数据由调用方重新定义，属性也由调用方按顺序构建。不要为了改变一个消息就手动修改隐藏状态；要么 Clone 后只补字段，要么 NewRecord 后显式重建。

按场景选择复制策略

可以把判断压缩成一句话：只读就遍历，补属性就 Clone，重塑基础事件就 NewRecord。如果记录要跨 goroutine 或异步队列长期保存，除了 Record 本身，还要确认属性值引用的业务对象是否具备独立生命周期。

常见问题

普通的 r2 := r 为什么看起来有时也能工作？

如果后续不修改属性，或者修改动作恰好没有触发共享存储的可见差异，问题可能暂时不显现。但这不是稳定的独立副本语义；一旦 Handler 开始追加属性，就应改用 Clone。

Clone 会不会把所有业务属性对象都深复制？

不会。Clone 负责让 Record 自身的属性状态不再共享；属性值里如果装着指针、切片或其他可变对象，仍需遵循这些对象自己的复制和并发规则。

只读遍历时可以保存 Attr 供异步使用吗？

要看 Attr 中的 Value 是否引用了外部可变对象。若需要跨生命周期保存，建议先把需要的字段转换成拥有独立生命周期的值，再交给异步任务。