strings.split不能直接用于连续分隔符是因为它严格按分隔符位置切分，连续分隔符必然产生空字符串，如strings.split("a,,b", ",")返回["a", "", "b"]；需过滤空项应手动遍历或改用strings.fields。
Go 语言里不用自己写字符串分割函数，strings.Split 就是标准、可靠、性能够用的解法 —— 但直接传错分隔符或忽略空字符串处理，会立刻出 bug。
为什么不能用 strings.Split 分割连续分隔符？
它把连续的分隔符当作多个独立分隔位置处理，中间会产生空字符串。比如 strings.Split("a,,b", ",") 返回 []string{"a", "", "b"}，不是你想要的三段数据。
- 常见错误现象：
len(strings.Split("1,,2,,3", ",")) == 5，而非预期的 3 - 使用场景：解析 CSV 片段、日志字段、配置项（如
PATH环境变量）时，原始字符串含冗余分隔符 - 解决办法：先用
strings.ReplaceAll清理，或改用strings.FieldsFunc+ 自定义判断 - 示例：要剔除所有空段，可链式调用
filterEmpty(strings.Split(s, ","))，其中filterEmpty是个简单遍历过滤函数
strings.Split 和 strings.SplitN 的关键区别在哪？
SplitN 控制最多切几刀，对性能敏感或协议字段数固定时更安全；Split 总是全切，可能意外生成超长切片。
-
strings.Split("a:b:c:d", ":")→["a","b","c","d"]（4 个元素） -
strings.SplitN("a:b:c:d", ":", 3)→["a","b","c:d"]（只切前 2 刀，第 3 段保留原样） - 参数差异：
n 时 <code>SplitN行为等同于Split；n == 1时返回原始字符串封装的单元素切片 - 性能影响：当字符串极大且
n很小（如只取前两个字段），SplitN提前终止，避免扫描全文
分割 Unicode 字符（如 emoji 或中文标点）会出问题吗？
不会。strings.Split 按 UTF-8 字节序列操作，而 Go 字符串天然以 UTF-8 存储，emoji 和中文标点都是合法的 rune 序列，只要分隔符本身是完整有效 UTF-8 字符串即可正常匹配。
- 正确示例：
strings.Split("hello?world?", "?")返回["hello", "world?"] - 风险点：若手动拼接字节构造分隔符（如用
[]byte{0xf0, 0x9f}），可能截断 emoji 导致匹配失败 - 兼容性提示：不要用
strings.Split处理需要按 rune 边界切分的场景（例如“取前 5 个汉字”），那得用utf8.RuneCountInString+strings.IndexRune配合手动截取
真正容易被忽略的是：分隔符为空字符串 "" 时，strings.Split 会按 rune 拆成单字符切片 —— 这行为不直观，而且在大多数业务逻辑里属于边界错误，建议加 if sep == "" { panic("empty separator") } 防御。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
