Go strings.Builder Grow 预留容量后为什么仍会扩容

我第一次给 strings.Builder 加 Grow 时，把参数理解成了“最终字符串要预留多少容量”。结果是主体文本写完后，补一个分隔符和尾部信息，容量还是发生了变化。真正的规则是：Grow(n) 只保证从当前已写入位置开始，至少还能写入 n 个字节而不再分配；它不是把最终总容量锁死为 n。所以，预留后仍扩容通常不是 Builder 失效，而是预算口径算错了。

先看懂 Grow 保证的到底是哪一段容量

官方文档把 Grow(n) 定义为：必要时扩展 Builder 容量，保证还能写入另外 n 个字节。当前 Go 源码的判断也是 cap(buf)-len(buf) 时才扩容。因此排查时，最有用的不是单独打印 Cap()，而是同时打印已写入长度、总容量和剩余容量。

package main

import (
    "fmt"
    "strings"
)

func main() {
    var b strings.Builder
    b.WriteString("prefix=") // 先写入固定前缀，后续预算只针对追加部分
    b.Grow(12)                // 保证接下来至少有 12 个字节的可写空间
    fmt.Printf("len=%d cap=%d remain=%d\n", b.Len(), b.Cap(), b.Cap()-b.Len())
    b.WriteString("abcdefghijkl") // 这次追加正好消耗 12 个字节
    fmt.Printf("len=%d cap=%d remain=%d\n", b.Len(), b.Cap(), b.Cap()-b.Len())
}

这里的 Cap() 是底层字节缓冲区的总容量，已经写入的前缀也包含在里面。也就是说，写入 7 个字节后调用 Grow(12)，目标是至少还能放下 12 个字节，而不是把总容量设成 12。具体容量可能大于刚好需要的值，这是实现的扩容策略，不应把它当成固定数值契约。

为什么写完主体后仍会扩容

最常见的情况是把主体长度当成最终长度。实际构造往往还会追加逗号、换行、字段名、错误提示或尾部标记。比如预计追加 20 个字节，却先 Grow(20)，随后再写入 "\nstatus=ok"，超过预算后当然可能触发下一次分配。

另一个容易忽略的点是多字节文本。len("Go语言") 统计的是字节数，不是 4 个“字符”；如果使用 utf8.RuneCountInString 得到的数量去调用 Grow，预算就会偏小。WriteRune 也会按 UTF-8 编码写入，并返回实际写入的字节数。

按字节预算，才能让 Grow 真正发挥作用

如果最终文本由多段已知字符串组成，可以先累加它们的字节长度，再一次性预留。不要为了让 Cap() 看起来整齐而追求“刚好容量”，因为 Builder 的实现会为后续写入留出增长空间，过度精确通常没有收益。

func render(prefix, name, status string) string {
    var b strings.Builder
    extra := len(prefix) + len(name) + len(status) + len(" | status=")
    b.Grow(extra) // 按所有将要追加的字节计算，而不是按字符数量计算
    b.WriteString(prefix)
    b.WriteString(name)
    b.WriteString(" | status=") // 分隔符和字段名也属于预算
    b.WriteString(status)
    return b.String()
}

如果数据来自循环或外部输入，就很难提前知道最终大小。此时可以做一个保守估算，例如按平均条目长度乘以条目数，再留出少量尾部空间；或者干脆不调用 Grow，让 Builder 自己增长。是否优化应由基准测试和分配次数决定，而不是只看某一次 Cap() 的打印值。

生产代码里的四项检查

第一，检查 Grow 调用点前已经写入了多少内容；第二，用 len 统计字符串字节数，不把 rune 数量当容量；第三，把分隔符、换行和格式化前后缀加入预算；第四，不复制已经写入过内容的非零 Builder。标准库明确说明 Builder 的非零值不能复制，复用时使用同一个变量并在下一轮开始前调用 Reset，再根据本轮数据重新估算。

一个简单的判断式是：需要追加的总字节数 。不满足时，扩容是预期行为；满足时，按照当前实现，后续这些写入不应因为空间不足而再次分配，但仍不要依赖某个具体容量增长倍数。

相关问题

Grow(0) 会把 Builder 的容量清零吗？

不会。它只是不额外保证新增空间，已有缓冲区不会因为这个调用自动清空。需要清空内容时使用 Reset。

Grow 传入负数会怎样？

会 panic。外部输入参与计算时，先确认预算没有溢出或变成负数。

为什么我调用了 Grow，仍然看到内存分配？

Grow 只覆盖它之后的指定字节预算。若预算不足、按字符数估算，或者代码中还有其他字符串转换和对象分配，仍可能观察到分配；应结合基准测试定位。