<p>正则匹配慢主因是引擎在长字符串中指数级回溯，尤其 .* 等结构；应优先用否定字符类、锚点、预筛选和编译复用优化。</p>
正则匹配慢，往往不是因为“写得不够巧”，而是让引擎在长字符串里反复试错。真正卡住的，是那些看似简单、实则触发指数级回溯的模式——尤其当输入变长时，耗时不是线性增长，而是翻倍再翻倍。
别让 .* 成为性能黑洞
通配符 .* 是最常被滥用的结构之一。它不指定边界，引擎只能一路吞到底，再逐个吐出来尝试匹配后续内容。比如 <div>(.*)</div> 遇到嵌套或缺失闭合标签，就会陷入深度回溯。
- 优先用否定字符类替代：想匹配 HTML 标签内文本？用
<div>([^<]*)</div>比<div>(.*)</div>稳定得多 - 如果必须跨行，明确限定范围：用
[\s\S]*?替代.*?（配合s标志），但更推荐直接拆解逻辑 - 非贪婪只是缓解，不是根治：
.*?在复杂上下文中仍可能回溯，关键还是缩小可选字符集
锚点和边界要写死，别靠运气
没加 ^ 和 $ 的正则，引擎会在每个位置都尝试匹配一遍。一个 10KB 的日志行，光找开头就多做上万次无效试探。
- 验证完整字符串？必须写
^\d{6}$，而不是\d{6} - 提取固定前缀？用
^GET\s+([^\s]+)，比GET\s+([^\s]+)少遍历 99% 的文本 - 路径匹配场景中，
^/api/v\d+/users/\d+$能立刻排除所有不以/api开头的请求
长文本处理前先切片或分流
正则不是万能的扫描器。面对几 MB 的日志或 HTML 文本，先用轻量方法定位大致区域，再交给正则精匹配，效率提升远超调优单个 pattern。
- 用
strings.Index或bytes.Index快速跳转到疑似起始位置（如找到第一个<script>） - 对用户输入做白名单预检：若字段只允许字母数字，先
strings.HasPrefix(input, "user_")，不满足直接返回，不进正则 - Golang 中可结合
bufio.Scanner按行处理，避免一次性加载整块长文本到内存
编译一次，反复使用，别在热路径里重编
每次调用 regexp.Compile 都要解析语法树、构建 NFA、做初步优化——这个过程开销远大于一次匹配。QPS 上千的服务里，这一步常成 CPU 瓶颈。
- 把常用 pattern 声明为包级变量：
var userPath = regexp.MustCompile(`^/user/\d+$`) - 运行时拼接的 pattern（如搜索关键词），改用
regexp.CompilePOSIX或退回到strings.Contains+strings.Fields - Go 1.20+ 支持原子组
(?>...)，但注意旧版本 panic；稳妥做法是提前用否定字符类重构逻辑
