在Golang的开发场景中，字符串拼接是非常高频的操作，不管是日志拼接、接口响应构建还是数据格式化，都会涉及多个字符串的组合。传统的拼接方式在处理少量拼接时表现尚可，但在高频、大批量拼接的场景下，会带来大量的内存分配和拷贝开销，影响程序的运行效率。strings.Builder作为Golang标准库提供的字符串构建工具，就是专门为解决这类问题设计的，它能够有效提升字符串拼接的性能，降低内存占用。
传统字符串拼接方式的不足
Golang中常见的传统字符串拼接方式主要有两种，分别是使用+运算符和fmt.Sprintf，这两种方式都存在一定的局限性。
使用+运算符拼接的问题
Golang中的字符串是不可变的，每次使用+拼接两个字符串时，都会创建一个新的字符串对象，将原有字符串的内容拷贝到新对象中。如果拼接次数很多，就会产生大量的临时字符串对象，不仅增加内存分配的次数，还会带来额外的拷贝开销。
比如下面这段代码，循环拼接10000次字符串：
package main
import "fmt"
func concatWithPlus() string {
var s string
for i := 0; i < 10000; i++ {
s += fmt.Sprintf("num_%d", i)
}
return s
}
这段代码每次循环都会创建一个新的字符串，性能会随着拼接次数增加而急剧下降。
fmt.Sprintf的性能问题
fmt.Sprintf虽然使用灵活，支持多种类型的格式化拼接，但内部会进行反射、格式化解析等操作，性能比+运算符还要差，不适合高频拼接场景。
strings.Builder的核心优势
strings.Builder的核心设计思路是预分配内存和可变的内部缓冲区，避免了频繁的字符串创建和拷贝，主要有以下几个优势：
- 减少内存分配：可以通过
Grow方法预分配足够的缓冲区空间，避免拼接过程中多次扩容带来的内存分配开销。 - 避免不必要的拷贝：内部维护一个
[]byte类型的缓冲区，拼接时直接将内容写入缓冲区，只有在调用String()方法时才会将缓冲区内容转换为字符串，减少了中间过程的拷贝。 - 性能优异：在高频拼接场景下，性能比传统方式高出数倍甚至数十倍。
strings.Builder的使用方法
strings.Builder的使用非常简单，核心方法包括WriteString、Write、Grow、String等，下面是一个基本的使用示例：
package main
import (
"fmt"
"strings"
)
func concatWithBuilder() string {
// 创建strings.Builder实例
var builder strings.Builder
// 预分配缓冲区大小，避免多次扩容，这里根据预估拼接后的字符串长度设置
builder.Grow(50000)
for i := 0; i < 10000; i++ {
// 写入字符串内容
builder.WriteString(fmt.Sprintf("num_%d", i))
}
// 转换为最终字符串
return builder.String()
}
上面的代码中，首先创建了strings.Builder实例，然后调用Grow方法预分配了50000字节的缓冲区，之后循环调用WriteString写入内容，最后调用String()得到最终的拼接结果。预分配缓冲区的大小可以根据实际拼接后的字符串长度预估，这样能最大程度减少扩容带来的开销。
性能对比测试
我们可以通过Golang的基准测试来对比三种拼接方式的性能差异，测试代码如下：
package main
import (
"fmt"
"strings"
"testing"
)
// 测试+运算符拼接
func BenchmarkConcatWithPlus(b *testing.B) {
for i := 0; i < b.N; i++ {
concatWithPlus()
}
}
// 测试fmt.Sprintf拼接
func BenchmarkConcatWithSprintf(b *testing.B) {
for i := 0; i < b.N; i++ {
concatWithSprintf()
}
}
// 测试strings.Builder拼接
func BenchmarkConcatWithBuilder(b *testing.B) {
for i := 0; i < b.N; i++ {
concatWithBuilder()
}
}
func concatWithSprintf() string {
var s string
for i := 0; i < 10000; i++ {
s = fmt.Sprintf("%snum_%d", s, i)
}
return s
}
运行基准测试后，通常能得到类似如下的结果：
| 拼接方式 | 每次操作耗时 | 内存分配次数 | 每次操作内存分配大小 |
|---|---|---|---|
| +运算符 | 约1200ms | 10000次 | 约50000字节 |
| fmt.Sprintf | 约2500ms | 20000次 | 约80000字节 |
| strings.Builder | 约20ms | 1次 | 约50000字节 |
从测试结果可以明显看出，strings.Builder的性能远高于传统拼接方式，内存分配次数也大幅减少。
使用strings.Builder的注意事项
虽然strings.Builder很好用，但使用时也有一些需要注意的点，避免出现错误：
- 不支持并发写入：strings.Builder的内部缓冲区不是并发安全的，不能在多个goroutine中同时调用它的写入方法，如果需要并发拼接，需要自己加锁或者使用其他并发安全的方案。
- 不能拷贝已使用的实例：如果strings.Builder已经调用过写入方法，再拷贝它的实例会导致panic，因为内部会记录是否已经被使用，拷贝后会触发检测错误。
- Grow方法不是必须的：如果不调用
Grow方法，strings.Builder会自动扩容，只是频繁扩容会带来额外开销，所以建议在能预估最终字符串长度的情况下提前调用Grow。 - String()方法调用后不影响原实例：调用
String()方法后，原strings.Builder实例还可以继续使用，继续写入内容后再次调用String()会得到更新后的字符串。
适用场景总结
strings.Builder适合所有需要拼接多个字符串的场景，尤其是以下情况更应该优先使用：
- 需要拼接的字符串数量较多，比如循环拼接数百、数千甚至更多次。
- 拼接的字符串总长度较大，比如拼接后的字符串长度超过1KB。
- 对性能和内存占用有较高要求的场景，比如高频调用的接口、处理逻辑复杂的服务。
如果是少量字符串拼接，比如只有两三个字符串需要组合，使用+运算符也是可以的，因为这种情况下性能差异可以忽略，代码的可读性反而更高。
Golangstrings.Builder字符串拼接性能优化内存利用修改时间：2026-06-27 16:39:32