go字符串拼接需按场景选最优方式：循环用strings.builder（预估字节数+writestring），切片用strings.join，少量静态拼接用+，避免+在循环中、fmt.sprintf纯拼接及len()误判unicode长度。
Go 里拼接字符串不是“怎么写都行”，而是“选错方式就拖慢程序”。循环里用 +，100 次拼接可能比 strings.Builder 慢 50 倍；fmt.Sprintf 看起来像胶水，实际是格式化引擎，纯拼接时连 + 都不如。
循环中拼接必须用 strings.Builder
每次 str += s 都要分配新内存、复制全部旧内容，N 次循环 → O(N²) 时间 + 大量临时内存。GC 压力陡增，CPU 缓存失效，实测慢几十倍。
- 声明
var b strings.Builder，初始化后立即调b.Grow(预估字节数)（比如日志平均 256 字节，就b.Grow(2048)） - 只用
b.WriteString(s)，别混用b.Write([]byte(s))——多一次类型转换，还可能触发额外拷贝 -
b.String()只调一次；之后要复用，必须b.Reset()，不能靠重新声明变量 - 别和
bytes.Buffer混用：strings.Builder更轻（无锁、无读接口），String()是零拷贝
已有 []string 切片时优先用 strings.Join
它底层单次计算总长、单次分配、单次拷贝，没有中间对象。比手写 for + += 快一个数量级，语义也最干净。
- 分隔符为
""时最快，等价于把所有元素首尾粘一起 -
len(parts) == 0→ 返回""；len(parts) == 1→ 直接返回该字符串，不加任何分隔符 - 别为了用
strings.Join先strings.Split再拼回去——白费一次分配和遍历 - 非字符串类型（如
[]int）得手动转：strconv.Itoa比fmt.Sprint更轻，后者有反射开销
少量静态拼接（≤3 段）直接用 +
2～3 个已知字符串连起来，比如 "User: " + name + ", ID: " + strconv.Itoa(id)，编译器会优化常量部分，运行时零开销，可读性还高。
- 数字、布尔等非字符串类型必须显式转换，
+不自动调fmt.Sprint - 编译期常量拼接（如
"a" + "b" + "c"）会被合并成单个字符串，完全没 runtime 开销 - 别在
for range里写result += item，哪怕只有 50 次，性能落差也会立刻显现
Unicode 场景下别用 len() 做预分配或截断
拼接本身不受影响，+ 和 strings.Builder 都按 UTF-8 字节处理，结果正确。但如果你基于 len() 做预分配或截断，中文、emoji 会让结果错得离谱——len("你好") == 6，但它只有 2 个字符。
- 需要字符数时，用
utf8.RuneCountInString(s)，不是len([]rune(s))（后者多一次分配） -
strings.Builder.Grow的参数是字节数，预估时得按 UTF-8 编码算，不是按字符数拍脑袋 - 真正容易被忽略的，是 Unicode 下的长度误判——它不报错，只悄悄让预分配不足、截断错位、日志字段错乱，而且只在中文或 emoji 出现时才暴露
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
