Go strings.Builder 复用与清空的内存边界

strings.Builder 可以重复写入，但 Reset 不是“保留容量后清空长度”：当前 Go 标准库实现会把内部缓冲区设为 nil，因此 Len() 和 Cap() 都回到 0。若要减少一次构建过程中的扩容，用 Grow；若目标是跨轮次保留容量，不能把 Builder 的 Reset 当成容量缓存。

官方文档：https://pkg.go.dev/strings#Builder

最小写法先看清复用范围

Builder 的零值可直接使用。对一次完整的字符串构建，局部声明、按需要 Grow、写入并取出结果，是最容易推理的范围：

package main

import (
	"fmt"
	"strings"
)

func buildMessage(name string) string {
	var b strings.Builder
	// 预估本次结果长度，减少构建过程中的扩容次数
	b.Grow(len(name) + len("你好，！"))
	b.WriteString("你好，")
	b.WriteString(name)
	b.WriteString("！")
	return b.String()
}

func main() {
	// Builder 只在函数内部使用，不跨调用复制或共享
	fmt.Println(buildMessage("Gopher"))
}

Grow(n) 保证还能写入至少 n 个字节而无需再次分配；n 为负数会触发 panic。这里的 n 是字节数，不是 Unicode 字符数。无法可靠估算时可以不调用 Grow，Builder 会按需增长。

Reset 清空了什么

从 Go 标准库源码看，Builder 内部有用于检测复制的 addr 和保存数据的 buf []byte。Reset 会同时把二者设为 nil。调用后 Builder 回到可用的零值状态，但之前的容量不再挂在这个 Builder 上。

var b strings.Builder

// Grow 后 Cap 至少能容纳计划写入的数据
b.Grow(1024)
b.WriteString("payload")
before := b.Cap()

// Reset 清空内容，同时丢弃 Builder 对原缓冲区的引用
b.Reset()
afterLen := b.Len()
afterCap := b.Cap()

// before 大于 0；afterLen 与 afterCap 都为 0
fmt.Println(before, afterLen, afterCap)

这也解释了一个常见误区：Reset 只改变对象的引用关系，不承诺进程占用立即下降。旧缓冲区何时可回收由可达性和垃圾回收决定，运行时是否把内存归还给操作系统又是另一层问题。

String 返回值会改变内存边界

Builder 的设计目标之一是减少字符串构建中的复制。当前标准库的 String() 直接基于内部字节区构造结果字符串。因此，只要返回的字符串仍被变量、缓存或对象字段持有，旧缓冲区就仍可能保持可达；随后对 Builder 调用 Reset，不会让那个字符串失效，也不会让其占用的底层数据立刻消失。

var b strings.Builder
b.Grow(1 

所以排查“大字符串构建后内存为什么没有立刻下降”时，要同时检查两类引用：Builder 自身是否还指向缓冲区，以及 String() 的返回值是否仍在长生命周期容器中。只盯着 b.Cap() 会漏掉后一类。

循环里新建还是调用 Reset

如果每轮都要生成独立字符串，局部 Builder 往往更清楚。编译器和运行时会决定对象放在栈上还是堆上，不需要为了“少声明一个变量”把 Builder 放到循环外。

func buildRows(rows []string) []string {
	result := make([]string, 0, len(rows))

	for _, row := range rows {
		// 每轮使用独立 Builder，生命周期与本次结果构建一致
		var b strings.Builder
		b.Grow(len(row) + len("row="))
		b.WriteString("row=")
		b.WriteString(row)
		result = append(result, b.String())
	}

	return result
}

把 Builder 放到循环外并在每轮 Reset，在语义上也能重新写入，但不会保留上一轮容量，而且已保存的结果字符串仍各自持有相应数据。两种写法都不应被宣传成固定的“零分配技巧”；要判断性能，应该针对真实输入做基准测试并观察分配，而不是只数变量声明次数。

复制和对象池是另一条边界

官方文档明确要求：非零 Builder 不得复制。Builder 内部用地址检查防止写入中的对象被按值复制后继续修改。把它放进结构体、切片、接口或对象池时，都要避免在已写入后发生值复制。

func invalidCopy() {
	var original strings.Builder
	original.WriteString("hello")

	// 错误示例：非零 Builder 被按值复制
	copied := original

	// 继续修改复制品可能触发运行时 panic
	copied.WriteString(" world")
}

sync.Pool 也不会改变 Reset 丢弃容量的事实。把 Builder 指针放回池前调用 Reset，下一次取出时容量仍为 0；不 Reset 又会把内容和旧缓冲区带到下一位使用者，难以控制生命周期。因此，Builder 池通常不能实现“保留大缓冲区容量”的直觉目标。

怎样选择更合适

bytes.Buffer.Reset 的官方语义是清空内容但保留底层存储，和 Builder.Reset 有意不同。是否改用 bytes.Buffer 还要看你是否需要字节读写、Reader/Writer 接口，以及转换为字符串的成本，不能只因为它保留容量就机械替换。

一份简短检查清单

• 只构建一次：用局部 Builder，必要时 Grow。
• 需要清空状态：Reset 可以用，但别期待 Cap 保留。
• 内存未下降：检查 String 返回值是否仍被保存。
• 跨边界传递：传指针也要控制所有权，绝不复制非零 Builder。
• 想复用容量：先确认需求是否更符合 bytes.Buffer，再用基准测试比较真实工作负载。

常见问题

strings.Builder.Reset 后 Cap 为什么是 0？

因为当前标准库实现把内部 buf 直接设为 nil。它恢复的是零值状态，不是把长度截断为 0 后保留底层数组。

Reset 后之前的 String 还能用吗？

能。已经返回的字符串独立保持其内容；只要它仍被引用，相关数据也可能继续占用内存。

每次循环重新声明 Builder 会不会很浪费？

不能只凭声明次数判断。局部声明让生命周期清晰，具体分配由编译器、写入规模和 Grow 策略共同决定，应以基准测试为准。

可以把 strings.Builder 放进 sync.Pool 吗？

技术上可以存指针，但 Reset 会丢弃容量，不 Reset 又会保留旧内容与大缓冲区。若目的只是复用容量，通常需要重新评估数据结构，而不是默认上池。