Go 的 strings.Builder 实战:拼接性能、Grow 预分配与何时该用 bytes.Buffer

Go 的 strings.Builder 实战:拼接性能、Grow 预分配与何时该用 bytes.Buffer

Go 里拼字符串,新手第一反应是+=,循环几万次后 CPU 和内存双双爆表。老手会甩一句「用 strings.Builder」,但很少讲清楚它为什么快、Grow 有什么用、什么时候反而该用 bytes.Buffer。这篇用能跑的代码说明白。

为什么 += 在循环里是灾难

Go 的 string 是不可变的。s += x每次都要新分配一块内存,把旧内容和新内容拷过去,旧的等着被 GC。循环 N 次就是 O(N²) 的拷贝量:

// 反例:每次 += 都重新分配 + 拷贝,循环越长越慢funcjoinBad(parts[]string)string{s:=""for_,p:=rangeparts{s+=p// 每轮生成一个新 string}returns}

一万个短字符串就能让它比正确写法慢几十倍,而且制造大量临时垃圾。

strings.Builder:一块可扩展的缓冲区

strings.Builder内部维护一个[]byte,WriteString直接往后追加,只在容量不够时才扩容,最后String()零拷贝地把 buffer 转成 string:

funcjoinGood(parts[]string)string{varb strings.Builderfor_,p:=rangeparts{b.WriteString(p)// 追加到内部 []byte,不重新分配整串}returnb.String()// 底层数组直接转 string,不拷贝}

String()之所以能零拷贝,是因为 Builder 用了unsafe把[]byte直接转成 string,并且禁止拷贝自身(拷贝会触发 panic,防止两个 Builder 共享同一底层数组)。所以别值传递 Builder,要传就传指针。

Grow:提前知道总长度就一次性分配

即便有 Builder,如果不预分配,它仍会在扩容时多次 realloc。当你能估算最终长度时,用Grow(n)一次性把容量备好,彻底消灭中途扩容:

funcjoinFast(parts[]string)string{total:=0for_,p:=rangeparts{total+=len(p)}varb strings.Builder b.Grow(total)// 一次分配到位,后续 Write 不再扩容for_,p:=rangeparts{b.WriteString(p)}returnb.String()}

用go test -bench实测,joinFast通常比不 Grow 的版本少一半以上的内存分配次数(allocs/op)。拼接大量数据时,Grow 是性价比最高的一行优化。

strings.Builder vs bytes.Buffer 怎么选

两者都是可扩展缓冲区,区别在用途:

• 最终要 string,而且只往里写→strings.Builder。它的String()零拷贝,更省。
• 需要读回来(实现 io.Reader)、或要反复 Reset 复用、或最终要 []byte→bytes.Buffer。Builder 没有读接口,Bytes()也没有。

// bytes.Buffer 能当 io.Reader/Writer 用,还能 Reset 复用varbuf bytes.Buffer buf.WriteString("hello")io.Copy(os.Stdout,&buf)// Builder 做不到:它不是 Reader

一句话:纯拼字符串用 Builder,要参与 IO 流或需要读取用 Buffer。注意bytes.Buffer.String()是有拷贝的,别为了「拼个字符串」平白多一次拷贝。

一个常被忽略的点:Builder 也能 fmt

不想手动拼格式化字符串时,fmt.Fprintf可以直接往 Builder 写,避免生成中间 string:

varb strings.Builderfori,p:=rangeparts{fmt.Fprintf(&b,"%d:%s;",i,p)// 直接写进 Builder,无中间字符串}

小结

• 循环里+=是 O(N²) 拷贝,数据量一大就崩;拼字符串默认上strings.Builder。
• String()零拷贝,但 Builder禁止值拷贝,传参用指针。
• 能估算长度就Grow(total)一次分配到位,实测能砍掉一半以上的allocs/op。
• 选型记忆点:只写、最终要 string 用 Builder;要读回来/复用/输出 []byte 用 bytes.Buffer。