Go strings.Builder 怎样估算容量后构造长字符串在批处理代码中减少额外分配

批处理代码把很多小片段拼成一段长文本时，关键不是盲目把 string += part 改成 strings.Builder，而是先估算最终文本大约需要多少字节，再调用 Grow 预留容量。预算足够时，写入过程就少一些扩容和搬移；预算不足时，Builder 仍会按需增长，因此估算不需要为了“绝对精确”而复制全部输入。

官方地址：https://pkg.go.dev/strings#Builder

估算单位要使用字节：固定文本长度 + 每条记录的字节数 + 分隔符字节数。先 Grow(预算)，再按相同规则写入；最后用 Len 看已写字节，用 Cap 看底层容量。

先把容量估算成字节预算

strings.Builder.Grow(n) 的含义是：如果当前剩余容量不足以再写入 n 个字节，就扩大容量；调用后至少有 n 个字节可以继续写入而不触发新的分配。这里的 n 不是字符数，也不是记录条数，而是字节数。

一个批处理结果通常可以拆成三类来源：固定前缀、记录内容和记录之间的分隔符。若每条记录写成 名称 + ": " + 值，预算可以写成：

固定前缀字节数
+ 所有名称和值的字节数
+ 每条记录内部的 ": " 字节数
+ 记录之间的换行字节数

Go 的 len(string) 返回 UTF-8 编码后的字节数，所以中文文本会自然按实际占用计入预算。不要用“字符个数乘以一个固定倍数”替代真实长度，那样要么浪费容量，要么仍然低估。

用 Grow 预留批处理空间

下面的例子把用户记录拼成一段文本。估算循环和写入循环使用同一套格式规则，避免预算与实际写入脱节。示例没有把 Grow 当作性能保证，而是把它当作减少扩容机会的明确提示。

package main

import (
	"fmt"
	"strings"
)

type Record struct {
	Name  string
	Value string
}

func buildBatch(records []Record) string {
	const prefix = "批处理结果：\n"
	const separator = "\n"

	// 先按最终写入格式估算字节预算；len 返回的是字节数。
	capacity := len(prefix)
	for i, record := range records {
		// 名称、冒号空格和值都会进入最终字符串。
		capacity += len(record.Name) + len(": ") + len(record.Value)
		if i > 0 {
			// 只有记录之间需要换行，避免多算一个尾部分隔符。
			capacity += len(separator)
		}
	}

	var builder strings.Builder
	// Grow 只接收字节预算；预算不足时 Builder 仍会继续增长。
	builder.Grow(capacity)
	builder.WriteString(prefix)

	for i, record := range records {
		if i > 0 {
			// 写入格式必须和上面的容量估算保持一致。
			builder.WriteString(separator)
		}
		builder.WriteString(record.Name)
		builder.WriteString(": ")
		builder.WriteString(record.Value)
	}

	// String 返回当前已经累积的文本，Len/Cap 可用于定位预算问题。
	fmt.Printf("len=%d cap=%d\n", builder.Len(), builder.Cap())
	return builder.String()
}

func main() {
	// 中文记录用于说明 len 按 UTF-8 字节计算，不按 rune 个数计算。
	records := []Record{
		{Name: "地区", Value: "华东"},
		{Name: "状态", Value: "已完成"},
	}
	fmt.Print(buildBatch(records))
}

运行后，len 表示已经写入的字节数，cap 表示底层字节缓冲区的容量。cap 可能大于 len，也可能大于估算值；不要把具体容量当成跨版本、跨实现都固定的数值。真正需要比较“是否减少分配”时，再针对真实批量规模编写基准测试。

处理估算不足和 UTF-8 边界

容量估算是预算，不是写入限制。记录字段可能比历史样本更长，也可能因为转义、格式化或动态后缀增加字节数。此时 Builder 会继续扩容，结果仍然正确；只是预留带来的收益会变小。

常见的错误是用 utf8.RuneCountInString 或业务上的“字符数”去调用 Grow。例如“已完成”有多个 UTF-8 字节，rune 数量并不等于最终字符串占用的字节数。只有当后续写入的内容全部是 ASCII，字符数才恰好等于字节数。

// estimateRecordBytes 只计算最终文本格式需要的字节数。
func estimateRecordBytes(record Record) int {
	// len(string) 直接返回 UTF-8 字节长度，不需要额外转换成 []byte。
	return len(record.Name) + len(": ") + len(record.Value)
}

