应使用 regexp.Split 而非 strings.Split 实现正则模式切分，因后者仅支持字面量；需预编译正则（如全局变量），注意空匹配产生空字符串、n 参数控制段数，并在必要时手动过滤或改用 Find 系列方法。
用 regexp.Split 而不是 strings.Split
Go 的 strings.Split 只支持固定子串，没法处理正则；真要按模式切分，必须上 regexp 包。别想着“先编译再调用”，regexp.Split 是唯一正路——它内部会复用已编译的 *regexp.Regexp 实例，性能没问题。
常见错误是误用 strings.Split 配正则字符（比如写 strings.Split(s, "\s+")），结果白切了：它把 "\s+" 当字面量，不是正则。
-
regexp.MustCompile编译一次，反复用，别每次调用都MustCompile - 第二个参数
n控制最多切几段：-1全切，0等价于-1，1返回原字符串（不切） - 空匹配（如
^或$）会导致开头/结尾多出空字符串，要留意
regexp.Split 的边界行为和空字符串陷阱
正则匹配到空字符串时，Split 会在每个匹配位置插入一个空段。比如用 regexp.MustCompile(`""`)（空字符串正则）切 "abc"，结果是 []string{"", "a", "b", "c", ""} —— 这不是 bug，是规范行为。
典型踩坑场景：用 `s*` 切分想“忽略空白”，结果一堆 "" 冒出来；该用 `s+` 才对。
立即学习“go语言免费学习笔记（深入）”；
- 想跳过空段？自己过滤：
result = filterEmpty(result) - 想保留分隔符？
Split不行，改用FindStringSubmatchIndex+ 手动截取 - 注意 Unicode：默认
w、d不匹配中文，需加(?U)标志
性能敏感时怎么避免重复编译
高频调用正则分割（比如日志解析循环里），regexp.MustCompile 放全局变量或 sync.Once 初始化，千万别塞进函数体里。Go 的正则引擎编译开销不小，尤其带回溯的模式（如 .* 嵌套）。
- 示例：
var spaceSplitter = regexp.MustCompile(`s+`)，然后用spaceSplitter.Split(s, -1) - 如果正则模式动态生成（如用户输入），用
regexp.Compile并检查err，别硬上MustCompile - 简单场景（如只切空格、逗号）仍优先用
strings.Fields或strings.Split，快一个数量级
替代方案：什么时候不该用 regexp.Split
正则分割不是万能锤。比如要按“非字母数字字符”切但保留分隔符，或需要捕获组内容，Split 就力不从心。
- 要保留分隔符：用
FindAllString+FindAllStringIndex自己拼 - 要按多个不同模式切（如“逗号或分号或换行”）：写成
`[,; ]+`更干净，别写多个Split嵌套 - 纯 ASCII 分隔符且无歧义（如 CSV 字段）：考虑
encoding/csv包，比正则更稳
真正难的从来不是写对正则，而是判断“这里到底该不该用正则”。多数时候，先问一句：这个分隔逻辑，未来会不会有人改需求加例外？越容易变的，越不适合绑死在正则里。
