Go bytes.Buffer 复用时怎么避免旧数据残留

如果同一个 bytes.Buffer 在循环里连续生成多条消息，第二条结果突然带上第一条的尾巴，先别急着怀疑 Go 的内存回收。最常见的原因是 Write 和 WriteString 都采用追加语义，而复用前没有把逻辑长度清零。正确的起点是：每轮写入前调用 Reset()；需要预留空间时再调用 Grow()；如果把 Bytes() 返回值交给外部长期保存，还要复制一份。

先分清 Len、Cap 和旧数据的来源

bytes.Buffer 的零值就是可用的空缓冲区。写入后，Len() 表示当前可读内容的长度，Cap() 表示底层字节切片已经分配的总容量。复用时真正决定“下一次会不会带上旧数据”的是 Len()，不是 Cap()。

例如第一轮写入 "trace=old"，第二轮直接写入 "trace=new"，结果会是两段内容相连，因为第二次写入本来就是 append。容量只是可继续使用的空间，不等于已经写入的有效字符。排查时可以临时记录 Len()、Cap() 和请求 ID，先确认是哪一条路径漏掉了清空。

Reset 放在复用入口，Grow 放在容量决策处

Reset() 会把 Buffer 变为空，但保留底层存储，官方文档也明确它等价于 Truncate(0)。因此一个普通的复用函数可以把清空动作放在最前面，让后续所有分支都共享同一个不变量：

package main

import "bytes"

// buildLine 复用调用方传入的 Buffer，每次从空的逻辑长度开始。
func buildLine(buf *bytes.Buffer, requestID, message string) string {
	buf.Reset() // 清空旧内容，但保留适合复用的底层存储
	buf.Grow(len(requestID) + len(message) + 8) // 只预留本轮可能写入的空间
	buf.WriteString("id=")
	buf.WriteString(requestID)
	buf.WriteString(" msg=")
	buf.WriteString(message)
	return buf.String()
}

Grow 应该放在 Reset 之后。它保证后续至少能再容纳指定数量的字节，但不会覆盖已有内容；若把它放在清空之前，容量规划正确了，输出仍可能从旧内容后面继续追加。

用容量阈值处理池化对象和大请求

在请求循环或 sync.Pool 中，Reset 很适合处理大小相近的消息。但某次异常大请求可能把底层容量撑得很大，之后每个小请求都长时间携带这块内存。这里不要把“清空内容”和“释放容量”混为一谈：前者是正确性要求，后者是资源策略。

阈值应结合业务消息大小、并发量和内存曲线设定，不要把某个固定数字当成通用答案。对于池化对象，归还前至少执行 Reset；如果对象需要跨 goroutine 传递，先完成数据复制再归还。

Bytes 返回值要复制，并限制 Buffer 的所有权

Bytes() 给出当前未读内容的切片视图，不会自动创建副本。下面的写法容易埋下串改问题：先保存 buf.Bytes()，随后又 Reset 并写入下一条消息，之前保存的切片可能观察到同一块底层存储的变化。

package main

import "bytes"

// snapshot 返回独立副本，调用方可以在 Buffer 复用后继续持有它。
func snapshot(buf *bytes.Buffer) []byte {
	out := make([]byte, buf.Len()) // 分配与当前有效内容相同的长度
	copy(out, buf.Bytes()) // 复制，切断与 Buffer 底层数组的别名关系
	return out
}

如果只在当前函数内立即读取，别名切片通常足够；只要要写入 channel、缓存、响应队列或另一个 goroutine，就把“谁拥有这段字节”写进接口约定。bytes.Buffer 本身也不应被多个 goroutine 同时读写，外层需要用明确的串行边界或锁保护。

常见问题

Reset 会把 Cap 也清零吗？

不会。它清空逻辑内容并保留底层存储，后续写入仍可能复用原容量。

Grow 能替代 Reset 吗？

不能。Grow 只保证额外写入空间，旧内容仍然存在；复用前先 Reset。

直接重新声明 Buffer 是否更安全？

对一次性小数据，重新声明简单直接；对稳定的高频大小，Reset 复用更合适，前提是所有权和容量策略清楚。

把复用规则固定成“入口 Reset、按需 Grow、跨边界复制、异常容量隔离”，基本就能同时解决旧数据残留和缓存对象越用越大的问题。