Go bytes.Buffer 复用后数据为什么变了：Reset、Bytes 别名与拷贝边界

消息网关里有一段很省内存的写法：用 bytes.Buffer 拼完一条消息，调用 Bytes() 交给下游，再把同一个 Buffer 清空复用。压测时偶尔出现“上一条消息变成了下一条”的现象，日志看起来像下游把数据改坏了，其实更常见的原因是保存了 Buffer 的底层切片视图。

bytes.Buffer 复用后旧数据被覆盖，本质上是你拿到的 Bytes 返回值不是独立快照，只是指向底层数组的临时切片视图，Reset 操作只重置读写位置不释放原有内存，后续写入直接复用同一块空间时，旧切片里的内容就会跟着被改写。

先复现：Bytes 返回的不是快照

下面的例子没有并发，只有一次复用，就足以看到问题：

var buf bytes.Buffer
buf.WriteString("order:1001")
oldPayload := buf.Bytes()

buf.Reset()
buf.WriteString("order:1002")

fmt.Println(string(oldPayload)) // 可能已经变成 order:1002

这里的“可能”很重要。只要第二次写入仍落在原来的容量范围内，Buffer 通常会复用原数组，oldPayload 就会看到新内容；如果新内容触发扩容，旧切片又可能暂时保持原值。不要把一次运行结果当成契约，真正的契约是：Bytes() 返回的切片只在下一次修改 Buffer 前可靠。

Reset 改了位置，底层数组可能还在

Reset() 的作用是把 Buffer 恢复到空状态，同时保留已经申请的存储空间，方便下一轮写入。它不是“擦除并分配新内存”。因此下面两个对象可能共享同一块数组：

所以排查时别急着给 Reset() 加更多调用。先画出数据的生命周期：谁拿到了 Bytes() 的结果，Buffer 什么时候再次写入，那个结果是否要跨过这次写入继续使用。

跨过下一次写入时，明确做一次拷贝

如果下游会异步发送、写入队列或保存到缓存，消息就不再是 Buffer 的临时视图。Go 1.20 及更新版本可以直接用 bytes.Clone：

payload := bytes.Clone(buf.Bytes())
buf.Reset()
// payload 与 buf 的后续写入互不影响
sendLater(payload)

兼容更老版本时，用带容量的 append 也很直白：

payload := append([]byte(nil), buf.Bytes()...)

如果只是马上同步调用，而且调用期间不会再改 Buffer，可以直接传 buf.Bytes()，但要把这个生命周期约束写在函数注释或接口契约里。调用方一旦把它放进 goroutine，原来的“马上”就不成立了。

把 Buffer 交给 goroutine 前，先定清所有权

bytes.Buffer 不是并发安全容器。常见的危险组合是：生产者继续复用 Buffer，消费者在另一个 goroutine 里读取之前拿到的切片。即使没有明显崩溃，也可能出现长度对、内容错的半成品。

payload := bytes.Clone(buf.Bytes())
buf.Reset()

go func(data []byte) {
    _ = sendLater(data)
}(payload)

这里的边界很清楚：生产者拥有 Buffer，消费者拥有复制后的 payload。另一种做法是用 channel 传递所有权，并保证 Buffer 在消费者完成前不再复用；那需要更严格的关闭和回收约定，通常不如复制一份容易维护。

用一个小测试锁住复用边界

这类问题适合用测试明确写出“下一次写入不能影响已保存消息”的约束：

func TestBufferPayloadIsSnapshot(t *testing.T) {
    var buf bytes.Buffer
    buf.WriteString("order:1001")
    got := bytes.Clone(buf.Bytes())

    buf.Reset()
    buf.WriteString("order:1002")

    if string(got) != "order:1001" {
        t.Fatalf("payload changed: %q", got)
    }
}

如果你是在定位真实服务里的偶发错包，再加上 go test -race 检查跨 goroutine 的读写关系。竞态检测不能替代生命周期设计，但能帮助确认“Buffer 复用”和“异步消费”是否已经交叉。

相关问答

bytes.Buffer.Bytes 会返回 nil 吗？

Buffer 当前没有未读内容时通常返回长度为零的切片。业务只应依赖长度和内容契约，不要把是否为 nil 当成消息是否有效的唯一判断。

把 Bytes 转成 string 能避免复用覆盖吗？

保存成 string 后得到的是字符串值，后续 Buffer 写入不会改变它；代价是发生一次内容转换，是否采用要看数据量和接口边界。

bytes.Clone 会不会让性能变差？

它确实增加一次分配和复制，但这是跨越异步边界换来的所有权成本。先保证数据正确，再用基准测试判断是否需要对象池或批量发送。

把“临时视图”与“业务消息”分开

bytes.Buffer.Bytes() 适合在短生命周期内读取，不适合默认当作永久消息保存。只要数据要跨过下一次写入、跨函数异步传递，或者交给另一个 goroutine，就在边界处明确复制；如果选择零拷贝，就同时明确谁拥有 Buffer、何时结束使用。这个判断比给 Buffer 反复调用 Reset() 更能解决问题。