strings.Builder 比 += 快，因其用切片缓存字节、仅需必要扩容，避免重复分配；拼接≥3次或长度不定时应优先使用，但单次常量拼接无需Builder。
strings.Builder 为什么比 += 快
因为 += 每次都新建字符串、复制旧内容，底层触发多次内存分配和拷贝；strings.Builder 内部用切片缓存字节，只在容量不足时扩容，避免重复分配。
实操建议：
- 只要拼接次数 ≥ 3 次、或拼接内容长度不确定（比如循环中累积日志），就该用
strings.Builder - 别在单次固定拼接（如
"hello" + name + "!"）里硬套strings.Builder，编译器对常量拼接做了优化，反而多一层对象开销 - 注意：
strings.Builder不是线程安全的，多 goroutine 并发写必须加锁或每个 goroutine 独立实例
Builder.Reset() 和重新声明哪个更省？
复用 strings.Builder 实例时，Reset() 比 var b strings.Builder 重新声明更快——它不清空底层数组，只是重置长度为 0，保留已有容量。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 用完不
Reset()就直接String()后再次WriteString()：没问题，但下次拼接可能意外复用上一轮残留容量（极少影响逻辑，但内存没及时释放） - 误以为
Reset()会释放内存：不会，它只设b.len = 0，底层数组仍持有原空间 - 在循环中反复
var b strings.Builder：每次都会初始化一个新结构体，虽然轻量，但 GC 压力略高，且无法复用已分配的缓冲区
Builder.WriteString() vs Builder.Write() 的参数陷阱
WriteString() 接收 string，Write() 接收 []byte。传错类型会编译报错，但容易忽略隐式转换开销。
使用场景与差异：
- 拼接纯字符串变量（
name,path）：优先用WriteString(name)，零分配、无转换 - 拼接
[]byte数据（比如从io.Read()得到的缓冲区）：用Write(data)，避免转成string触发额外内存分配 - 想拼接 rune 或格式化内容？别硬转：先用
fmt.Appendf(b.Grow(16), "%d", n)或直接strconv.AppendInt()写入底层数组，再调b.Len()控制位置——Builder本身不提供格式化方法
Builder.String() 后还能继续用吗？
能，但有隐藏成本：String() 返回的是底层数组的只读副本（通过 unsafe.String() 构造），不阻断后续写入；但一旦调了 String()，后续任何写操作都会触发一次底层数组复制（防止返回的字符串被意外修改）。
性能影响明显：
- 如果之后还要拼很多内容，先
Reset()再写，比调完String()立刻接着WriteString()快得多 - 调试时习惯性在中间打
log.Println(b.String())？小心——这会让后面所有写入变慢，换成log.Printf("builder len=%d, cap=%d", b.Len(), cap(b.Bytes()))更轻量 - 需要同时保留字符串和继续拼接？要么拆成两个
Builder，要么用b.String()后立刻Reset()，别拖着用
最常被忽略的一点：这个“写时复制”行为没有文档显式警告，只藏在源码注释里，很多人直到压测时看到 CPU 突增才去翻 strings/builder.go。
