Go slog.Record Clone 怎样隔离 Handler 的共享状态

自定义 slog.Handler 时，判断是否调用 Record.Clone 的标准很简单：如果记录只在当前 Handle 调用中同步读取，可以直接使用；如果要把它保存到队列、交给多个下游，或在当前调用返回后继续使用，就先克隆。普通的 slog.Record 复制可能共享内部状态，Clone 才是隔离副本的明确边界。

普通传值与 Clone 的共享边界

Handle(ctx, r slog.Record) 看起来已经按值接收记录，但 Record 内部仍可能持有共享的属性存储。给另一个函数传值、把它放进闭包，不能自动变成独立快照。只要后续代码会保存副本、并发处理或让多个输出分支分别消费，应该在交接点调用 Clone。

下面的 Handler 示例把一份记录交给两个异步消费者。原始 r 仍用于当前 Handler 的计数，两个副本分别进入不同队列；真实项目还要给队列设置容量和关闭策略。

type FanoutHandler struct {
	left  chan slog.Record
	right chan slog.Record
}

func (h *FanoutHandler) Handle(ctx context.Context, r slog.Record) error {
	// 多个下游会在 Handle 返回后继续读取，所以各自拿到独立副本。
	leftRecord := r.Clone()
	rightRecord := r.Clone()

	select {
	case h.left 

什么时候调用 Clone 才不会过度复制

不要把 Clone 当成每次日志都必须执行的模板。只在“记录所有权要离开当前同步调用”这个时刻复制即可。单个 Handler 在当前栈内调用 r.Attrs、解析值并立即写入一个线程安全的输出，通常无需额外 Clone；写入 goroutine、批处理缓存、重试列表或多个不同时序的 sink，则应在交接前复制。

属性遍历要保留记录顺序

自定义 Handler 不应假设属性一定能无损地放进 map[string]any。Record.Attrs 会按记录中的顺序访问每个 Attr；分组属性的值还可能是 Group，同名属性也可能出现多次。若业务确实需要字典，应先规定重复键覆盖规则，并明确组名如何拼接。

func collectAttrs(r slog.Record) []string {
	var result []string
	r.Attrs(func(a slog.Attr) bool {
		// Resolve 先展开 LogValuer，Group 则保留为结构化值处理。
		value := a.Value.Resolve()
		if value.Kind() == slog.KindGroup {
			result = append(result, a.Key+"=")
		} else {
			// 不用 map 覆盖同名键，保留事件原有顺序。
			result = append(result, a.Key+"="+value.String())
		}
		return true
	})
	return result
}

并发交接和关闭流程的复查清单

Clone 只解决 Record 内部状态的隔离，不会自动解决队列满、消费者退出、Handler 自身字段竞争或输出端关闭顺序。上线前可以按下面顺序复查：

1. 确认每个异步任务拿到的是 Clone 或已经提取出的自有字段，而不是闭包里继续引用原始 Record。
2. 确认多个 goroutine 调用 Handler 时，队列、计数器和下游 Writer 的并发约束分别成立。
3. 确认上下文取消时不会无限阻塞在入队操作，关闭时先停止生产再等待消费者排空。
4. 确认属性处理保留组层级和重复键规则，错误分支不会把半成品记录再次交给下游。

相关问题

只把 Record 传给一个同步函数，也需要 Clone 吗？

通常不需要。只要被调用函数在当前调用链中完成读取，不把 Record 保存到 goroutine、缓存或回调里，直接传值即可。

Clone 能不能代替 Handler 的互斥锁？

不能。Clone 隔离的是记录内部状态；Handler 的共享计数器、队列和 Writer 仍需使用合适的并发设计。

为什么不直接把属性转成 map？

map 会丢失顺序，并迫使你决定重复键覆盖规则。日志需要保留分组结构时，应先遍历 Attr，再按业务协议编码。