strings.Split 会保留空字段，需手动过滤；SplitN 可限制次数；空分隔符会 panic；Replace 需指定 n=-1 才全替换；大小写比较优先用 ContainsFold；大量拼接用 Builder 更高效。
strings.Split 拆分字符串时，空字段和边界情况怎么处理？
strings.Split 看似简单，但一不留神就会拿到一堆空字符串。比如 strings.Split(",a,,b,", ",") 返回 []string{"", "a", "", "b", ""} —— 开头、中间连续分隔符、结尾都会产生空元素。
- 若你解析的是 CSV 或配置项（如
"key1=value1,,key2=value2"），得手动过滤：if p != ""才保留 - 想跳过所有空白分隔逻辑？改用
strings.Fields，它按任意空白字符（空格、\t、\n）切分，并自动丢弃空项 - 需要保留空字段但限制切分次数？用
strings.SplitN(s, sep, n)，比如SplitN("a,b,c,d", ",", 3)得到["a", "b", "c,d"] - 传空字符串
""作分隔符会 panic，这点必须提前校验，不能依赖运行时捕获
strings.Replace 和 strings.ReplaceAll 到底该用哪个？
别被名字迷惑：strings.Replace 不是“只换一次”，而是“最多换 n 次”；n = -1 才等价于 strings.ReplaceAll。线上代码里写 strings.Replace(text, "old", "new", 1) 却本意想全替换，是高频低级错误。
- 明确要全部替换 → 直接用
strings.ReplaceAll，语义清晰，不易出错 - 需控制替换数量（如日志脱敏只掩码前两个手机号）→ 用
strings.Replace并传具体正整数 - 替换空字符串合法但危险：
strings.Replace("abc", "", "-", -1)会在每个 rune 之间插入-，结果是"-a-b-c-"，慎用
忽略大小写的子串判断，为什么不用 strings.ToLower 预处理？
strings.Contains(strings.ToLower(s), strings.ToLower(substr)) 能用，但不推荐作为默认方案：它强制分配两份小写副本，对长字符串或高频调用有额外内存开销。
- Go 1.19+ 推荐用
strings.ContainsFold，底层基于 Unicode 大小写折叠（case-folding），更准确也更省内存 - 前缀/后缀判断同理：
strings.HasPrefix和strings.HasSuffix没有 Fold 变体，此时才考虑ToLower预处理 - 注意：
strings.EqualFold是专用于两字符串比较的，别误用在子串场景
大量字符串拼接时，Join 和 Builder 哪个更合适？
strings.Join 适合已知全部元素的静态拼接（如 SQL IN 子句、HTTP 查询参数）；但若需循环追加、边处理边构建（如生成 HTML 片段或日志行），strings.Builder 才是正确选择。
立即学习“go语言免费学习笔记（深入）”；
-
strings.Join对nil切片会 panic，调用前务必检查：if elems == nil { elems = []string{} } -
strings.Builder底层复用字节 slice，避免重复分配；调用WriteString或WriteRune即可累积内容，最后builder.String()获取结果 - 性能差异在元素数 > 10 或字符串总长 > 1KB 时开始明显；小量拼接用
Join更简洁，无需过度优化
真正容易被忽略的，不是函数有没有，而是它们组合使用的边界条件：比如 Split 后忘了清空字段就直接 Join，或者在热路径里反复调用 ToLower 做大小写无关匹配。标准库够用，但得懂它在哪停、在哪拐、哪条路会绕远。
