Go strings包函数均为纯函数，不修改原串；TrimSpace仅处理ASCII空白，对全角空格等无效；Split按字面分隔，Fields按空白切并去空；ReplaceAll高频替换性能差；Builder需预分配容量；Contains对空串恒返回true。
strings 包所有函数都是纯函数、无状态、不修改原字符串，调用时必须显式传入字符串作为第一个参数——这不是约定，是 Go 的硬性设计。
strings.TrimSpace 对全角空格、零宽字符无效，不是 bug
它只识别 ASCII 空白字符：' '、'\t'、'\n'、'\r'、'\f'、'\v'。Unicode 中的全角空格（'\u3000'）、零宽空格（'\u200b'）、不间断空格（'\u00a0'）全部被忽略。
- 常见错误：用户从微信粘贴用户名
"admin\u3000"，strings.TrimSpace返回仍是"admin\u3000"，== ""判断失败，导致空校验绕过 - 真实场景多见于富文本导出、网页表单提交、OCR 识别结果清洗
- 修复建议优先用
strings.Map+unicode.IsSpace，比正则轻量且语义清晰
示例：
func trimAllSpace(s string) string {
return strings.Map(func(r rune) rune {
if unicode.IsSpace(r) {
return -1
}
return r
}, s)
}
strings.Split 和 strings.Fields 行为完全不同，混用必出错
strings.Split 是字面匹配分隔符，strings.Fields 是按任意空白字符切并自动丢弃空串——二者语义不可互换。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误：
strings.Split("a b c", " ")得到[]string{"a", "", "b", "", "", "c"}，遍历时容易触发panic: index out of range - 用
strings.Split：适合固定分隔符，如解析 CSV（","）、路径（"/"）、HTTP 头（":"） - 用
strings.Fields：适合自然输入，如命令行参数、日志关键词提取、配置项列表；它还把\r\n、\u2028（行分隔符）等也当空白处理
strings.ReplaceAll 在大字符串高频替换时性能明显下滑
每次调用都生成新字符串，底层反复分配内存。当原始字符串 >1KB、替换次数多（如循环中）、或用于模板渲染（HTML/日志）时，GC 压力和 CPU 占用会肉眼可见上升。
- 常见错误现象：火焰图里
runtime.mallocgc占比突增，QPS 下降 - 若已知替换位置或只需替换前 N 次，改用
strings.Replace(s, old, new, n)显式指定次数 - 若需批量替换多个不同子串，别链式调用多次
ReplaceAll，改用strings.NewReplacer实例复用 -
strings.Builder更适合拼接类场景，记得先调用b.Grow(len(s))预分配容量
strings.Contains 对空字符串永远返回 true，必须显式排除
这是文档明确定义的行为（“empty string is contained in any string”），不是 bug。但实际业务中，你几乎从来不想让空搜索词通过校验。
- 常见错误：用户提交空关键词，
strings.Contains(text, keyword)返回true，逻辑被绕过 - 正确写法必须加前置判断：
if keyword != "" && strings.Contains(s, keyword) - 性能影响极小，但漏掉会导致语义错误——比慢更危险
- 同理：
strings.ContainsAny("", "")返回false，而strings.Contains("", "")返回true，二者行为不一致，不能假设对称
真正难的不是记函数名，而是理解每个函数的边界条件：哪些字符算“空白”，哪些分隔符会留空字段，空串在不同函数里为何有不同表现。这些细节在日志清洗、用户输入校验、协议解析里一踩一个准。
