Go字符串不可变，底层为只读字节数组加长度字段；修改实为指向新内存，原对象不变；拼接性能差异大，strings.Builder预分配容量最高效。
Go 字符串确实是不可变的
是的，string 在 Go 中是只读的底层字节数组（[]byte）加长度字段的结构体，一旦创建，内容无法修改。你看到的“修改”其实是让变量指向新分配的内存地址——原字符串对象没变，只是引用换了。这也是为什么 s[0] = 'x' 会编译报错，而 []byte(s)[0] = 'x' 虽能编译但改的是副本，不影响原 string。
拼接性能差距大到必须选对方法
不可变性直接导致拼接开销：每次 + 都要复制全部已有内容 + 新内容，10 万次拼接可能触发数百万次内存拷贝。基准测试中，不同方式耗时可差 100 倍以上：
-
+操作符：适合 2~3 次拼接，循环里用就是性能黑洞 -
fmt.Sprintf：带格式化语义，有反射和解析开销，纯拼接场景纯属浪费 -
strings.Builder：目前最优解，内部用[]byte缓冲，WriteString不分配、不拷贝，String()才一次性转成string -
bytes.Buffer：功能更重（支持读写、io.Writer接口），拼接场景比Builder多一点间接调用开销 -
[]byte手动拼接：可控性强，但要注意append([]byte{}, s)会隐式转换string→[]byte，若未预设容量（make([]byte, 0, totalLen)），仍可能多次扩容
strings.Builder 怎么用才真正高效
光用 strings.Builder 不够，关键在预估总长并调用 Grow。否则首次 WriteString 触发默认 64 字节分配，后续反复扩容仍产生碎片和拷贝。
builder := strings.Builder{}
builder.Grow(len(prefix) + len(items)*avgItemLen + len(suffix)) // 预分配
builder.WriteString(prefix)
for _, item := range items {
builder.WriteString(item)
}
builder.WriteString(suffix)
result := builder.String() // 此刻才生成最终 string
没预分配时，Grow 可省略；但已知总量（如日志行拼接、SQL 构造），跳过它就等于放弃一半优化收益。
别在错误场景硬套 Builder
strings.Builder 不是银弹。以下情况反而更简单或更合适：
- 拼接固定几项：
"[" + name + ":" + id + "]"直接用+，可读性高且无性能压力 - 切片拼接带分隔符：
strings.Join(strs, ",")底层已优化，比手写循环 +Builder更快更安全 - 需要中间修改或查找：
[]byte更灵活，比如边拼边替换、正则匹配后截取 - 跨 goroutine 复用 Builder：不能直接共享，需配合
sync.Pool管理生命周期，否则引发 panic 或数据污染
真正容易被忽略的点是：Builder 的零值可用，但它的底层 []byte 缓冲区不会自动清空，重复使用前必须调用 Reset()，否则内容会累积。
