strings包中真正高性能的函数仅有strings.builder、strings.replace（n可控时）和strings.split（分隔符长为1时），其余如toupper等仅逻辑简洁并无性能优势。
strings 包里真正高性能的函数，只有 strings.Builder 和 strings.Replace（带 n 参数时可控）、strings.Split（底层用 unsafe.String 避免拷贝）这几个是经过 runtime 优化的；其余如 ToUpper、TrimSpace 等只是逻辑简洁，并不比你自己遍历快。
为什么 strings.Builder 是唯一被 runtime 特别照顾的字符串拼接方式
它不是“写得巧”，而是 Go 编译器和 runtime 在多个层面做了硬编码支持：
-
Builder.String()调用的是unsafe.String(&b.buf[0], len(b.buf))，完全绕过内存拷贝 —— 这是其他任何字符串构造方式都做不到的 -
Builder.Grow(n)触发的预分配，会直接调用runtime.makeslice，且扩容策略（ - 如果没调用
Grow，首次WriteString会默认分配 64 字节，这个常量写死在src/strings/builder.go里
反例：s += "x" 每次都走 runtime.concatstring2，每次都要 malloc 新内存 + memcpy 原内容 —— 即使只拼 10 次，GC 压力也明显可测。
strings.Replace 的 n 参数决定是否触发 fast path
当 n >= 0 且替换次数有限时，Go 会走一个高度优化的汇编 fast path（位于 src/runtime/string.go），跳过构建完整切片、避免中间 []string 分配；但一旦 n == -1（全量替换），就会退化为通用路径，先 Split 再 Join，多一次遍历 + 多一次切片分配。
- 敏感词过滤场景下，用
strings.Replace(s, bad, "***", 1)比ReplaceAll快 30%~50%，尤其当坏词只出现一次时 - 若确定只替换首个匹配项，
strings.Index+ 手动切片拼接反而更轻量（无额外切片分配）
strings.Split 和 strings.Join 的零拷贝边界很窄
它们只在「分隔符长度为 1」且「输入字符串不为空」时，才可能复用底层字节数组指针 —— 这个优化藏在 runtime.findnull 和 unsafe.String 的联动里。但只要 sep 长度 ≠ 1（比如 "\n\r" 或正则分隔），就立刻退回到朴素循环 + 每次 unsafe.String 调用。
-
strings.Split("a,b,c", ",")返回的三个string共享原字符串底层数组（只读），内存零新增 -
strings.Split("a|b|c", "|")同样高效；但strings.Split("a;;b;;c", ";;")就会为每个子串单独分配内存 -
Join只对[]string切片中每个元素调用一次unsafe.String，不合并底层存储 —— 所以它快，但不是“共享”意义上的快
真正容易被忽略的是：所有 strings 函数返回的新 string，哪怕内容和原字符串完全一样（比如 TrimSpace("abc") 对无空格字符串），也会生成新结构体 —— 因为 string 是值类型，且底层 str 指针无法跨函数复用（编译器不保证逃逸分析能消除）。这意味着，高频调用时，哪怕不做任何修改，也要承担结构体复制开销。
