循环拼接必须用strings.Builder，禁用+=；需预调Grow()避免扩容开销；fmt.Sprintf纯拼接是反模式；strings.Join仅适用于已知[]string切片；Unicode下len()预估长度不可靠。
拼接字符串不能只看“能不能写出来”，得看场景：循环里用 + 会慢 50 倍，fmt.Sprintf 纯拼接是反模式，strings.Join 只对切片有效，而 Unicode 下用 len() 预估长度大概率翻车。
循环中拼接字符串必须用 strings.Builder
每次 str += s 都会复制前面所有字节，100 次循环 → O(N²) 时间、几十次内存分配、GC 压力陡增。这不是“能跑就行”的问题，是上线后 CPU 突增的根源。
- 初始化后立刻调
b.Grow(预估长度)，比如日志行平均 200 字节，就写b.Grow(2048)，能砍掉 90% 的扩容开销 - 只用
b.WriteString(s)，别用b.Write([]byte(s))—— 多一次类型转换，还可能触发额外拷贝 -
b.String()只能调一次；想复用 builder，必须先b.Reset()，重新声明变量不等于重置状态 - 别和
bytes.Buffer混用：strings.Builder更轻（无锁、无读接口），String()返回结果也不额外复制
已有 []string 就直接用 strings.Join
它不是“另一个拼接选项”，而是针对切片场景的最优解：一次分配、一次拷贝、零中间对象。比手写循环 + 还快一个数量级。
- 分隔符是空字符串
""时最快，效果等价于把所有元素首尾相接 - 切片长度为 0 → 返回
""；长度为 1 → 直接返回该字符串，不加任何分隔符 - 别为了用
strings.Join先把几个变量塞进切片：[]string{a, b, c}再 join，反而多一次切片分配 - 非字符串类型（如
[]int）要手动转：strconv.Itoa比fmt.Sprint更轻，后者有反射开销
混合类型（字符串 + 整数）优先用 fmt.Sprintf
Go 不支持隐式类型转换，"key:" + 123 直接编译失败。这时候 + 不是省事，是写不动。
立即学习“go语言免费学习笔记（深入）”；
-
fmt.Sprintf("%s%d%s", "id=", id, ", name="+name)是安全且清晰的选择，自动处理类型、无需手动转 - 需要格式控制才体现价值：补零（
%04d）、引号包裹（%q）、浮点精度（%.2f） - 纯拼接（如
fmt.Sprintf("%s%s", a, b)）是典型误用，比a + b慢 3–5 倍，还掩盖真实意图 - 参数类型错位（比如用
%d格式化字符串）不会编译报错，运行时 panic，没有编译检查
Unicode 场景下别信 len()
拼接本身不受影响，+ 和 strings.Builder 都按 UTF-8 字节处理，结果正确。但只要你基于 len() 做预分配、截断或索引，中文、emoji 就会让你得到完全错误的字节数。
-
len("你好") == 6，但字符数是 2 —— 要算长度用utf8.RuneCountInString("你好") - 要截前 5 个字符？不能
s[:5]，得转成[]rune再切：string([]rune(s)[:5]) -
strings.Builder.Grow()的参数是字节数，不是字符数；预估时得按 UTF-8 编码习惯估算（中文平均 3 字节，ASCII 1 字节） - range 遍历字符串拿到的是 rune 索引位置，不是字节偏移 —— 这点和
len()的含义根本不一致，混用必出 bug
