bytes.Buffer 拼接字符串性能远优于 + 或 fmt.Sprintf，因其避免重复内存分配；string 不可变，+= 每次都复制全部内容；Buffer 用动态切片管理，扩容少、WriteString 零分配；预估容量可减少扩容，但需谨慎；Bytes() 返回内部切片，勿长期持有。
直接用 bytes.Buffer 拼接字符串比 + 或 fmt.Sprintf 快得多，尤其在循环中拼接几十次以上时，性能差距明显——它避免了反复分配内存和拷贝底层数组。
为什么不用 string += ？
Go 中 string 是不可变的，每次 s += "x" 都会新建一个字符串并复制全部内容。100 次拼接可能触发数十次内存分配，而 bytes.Buffer 内部用可增长的 []byte 缓冲区管理，扩容策略类似 slice（通常翻倍），实际分配次数极少。
- 1000 次拼接，
string +=可能分配 ~1000 次；bytes.Buffer通常只分配 5–10 次 -
Buffer的WriteString和Write方法零分配（只要缓冲区够用） - 如果最终需要
string，调用buf.String()；如需[]byte，用buf.Bytes()（注意：返回的是内部切片，别长期持有或修改）
基础写法：WriteString 与 Write 区别
WriteString 接收 string，Write 接收 []byte。二者底层都调用同一段追加逻辑，但传 string 时会隐式转成 []byte（不额外分配，Go 运行时做了优化）。日常用 WriteString 更自然；若已有字节切片（比如从 io.Read 得到），直接 Write 省去转换。
var buf bytes.Buffer
buf.WriteString("hello")
buf.WriteString(" ")
buf.WriteString("world")
s := buf.String() // "hello world"- 不要用
fmt.Fprintf(&buf, "...")做简单拼接——格式化有开销，且会多一次参数反射/解析 - 避免在循环里反复调用
buf.String()，它每次都会新建字符串（即使内容未变） - 如果拼接内容含大量数字，用
strconv.AppendXXX直接写入buf.Bytes()底层切片，比WriteString(strconv.Itoa(x))更省
预估容量能省一次扩容
如果知道最终字符串大概长度（比如拼 100 个平均 20 字符的 ID，加逗号分隔），初始化 Buffer 时传入容量，能避免初始小缓冲区的多次翻倍扩容：
立即学习“go语言免费学习笔记（深入）”；
var buf bytes.Buffer
buf.Grow(100 * 21) // 预留空间，避免中途扩容
for _, id := range ids {
if buf.Len() > 0 {
buf.WriteByte(',')
}
buf.WriteString(id)
}-
Grow(n)确保后续至少n字节无需再分配；但它不改变当前Len()，只是扩容底层buf - 过度预估（比如给 1MB）浪费内存；完全不预估（默认 0）在小数据下也没问题，但大数据量时值得算一算
- 注意：
Grow不是Make，它只是建议，实际扩容仍由 Buffer 内部逻辑控制
别误用 buf.Bytes() 返回值
buf.Bytes() 返回的是内部底层数组的切片，**不是拷贝**。如果之后继续 Write，这个切片可能被覆盖或重分配，导致数据错乱或 panic（如果原底层数组被回收）：
var buf bytes.Buffer
buf.WriteString("hello")
b := buf.Bytes() // b 指向内部内存
buf.WriteString(" world") // 可能触发扩容，b 失效！
fmt.Println(string(b)) // 可能打印 "hello"，也可能打印乱码或崩溃- 安全做法：需要稳定字节切片时，用
append([]byte(nil), buf.Bytes()...)拷贝一份 - 或者直接用
buf.String()（它内部已做拷贝） - 如果确定后续不再写入，且只读一次，
Bytes()可以省拷贝，但必须严格控制生命周期
真正要注意的不是“怎么写”，而是“什么时候不该用”：比如只拼 2–3 次字符串，+ 更简洁；需要频繁重置拼接内容时，buf.Reset() 比重建 Buffer 对象更轻量；而一旦涉及并发写入，bytes.Buffer 本身不安全，得加锁或换用 sync.Pool 管理实例。
