Go字符串处理不当会导致算法退化：+拼接、strings.Split滥用、频繁byte/string转换均引发O(n²)或GC超时；strings.Builder通过预分配切片避免重复拷贝，性能提升数十倍，但需注意非线程安全、必须调用String()获取结果等使用约束。
+ 拼接、strings.Split 不加节制、反复 []byte ↔ string 转换，都会让本该 O(n) 的算法退化成 O(n²) 或触发频繁 GC 导致超时。
为什么 strings.Builder 比 + 快几十倍？
因为 + 每次拼接都新建字符串并复制全部已有内容，1000 次循环就是约 50 万次字节拷贝；而 strings.Builder 底层用预分配的 byte 切片，只在容量不足时扩容（通常 1–2 次），写入是纯追加。
-
strings.Builder必须调用String()才能拿到最终结果，不能中途读取或修改内部 buffer - 如果已知总长度（比如拼接固定格式日志），用
builder.Grow(n)预分配，避免任何扩容 - 不要对同一个
strings.Builder实例并发调用WriteString—— 它不是线程安全的
strings.Split 用错场景会拖慢整个算法
strings.Split 返回的是 []string，每个子串都共享原字符串底层数组。若原字符串很大（如读入整篇 HTML），而你只取其中几个短 token，却长期持有这些子串，会导致整块内存无法被 GC 回收。
- 临时解析且后续只用少量字段 → 直接用
strings.SplitN(s, sep, n)限制切片数量 - 需要长期保存子串（如存入 map 或结构体）→ 显式复制：
sub = string([]byte(sub))或sub = sub[:len(sub):len(sub)] - 高频拆分（如 CSV 行解析）→ 改用
strings.Index+ 手动游标移动，避免分配切片
什么时候必须用 []byte 而不是 string？
当你需要修改内容、做大量 I/O、或调用底层系统接口时，[]byte 是唯一选择。Go 标准库里很多高性能路径（如 net/http body、json.Unmarshal、regexp.Match）都优先接受 []byte。
- 从文件/网络读取后直接处理 → 保持为
[]byte，直到最后一步才转string（如有必要） - 正则匹配大文本 → 用
re.FindAllIndex([]byte(text), -1)，比re.FindAllString少一次转换开销 - 修改字符串某几位（如 Base64 编码中间替换）→ 必须转
[]byte，改完再转回（注意 UTF-8 编码边界）
容易被忽略的 rune vs byte 边界问题
Go 的 string 是 UTF-8 字节序列，len(s) 返回字节数，不是字符数。用 s[i] 下标访问可能截断中文或 emoji，导致 panic 或乱码。
立即学习“go语言免费学习笔记（深入）”；
- 需要按字符（rune）遍历时，用
for _, r := range s，不是for i := 0; i - 截取前 N 个字符 → 先转
[]rune，再切片，最后转回string（小数据可接受，大数据慎用） - 判断是否包含某个 Unicode 字符 → 用
strings.ContainsRune，而非strings.Contains（后者按字节匹配）
go test -bench=. 对比下不同拼接/拆分方式的耗时——差别常常在 10 倍以上。 
