循环拼接必须用 strings.Builder，静态少量拼接用 + 最快，已有切片用 strings.Join；选错场景再快工具也变慢。
循环拼接必须用 strings.Builder，静态少量拼接直接用 + 最快，已有切片就用 strings.Join ——选错场景，再快的工具也变慢。
循环中拼接字符串必须用 strings.Builder
Go 字符串不可变，s += "x" 每次都新建底层数组、全量拷贝旧内容。1000 次拼接实际拷贝字节数是 O(n²) 级，压测显示比预分配的 strings.Builder 慢 3–5 倍，GC 分配次数多一个数量级。
-
strings.Builder底层复用[]byte，String()是零拷贝转换（Go 1.10+） - 务必调用
b.Grow(estimatedTotalLen)：宁可略高估，避免底层数组反复扩容 - 写入统一用
b.WriteString(s)，别用b.Write([]byte(s))（多一次类型转换） -
b.String()只调一次：它返回副本，循环中每轮都调等于白建Builder - 别在循环里反复
b.Reset()后重用：它不清底层数组，后续写入仍可能触发扩容
已有 []string 切片时优先用 strings.Join
strings.Join 是已知全部片段时的最优解：一次性算总长、一次分配、一次拷贝，没有初始化开销，比 strings.Builder 还快一点。
- 适用场景：
strings.Join([]string{"api", "v1", "users"}, "/")、配置项转逗号串、HTTP Header 合并 -
sep参数必须是string，传rune或byte会编译失败 - 空切片 + 非空
sep返回空字符串，不是panic，但结果可能不符合预期 - 若片段来自
map遍历，记得先排序 key 或转成有序 slice，否则结果不稳定 - 典型误用：
parts := make([]string, 0); for k, v := range m { parts = append(parts, k+"="+v) }——append自身频繁扩容，整体性能反被拖累
两三个静态字符串直接用 + 最快
Go 1.20+ 编译器会对 a + b + c 这类局部变量拼接做常量折叠和逃逸优化，压测显示它比 strings.Join 还快 10%～15%，且零分配。
立即学习“go语言免费学习笔记（深入）”；
- 安全例子：
"GET " + path + " HTTP/1.1"（path是函数参数里的string） - 危险例子：
"id=" + strconv.Itoa(x) + "&name=" + url.QueryEscape(n)——中间有函数调用，编译器无法优化，+就退化成性能黑洞 - 调试日志、测试用例里快速构造值，可读性优先，
+完全没问题 - 超过 3 段、或含函数调用，就别幻想编译器优化了
别把 fmt.Sprintf 当拼接工具塞进循环
fmt.Sprintf 是格式化工具，不是拼接工具。它内部会做反射、类型检查、缓存复用等，单次调用没问题，但放进 for 循环里就是性能黑洞。
- 典型误用：遍历 slice 拼 CSV 行，每行都写
fmt.Sprintf("%s,%d,%t", a, b, c) - 正确做法：用
strings.Builder+ 手动写分隔符，或改用fmt.Fprint写到io.Writer - 适合用
fmt.Sprintf的地方：错误信息构造（fmt.Sprintf("failed to parse %q: %v", input, err)）、调试日志、固定模板的一次性渲染 - 参数尽量是具体类型（
string,int），避免传any或空接口，减少反射开销 - 如果必须批量格式化，考虑预分配
[]string存结果，最后用strings.Join
真正容易被忽略的是「场景前提」：不是哪个 API 最快，而是它是否匹配你的数据生成节奏——strings.Join 要求所有字符串已就绪，strings.Builder 要求你能预估长度或接受动态扩容，+ 要求无函数调用介入。漏掉这个前提，基准测试数字再漂亮也没用。
