strings.builder 不调 grow() 比 bytes.buffer 默认容量更易性能受损：前者初始 cap 为 0，首次写即分配；后者默认 cap 64，延缓扩容但未根治问题，两者超限时均频繁扩容，而 builder 未预估长度会导致多次底层数组复制，抵消零拷贝优势。
strings.Builder 不调 Grow() 和 bytes.Buffer 默认容量谁更吃亏
不预估长度就直接用 strings.Builder{}，比 bytes.Buffer{} 更容易掉进性能坑里。前者初始 cap 是 0，第一次 WriteString() 就触发分配并设为 8；后者默认 cap 是 64，至少撑住几十个短字符串。
但别因此觉得 bytes.Buffer 更“友好”——它只是把问题延后了。一旦拼接总量远超 64 字节（比如日志行拼接、模板渲染），两者都会频繁扩容，而 strings.Builder 因没调 Grow() 导致的多次底层数组复制，会抵消掉它本应具备的零拷贝优势。
-
strings.Builder必须在写入前调Grow(n)，n是你预估的总字节数（宁可略高，比如乘以 1.5） -
bytes.Buffer虽有默认容量，但若你知道最终长度，同样该调Grow(n)或用bytes.NewBuffer(make([]byte, 0, n)) - 实测：拼 100 个平均 50 字节的字符串，
strings.Builder不调Grow()的分配次数是调了的 3 倍以上
String() 调用时是否拷贝内存，这才是关键分水岭
strings.Builder.String() 是零拷贝：它用 unsafe.String() 直接把 buf 底层数组头映射成字符串，不复制任何字节；bytes.Buffer.String() 每次都调 bytes.toString()，强制遍历整个 buf 做 UTF-8 合法性检查——哪怕你只拼了 "key=val" 这种纯 ASCII，这步也绕不开。
这个差异在高频小拼接中特别明显。比如每秒生成上千条日志，bytes.Buffer.String() 很可能成为 CPU 热点，pprof 里看到大量 utf8.fullRune 或 runtime.checkptr 就是信号。
- 如果你 100% 确保内容是合法 UTF-8（绝大多数文本场景），
strings.Builder的零拷贝就是实打实的优势 - 如果你拼的内容可能含二进制数据（比如 raw header、加密片段），
strings.Builder.WriteString()编译期就会报错：cannot convert []byte to string，此时必须用bytes.Buffer - 别为了省一次
.String()就把bytes.Buffer当strings.Builder用——接口调用 + UTF-8 检查 +off字段三重开销白扔
Builder.Reset() 和 Buffer.Reset() 行为完全不同
strings.Builder.Reset() 只是把 len(b.buf) 置 0，底层数组完全复用；bytes.Buffer.Reset() 同样不释放底层数组，但它还顺带把 off 字段清零——这个字段对纯拼接毫无意义，却始终占内存、参与每次 WriteString() 的接口调用路径。
常见误用是拼完一次就 builder = strings.Builder{}，以为这是“清空”，其实浪费了已分配的底层数组；更糟的是在循环里反复声明新 bytes.Buffer，等于每次都在堆上新建结构体+切片头。
- 高频复用场景（如 HTTP handler 内拼接响应体），用
Reset()复用单个实例，别用字面量初始化 -
strings.Builder没有Bytes()方法，也不支持读取中间状态——这不是缺陷，是设计约束，防止你写出b.String() + "suffix"后又继续WriteString()这种触发全量拷贝的代码 -
bytes.Buffer支持Bytes()和Read()，但代价是多一个字段、多一次虚表跳转、多一次 UTF-8 检查
什么时候必须用 bytes.Buffer，而不是“能用 Builder 就不用”
不是看“能不能拼”，而是看后续要对接什么接口。只要目标函数签名里明确要求 io.Writer 或 io.Reader，你就没得选——strings.Builder 不实现这两个接口，编译直接报错。
典型强依赖场景包括：json.NewEncoder(w).Encode(v)、template.Execute(w, data)、http.ServeContent(w, ...)、gzip.NewWriter(w)。这些函数只认 io.Writer，而 bytes.Buffer 实现了它；strings.Builder 没实现，连编译都过不去。
- 如果只是拼完再传给
io.WriteString(w, s)，那优先用strings.Builder拼，再转成字符串传过去——避免bytes.Buffer的额外开销 - 如果拼完立刻要
json.Unmarshal(buf.Bytes())，说明原始数据可能非 UTF-8，strings.Builder根本不能用 - 边写边读（比如拼一段 JSON 后立刻解析），
bytes.Buffer的Bytes()+Read()是唯一可行路径
Grow() 的语义：它不是“设容量为 n”，而是“确保还能写入至少 n 字节”。很多人传了个估算值，却忘了自己已经写过一部分，导致后续仍扩容。真要压榨性能，就得把预估逻辑和写入逻辑耦合起来——比如先算好所有字段长度总和，再调 Grow()，最后才开始 WriteString()。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
