Go strings.Builder Grow 预估容量时怎么避免过度分配

用 strings.Builder 拼接报告、日志或批量文本时，Grow 很容易被误用：开发者先算出“最终大约 4 KB”，随后直接调用 b.Grow(4096)，但此时 Builder 可能已经写入了前缀，实际预留就会偏大。更稳妥的做法是把预算统一换算成字节，再传入“还要写多少”的剩余值。

记住一个公式：Grow(n) 只保证接下来至少能写入 n 个字节；如果目标是最终容量 T，而当前已经写入 L 个字节，应传入 max(0, T-L)，而不是再次传 T。

Grow 的 n 到底代表什么

标准库文档对 Grow(n) 的承诺是“保证还有 n 个字节的空间可以写入”。因此它检查的是 Cap()-Len() 是否小于 n。若当前余量已经够用，调用不会因为“参数看起来很大”而再次分配；只有余量不够时，Builder 才会扩容。

还要注意，当前实现的扩容会把已有内容复制到新缓冲区，并按旧容量与本次需求共同计算新容量。也就是说，Grow 不是精确的 make([]byte, n) 替代品，过大的 n 会把一次本可避免的内存预留放大。

把真实片段换算成字节预算

不要用“字符个数乘一个拍脑袋系数”替代计算。Go 的字符串长度按字节计，中文、表情和其他 UTF-8 内容都可能让字符数与字节数不同。字段已知时，直接累加每个片段的 len，再加上分隔符、换行和格式化固定文本，得到更可信的总预算。

package main

import (
    "fmt"
    "strings"
)

func buildReport(rows []string) string {
    // 预算包含每行内容和换行，按字节而不是按 rune 个数计算。
    total := 0
    for _, row := range rows {
        total += len(row) + len("\n")
    }

    var b strings.Builder
    // Grow 的参数是还要写入的字节数；此时 Len 为零，所以可直接用总预算。
    b.Grow(total)
    for _, row := range rows {
        // WriteString 的返回错误恒为 nil，但保留返回值没有必要。
        _, _ = b.WriteString(row)
        _ = b.WriteByte('\n')
    }
    return b.String()
}

func main() {
    fmt.Println(buildReport([]string{"订单-001", "订单-002"}))
}

如果前面已经写入了固定头部，就要把目标总预算减去当前 Len()。例如目标是 4096 字节，头部已经写了 128 字节，应该调用 b.Grow(3968)；若头部已经超过目标，传入 0 即可。

估算不准时控制上界

真实服务里常见的是“记录数知道，单条文本长度不知道”。这时不建议把极端最大值直接乘上记录数。可以先给每条记录设置业务上合理的上限，只为常见路径预留；超出上限的输入仍让 Builder 正常扩容，并把异常长度单独记录。

另一种做法是分阶段写入：先写确定的前缀和少量元数据，等拿到列表或字段长度后，再按照剩余预算调用一次 Grow。这比在入口处为整个响应预留一个模糊的大数更节省内存，也更容易解释容量变化。

func appendRows(b *strings.Builder, rows []string, maxRowBytes int) {
    // 只按约定的单行上界估算，避免异常长文本让入口预算失控。
    estimate := len(rows) * (maxRowBytes + len("\n"))
    remaining := estimate - b.Len()
    if remaining > 0 {
        // 已写前缀不能重复计入，否则会产生不必要的容量余量。
        b.Grow(remaining)
    }
    for _, row := range rows {
        _, _ = b.WriteString(row)
        _ = b.WriteByte('\n')
    }
}

用 Len 与 Cap 做收尾检查

容量优化的目标不是让 Cap() 永远等于 Len()，而是让余量有业务解释：小批量响应可以接受少量余量，大批量响应则要避免把一次极端估算带入长期内存峰值。可以在基准或日志采样中记录 Len()、Cap() 和 Cap()-Len()，再决定上界是否需要调整。

还有两个容易忽略的边界：负数传给 Grow 会 panic；非零 Builder 不应复制后继续写入，不能把它按值放进结构体或作为值参数传递。Reset() 会清空 Builder 的状态，不能把它理解成一定保留原缓冲区的复用承诺。

常见问题

Grow(最终长度) 为什么会显得容量偏大？

因为 Builder 可能已经有已写入字节。最终目标要扣掉 Len()，Grow 参数只表示额外写入量。

中文文本应该按字符数还是字节数估算？

按字节数估算，直接使用 len(string)；字符串的字符数量不能代表 UTF-8 编码后的占用。

完全不知道输入大小，还要不要调用 Grow？

可以只为确定的前缀或常见上界预留；不要为了覆盖极端输入而一次性设置很大的容量，让自然扩容承担不确定部分。

继续核对参数语义时，可查看标准库文档：https://pkg.go.dev/strings#Builder.Grow。