Go slog.Record.Clone 什么时候必须调用：异步 Handler 处理与属性生命周期

自定义 slog.Handler 时，最容易被忽略的不是日志格式，而是 Record 什么时候会被保留、复制或修改。只把一条记录转交给下游 Handler，普通值传递通常够用；一旦要 fan-out 给多个 Handler，或把记录放进异步 channel，就应该先调用 Record.Clone，把后续生命周期和原记录分开。

判断标准很简单：不保留、只传一份，可以直接传；要修改、分发多份或跨当前调用异步保存，先 Clone。

先分清 Record 是“传递”还是“保存”

Handler.Handle 收到的是一个 slog.Record 值。Go 的值传递容易让人产生“复制后绝对互不影响”的错觉，但 Record 内部可能持有属性切片等共享状态。官方 Handler 约定还特别强调：Handler 的方法可能与自身或其他方法并发调用，具体的并发保护由 Handler 负责。

所以问题不在于“写没写指针”，而在于下游会做什么：

• 只调用一个下游 Handler，当前调用结束前不保留 Record：可以直接传。
• 要给两个下游 Handler，或在当前 Handler 中调用 r.AddAttrs、r.Add：先得到独立副本。
• 要把 Record 发送到异步 channel，让当前 Handle 返回后继续用：发送前 Clone。

单份转发可以直接传，多份分发必须拆开

一个包装 Handler 只是给单个下游加一层边界时，不需要无条件 Clone。下面的 Handle 只把记录交给一个 next，它没有保存原记录，也没有修改后再复用：

type ForwardHandler struct {
    next slog.Handler
}

func (h ForwardHandler) Handle(ctx context.Context, r slog.Record) error {
    return h.next.Handle(ctx, r)
}

如果改成多个下游，就不能把同一个可继续修改的状态交给所有分支。每个分支拿到 r.Clone()，其中一个 Handler 添加属性，不会把变化泄漏给另一个 Handler：

type FanoutHandler struct {
    targets []slog.Handler
}

func (h FanoutHandler) Handle(ctx context.Context, r slog.Record) error {
    for _, target := range h.targets {
        if err := target.Handle(ctx, r.Clone()); err != nil {
            return err
        }
    }
    return nil
}

这里的关键不是“循环里必须 Clone”这句口诀，而是每个分支都可能修改或保留 Record。若下游始终只读、并且你能证明没有共享状态被后续修改，复制策略可以更精细；公共 Handler 通常不值得押这个隐含前提。

异步 channel 是生命周期分界线

把日志交给后台 goroutine 时，Handle 会先返回，生产端和消费端的执行时机已经分开。此时应在发送到 channel 前 Clone，并让消费端只处理这份独立记录：

type AsyncHandler struct {
    queue chan slog.Record
}

func (h *AsyncHandler) Handle(ctx context.Context, r slog.Record) error {
    copy := r.Clone()
    select {
    case h.queue 

消费循环还要考虑队列关闭、退出和下游错误。Clone 只解决记录的共享状态，不会自动替你处理 channel 的所有权，也不会让阻塞发送变成无损队列。日志系统如果允许丢弃，应在队列满时明确记录丢弃策略。

修改 Record 前先建立自己的副本

常见需求是给每条日志补一个租户或组件属性。若 Handler 还要把原记录交给别的目标，修改动作应作用在副本上：

func addComponent(ctx context.Context, next slog.Handler, r slog.Record) error {
    copy := r.Clone()
    copy.AddAttrs(slog.String("component", "billing"))
    return next.Handle(ctx, copy)
}

如果先在原值上添加属性，再尝试把它“恢复”回来，代码会同时承担共享属性存储和并发访问的风险。把 Clone 放在修改前，意图更直接，回归测试也更容易写。

用三组测试验收迁移边界

单份同步转发

验证包装 Handler 只调用一个目标，且 Handle 返回后没有后台引用；这条路径不应凭习惯制造额外副本。

多目标分发

让第一个目标添加 component 属性，第二个目标检查自己收到的记录没有这项属性。测试重点是分支隔离，而不是日志文本的排序。

异步退出与错误

让 ctx.Done 在队列发送前触发，检查 Handle 能返回上下文错误；再让消费者的下游 Handler 返回错误，确认退出策略和错误记录符合应用约定。

相关问题

Record 是结构体，为什么还需要 Clone？

结构体复制只保证顶层值复制；Record 内部可能引用共享属性状态。Clone 的契约是返回没有共享状态的副本。

只读 Handler 也必须 Clone 吗？

如果只同步传给一个目标且不保留，不必为了形式 Clone；要多份传递、跨调用保存或后续修改时再 Clone。

Clone 能解决 Handler 的并发安全问题吗？

不能。Handler 方法可能并发调用，锁、队列容量、关闭顺序和错误处理仍由 Handler 自己负责。

小结

Record.Clone 的使用时机由生命周期决定：单份同步转发保持简单，多份分发和异步保存明确隔离。把这条边界写进 Handler 的测试和注释，后续增加字段、下游目标或后台队列时，就不容易把一条日志的属性变化带到另一条路径。