




bytes.Buffer 拼接字符串性能远优于 + 或 fmt.Sprintf,因其避免重复内存分配;string 不可变,+= 每次都复制全部内容;Buffer 用动态切片管理,扩容少、WriteString 零分配;预估容量可减少扩容,但需谨慎;Bytes() 返回内部切片,勿长期持有。
直接用 bytes.Buffer 拼接字符串比 + 或 fmt.Sprintf 快得多,尤其在循环中拼接几十次以上时,性能差距明显——它避免了反复分配内存和拷贝底层数组。
Go 中 string 是不可变的,每次 s += "x" 都会新建一个字符串并复制全部内容。100 次拼接可能触发数十次内存分配,而 bytes.Buffer 内部用可增长的 []byte 缓冲区管理,扩容策略类似 slice(通常翻倍),实际分配次数极少。
string += 可能分配 ~1
000 次;bytes.Buffer 通常只分配 5–10 次Buffer 的 WriteString 和 Write 方法零分配(只要缓冲区够用)string,调用 buf.String();如需 []byte,用 buf.Bytes()(注意:返回的是内部切片,别长期持有或修改)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
Grow 不是 Make,它只是建议,实际扩容仍由 Buffer 内部逻辑控制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 管理实例。