func buildWithEstimate(records []Record, estimate int) string {
	var builder strings.Builder
	// estimate 可以是历史统计值或上游预算，不足时由 Builder 自动扩容。
	if estimate > 0 {
		builder.Grow(estimate)
	}
	for i, record := range records {
		if i > 0 {
			// 分隔符也必须计入真实写入，但不要求估算永远完美。
			builder.WriteByte('\n')
		}
		builder.WriteString(record.Name)
		builder.WriteString(": ")
		builder.WriteString(record.Value)
	}
	return builder.String()
}

如果估算值来自不可靠的外部输入，还要先处理负数。Grow 传入负数会 panic，因此可以像示例一样只在正数时调用，或者在计算预算时使用明确的上限和溢出策略。文章里的重点是把“预算不准”与“结果错误”分开：前者通常影响扩容次数，后者才是格式计算错误。

用 Len、Cap 和 String 看清结果对象

三者关注点不同。Len 是已经累积的字节数，等价于当前结果的 len；Cap 是底层字节切片的容量，包含已经写入的部分；String 返回当前累积的字符串。调试容量预算时，先看 Len 和 Cap 的关系，不要从 Cap 反推字符串内容。

官方文档明确提醒：零值 Builder 可以直接使用，但不要复制一个已经写入过内容的非零 Builder。把它放进结构体后按值传递、从函数返回后再复制，都会让生命周期变得危险；更稳妥的做法是传递 *strings.Builder，或者让构造函数在内部独占一个 Builder。

批次复用时先 Reset，别把 Builder 当并发容器

同一个 goroutine 连续处理多个批次时，可以用 Reset 清空当前内容后继续写入。复用的是 Builder 的使用边界，不是把一个 Builder 同时交给多个 worker。strings.Builder 没有把一个实例安全共享给多个 goroutine 的承诺，批处理并发时应当每个任务拥有自己的 Builder，或在任务边界创建和销毁。

func buildManyBatches(b *strings.Builder, batches [][]Record) []string {
	results := make([]string, 0, len(batches))
	for _, records := range batches {
		// 每批开始前清空上一次内容，再按当前批次重新估算。
		b.Reset()
		capacity := 0
		for i, record := range records {
			if i > 0 {
				capacity++ // 换行是一个字节。
			}
			capacity += estimateRecordBytes(record)
		}
		// 预留当前批次的预算，避免沿用不匹配的旧长度判断。
		b.Grow(capacity)
		for i, record := range records {
			if i > 0 {
				b.WriteByte('\n')
			}
			b.WriteString(record.Name)
			b.WriteString(": ")
			b.WriteString(record.Value)
		}
		// 在下一次 Reset 前把当前批次结果交给下游使用。
		results = append(results, b.String())
	}
	return results
}

这个示例的重点是生命周期顺序：当前批次完成后先取得字符串结果，再进入下一轮 Reset。如果结果会被异步消费者长期保存，应把所有权和消费时机设计清楚；不要让调用方误以为后续批次会修改已经返回的业务结果。

落地前的检查清单

1. 把固定文本、字段内容和分隔符都按字节计入预算，中文不要按字符数估算。
2. 让容量估算格式与实际写入格式保持一致，新增后缀或转义规则时同步修改两处。
3. 把 Grow 看成减少扩容机会的预算提示，不把某个具体 Cap 或分配次数写死。
4. 用 Len 观察已写入字节，用 Cap 观察容量，不用容量推断文本内容。
5. 同一实例只在明确的生命周期内使用；批次复用先 Reset，并发任务不要共享非零 Builder。

如果输入规模很小、拼接次数很少，直接使用清晰的字符串表达式可能更合适；当代码确实在循环中构造长文本，并且能够合理估算最终字节数时，strings.Builder.Grow 才值得加入。最终的性能结论应由贴近生产输入的基准测试决定。

相关问题

Grow 的参数应该填字符数还是字节数？

填字节数。len(string) 返回 UTF-8 字节长度，Grow 也按字节保证后续写入空间。

容量估算少了，Builder 会不会截断字符串？

不会。容量不足时 Builder 会继续增长，结果仍按写入内容构造；只是预留容量减少扩容的效果会变弱。

Grow 越大越好吗？

不是。过大的预算会提前占用更多内存，尤其不适合批量大小变化很大的请求。应使用可解释的上限或历史分布，并用真实输入做基准。

Builder 可以放进 sync.Pool 吗？

可以把它作为复用策略的一部分，但必须在归还前 Reset，并明确所有权与并发边界；不要复制非零 Builder，也不要让多个 goroutine 同时操作同一个实例。