strings.contains 搜不到子串常见因大小写敏感或 unicode 组合字符未归一化；strings.replaceall 替换后长度异常多因误用 replace 且未传 -1；正则替换需用 regexp 包而非 strings；builder 仅在高频追加且长度可预期时优于 + 拼接。
strings.Contains 为什么搜不到明明存在的子串？
常见错误是忽略大小写或 Unicode 边界问题。比如 strings.Contains("Go语言", "go")
false，不是函数坏了，而是它严格按字节逐字符比对，不自动转大小写，也不处理组合字符（如带重音的字母）。
使用场景：快速判断存在性，不要求位置或上下文。
- 区分大小写时，先用
strings.ToLower或strings.ToUpper统一再查（但注意性能开销） - 需要模糊匹配（如忽略重音、全半角），别硬扛
strings，换golang.org/x/text/search - 搜索中文时，只要源字符串和子串都是合法 UTF-8 字符串，
strings.Contains没问题——Golang 的string本质就是 UTF-8 字节数组，无需额外 decode
strings.ReplaceAll 替换后长度异常变长？
典型现象：原字符串 100 字节，替换后变成 150+ 字节，看着像“重复替换了”。实际多数是误用了 strings.Replace 而非 strings.ReplaceAll，漏传了第 4 个参数 -1。
参数差异很关键：strings.Replace(s, old, new, n) 中 n 是最大替换次数，n = -1 才等价于全部替换；设成 1 就只换第一个匹配项。
立即学习“go语言免费学习笔记（深入）”；
- 永远优先用
strings.ReplaceAll，语义清晰，不易错 - 如果真要限制次数（比如只替换前 3 处），明确传
3，别传0（那会不替换任何内容） - 注意
old是空字符串""时，ReplaceAll会在每个 rune 之间插入new，结果爆炸式增长——这是定义行为，不是 bug
想按正则替换，但 strings 包里找不到 Regexp？
strings 包压根不支持正则。所有带 Regexp 的函数都在 regexp 包里，比如 regexp.ReplaceAllString 或 regexp.MustCompile。
性能影响明显：编译正则表达式（regexp.MustCompile）有开销，不能在热循环里反复调用；而 strings 系列全是纯字节操作，零分配、O(n) 时间。
- 简单字面量替换，死守
strings.ReplaceAll，别为省几行代码引入regexp - 需要捕获分组、边界断言（
）、或动态模式时，才上regexp；记得把正则对象缓存为包级变量，避免重复编译 - 错误信息如
error parsing regexp: invalid escape sequence，大概率是没用原始字符串字面量——写成regexp.MustCompile(`d+`)，而不是"\d+"
strings.Builder 什么时候该用，什么时候纯属多此一举？
单次拼接少于 4–5 个字符串，直接用 + 或 fmt.Sprintf 更简洁；只有频繁追加（比如循环内拼 SQL 或日志）、且最终长度可预期时，strings.Builder 才显价值。
它底层复用字节切片，避免多次内存分配，但初始化和调用 WriteString 本身也有微小固定开销。
- 别在函数开头无脑声明
var b strings.Builder，然后只写两次b.WriteString—— 这反而比s1 + s2 + s3慢 - 如果已知最终长度（比如拼 100 条固定格式日志），调用
b.Grow(estimatedSize)预分配，能进一步减少扩容次数 -
Builder.String()返回的是拷贝，之后继续写入不影响已生成字符串；但别把它当缓冲区反复Reset()复用——除非你确认生命周期可控，否则容易残留旧数据
strings 函数全是对 UTF-8 字节的安全操作，不是“字符”操作；所谓“中文支持好”，是因为 Go 字符串天然是 UTF-8，不是因为库做了什么特殊处理。 
