strings.split("", "x") 返回 []string{""} 而非 []string{}，这是 go 标准库明确设计：空字符串被视为“一个空段”，保证 len(split(s, sep)) == count(s, sep) + 1 恒成立，支撑索引安全与遍历一致性。
strings.Split("", "x") 返回 [""] 而不是 []string{}
这是 Go 标准库明确规定的逻辑，不是 bug。当输入字符串为空时，strings.Split 总是返回一个包含单个空字符串的切片：[]string{""}。这个行为容易让人误以为“没东西可分就该返回空切片”，但实际设计是“空字符串本身就是一个有效分割结果”。
常见错误现象：用 len(strings.Split(s, ",")) 判断 CSV 字段数，当 s == "" 时得到 1 而非 0，导致后续逻辑多处理一个空字段。
- 参数差异：
strings.Split("a,b", ",")→[]string{"a","b"}；strings.Split("", ",")→[]string{""}；strings.Split(",,", ",")→[]string{"","",""} - 性能影响极小，但语义陷阱明显——它不区分“无输入”和“输入为空字符串”
- 若需统一空输入返回空切片，得手动后处理：
if s == "" { return []string{} }
为什么 strings.SplitN("", sep, 0) 和 strings.SplitN("", sep, 1) 行为一致
strings.SplitN 的 n 参数控制最大分割次数，但对空字符串输入不生效。无论 n 是 0、1 还是负数，strings.SplitN("", "x", n) 永远返回 []string{""}。
使用场景：写解析器时假设 SplitN(s, ",", 2) 最多返回两个元素，却在 s == "" 时拿到一个元素，看似符合预期，实则掩盖了空输入未被识别的问题。
-
n == 0表示“不限次数”，但空字符串无法分割，仍返回[]string{""} -
n == 1表示“最多切一次”，空字符串连一次切的机会都没有，还是[]string{""} - 真正影响结果的是输入字符串是否含分隔符，而不是
n值
对比 strings.Fields 和正则 regexp.Split 的空字符串处理
如果你需要“空输入 → 空切片”的语义，strings.Fields 是更安全的替代方案（但它按 Unicode 空格分割，且自动跳过所有空白字段）；而 regexp.Split 在空字符串输入时也返回 []string{""}，和 strings.Split 保持一致。
容易踩的坑：有人试图用 regexp.MustCompile(`,`).Split("", -1) 替代 strings.Split，结果发现行为完全一样，白白引入正则开销。
-
strings.Fields("")→[]string{}（空切片），适合纯空白敏感场景 -
regexp.MustCompile(`,`).Split("a,,b", -1)→[]string{"a","","b"}，但regexp.MustCompile(`,`).Split("", -1)→[]string{""} - 若分隔符是动态生成的（比如用户输入），且需兼容空输入，必须显式判断：
if s == "" { return []string{} }
真实项目中如何安全使用 strings.Split
绝大多数情况下，你不是在处理“理论上的空字符串”，而是在解析 HTTP 查询参数、日志行、配置文件字段——这些来源本身就可能带空值。关键不是避免空输入，而是让代码对 []string{""} 的出现有明确预期。
- 检查切片长度前，先确认原始字符串非空：
if s != "" && len(strings.Split(s, ",")) > 2 { ... } - 用
strings.TrimSpace预处理再 split，能过滤掉纯空白干扰：strings.Split(strings.TrimSpace(s), ",") - 若业务上“空字段”有意义（如 CSV 中的
,,），那就接受""元素；若“空输入”和“空字段”必须区分，就得在 split 前做守卫判断
最常被忽略的一点：这个行为在 Go 1.0 就已固化，所有版本一致，没法靠升级绕过。它不难记，但一旦漏掉，就会在边界 case 上静默出错。
