Go bytes.Buffer 怎样复用缓冲区并避免旧内容残留完成一个可复用的最小示例

我在把多条短文本拼成批量摘要时，遇到过一个很隐蔽的问题：同一个 bytes.Buffer 被重复使用，第二轮输出却带上了第一轮的尾巴。原因通常不是 WriteString 失效，而是复用前没有清空当前内容。正确做法是每轮写入前调用 Reset()：它会把当前未读长度清零，同时保留底层存储供下一轮使用。

官方文档：https://pkg.go.dev/bytes

把 Buffer 当作一个有生命周期的可复用容器：先 Reset，再写入；用 Len 看当前内容，用 Cap 看底层容量；不要把 Bytes 返回的切片跨越下一次修改继续使用。

先识别旧内容残留的原因

bytes.Buffer 的零值可以直接写入。如果第二次构建时继续调用 WriteString，它会在现有内容后面追加，而不是自动替换。这个差异在循环或批量任务里很容易被忽略。

下面先看一个最小的错误方向。第一轮写入后，第二轮如果不调用 Reset，结果自然会变成两轮文本的拼接：

var buf bytes.Buffer

// 第一轮写入摘要内容。
buf.WriteString("订单 A\n")

// 如果这里直接继续写，第二轮会接在“订单 A”后面。
buf.WriteString("订单 B\n")
fmt.Print(buf.String())

这里的关键是区分“底层存储还在”和“当前内容还在”。复用容量并不等于复用旧文本；想让下一轮从空内容开始，就必须显式调用 Reset。

把 Reset 放进可复用函数

为了让调用方不必每次记住清理顺序，可以把 Reset 放进负责构建摘要的函数开头。这个小项目用一个 Buffer 连续构建两个批次，函数返回字符串后，下一次调用仍然使用同一个 Buffer。

package main

import (
	"bytes"
	"fmt"
)

// buildSummary 复用传入的 Buffer，返回本轮独立的摘要字符串。
func buildSummary(buf *bytes.Buffer, batch string, items []string) string {
	// 清空当前未读内容，但保留底层存储给下一轮写入。
	buf.Reset()
	buf.WriteString(batch)
	buf.WriteString("\n")

	for _, item := range items {
		// 每条记录单独换行，避免批次之间的内容粘连。
		buf.WriteString("- ")
		buf.WriteString(item)
		buf.WriteByte('\n')
	}

	// String 返回本轮摘要；下一次修改 Buffer 前不要把 Bytes 切片留作长期引用。
	return buf.String()
}

func main() {
	var buf bytes.Buffer

	first := buildSummary(&buf, "上午批次", []string{"订单 A", "订单 B"})
	second := buildSummary(&buf, "下午批次", []string{"订单 C"})

	fmt.Print(first)
	fmt.Print(second)
	fmt.Printf("当前长度=%d，底层容量=%d\n", buf.Len(), buf.Cap())
}

这个函数的可复用点有两个：Buffer 由调用方持有，避免每次都创建新对象；Reset 由构建函数负责，调用方只需要传入本轮数据。函数返回后，first 和 second 是本轮要输出的字符串，Buffer 本身则继续作为下一轮工作区。

用 Len 和 Cap 观察 Buffer 的生命周期

Len() 表示当前未读内容的长度，Cap() 表示底层字节切片的容量。调用 Reset() 后，Len 会回到 0，而 Cap 通常仍然保留，所以后续写入有机会复用已有空间。

var buf bytes.Buffer

// 写入一轮内容，观察当前长度和容量。
buf.WriteString("一段可以被复用的文本")
fmt.Printf("写入后：Len=%d Cap=%d\n", buf.Len(), buf.Cap())

// Reset 只清空当前内容，不把底层存储当场变成零容量。
buf.Reset()
fmt.Printf("Reset 后：Len=%d Cap=%d\n", buf.Len(), buf.Cap())

// 新一轮写入从空内容开始，不会带上上一轮的尾巴。
buf.WriteString("新的文本")
fmt.Println(buf.String())

不要把“Cap 可能保留”理解成永久承诺：Buffer 仍可能因为后续增长、重新赋值或生命周期结束而使用不同的存储。这里要利用的是 API 明确给出的复用语义，而不是把底层地址当成业务契约。

处理 Bytes 切片和并发边界

Bytes() 返回的是当前未读部分的切片，而且可能与 Buffer 的底层存储别名。官方文档明确提醒，这个切片只在下一次 Buffer 修改前有效。因此，不要在调用 Write、Reset 或读取方法后继续假定旧切片内容和生命周期不变；需要长期保存时，先复制一份。

func snapshot(buf *bytes.Buffer) []byte {
	// copy 创建独立副本，避免后续 Reset 或写入影响快照。
	return bytes.Clone(buf.Bytes())
}

func useBuffer(buf *bytes.Buffer) []byte {
	// 先生成快照，再允许调用方继续复用 Buffer。
	return snapshot(buf)
}

并发方面，单个 Buffer 不应被多个 goroutine 直接同时写入。更简单的做法是让每个 worker 拥有自己的 Buffer；如果确实要共享，就在更高层用互斥锁保护完整的 Reset、写入和读取区间，而不是只锁住其中一个方法。

这个小项目适合什么场景

我的经验是，复用 Buffer 最有价值的地方不是“保证每次都更快”，而是把“本轮内容”和“可复用工作区”分开管理。若要证明分配次数确实下降，应在自己的输入规模和并发模型下补充基准测试，不要只凭 Cap() 看起来没有变化就下结论。

相关问题

Reset 会释放 bytes.Buffer 的底层内存吗？

Reset 会把 Buffer 清空并保留底层存储供后续写入；它不是把 Buffer 重新替换成一个全新的零值对象。是否继续复用这块容量，仍取决于后续写入和对象生命周期。

为什么调用 Reset 后旧的 Bytes 切片不能继续使用？

Bytes 返回的切片可能与 Buffer 的底层内容别名，而 Reset 属于 Buffer 修改。需要跨修改保存时，用 bytes.Clone 或 append([]byte(nil), buf.Bytes()...) 建立独立副本。

可以把同一个 Buffer 放进多个 goroutine 吗？

不建议直接并发读写同一个 Buffer。让每个任务使用独立 Buffer 通常更清晰；若必须共享，应保护完整的操作区间，并明确返回字符串或字节快照的生命周期。