Go字符串拼接应优先用strings.Builder，其复用底层数组、零拷贝转字符串、API清晰；次选bytes.Buffer，适合io.Writer场景；须避免+=、fmt.Sprintf循环及误用string()转换。
Go语言中字符串拼接若处理不当，容易引发频繁内存分配和拷贝，显著拖慢性能。最直接有效的优化方式是避免用+或
fmt.Sprintfstrings.Builder（推荐）或bytes.Buffer。
优先使用 strings.Builder
strings.Builder专为高效构建字符串设计，底层复用[]byte切片，零拷贝转字符串，且不支持并发写入（无锁，更轻量）。它比bytes.Buffer少一次类型转换开销，API也更语义清晰。
- 初始化时可预估容量：
var b strings.Builder; b.Grow(1024)，避免多次扩容 - 用
b.WriteString(s)追加字符串，比b.Write([]byte(s))更简洁安全 - 最终调用
b.String()获取结果——该操作不额外分配内存，直接共享底层数组 - 注意：Builder不可复用（重置需
b.Reset()），但复用本身是安全的
bytes.Buffer 仍适用特定场景
当逻辑已重度依赖io.Writer接口（如写入网络、文件、加密器等），或需要同时写入字节和字符串时，bytes.Buffer更自然。它本质是带扩容策略的[]byte封装，兼容性更强。
- 同样建议预分配：
var buf bytes.Buffer; buf.Grow(2048) - 支持
WriteString、Write、WriteRune等多种写法 - 获取结果用
buf.String()（触发一次拷贝）或buf.Bytes()（零拷贝，但返回的是可变切片，注意别意外修改） - 如果后续还要把内容传给
io.Writer，直接用buf.Bytes()能省掉转字符串这步
哪些情况要特别避开
以下写法在循环或高频路径中会严重劣化性能：
- 用
+=拼接字符串（每次生成新字符串，旧的被GC） - 在循环里反复调用
fmt.Sprintf（内部用bytes.Buffer但未预分配，且有格式解析开销） - 用
strings.Join拼接少量字符串（它适合切片聚合，但单次拼接不如Builder直接） - 误以为
string([]byte{...})很便宜——小量没问题，大量时构造切片+转换仍有开销
一个对比示例
拼接1000个短字符串：
- 用
+=：约 3000+ 次内存分配，耗时可能超 1ms - 用
strings.Builder（预分配）：1–2 次分配，耗时通常 - 用
bytes.Buffer（预分配）：性能接近Builder，略高几纳秒（因多一层接口调用）
基本上就这些。日常开发中，只要拼接不是一次性的、或字符串数量不确定，就默认选strings.Builder，简单、快、意图明确。
