Go 正则匹配变慢怎么查：把 regexp 编译移出请求热路径

订单搜索接口的 P95 从 42ms 涨到 118ms，业务代码没新增查库逻辑，CPU 却在午高峰明显往上跳。用 pprof 排查下来，最显眼的不是 Regexp.MatchString，而是每个请求都在重复调用 regexp.Compile。把正则规则编译一次之后在所有请求间复用，通常就能先砍掉一大块不必要的CPU开销；但动态规则、异常处理和规则数量上限这些点还是要单独做好约束。

先把“变慢”还原成一组可对比的基线

先别急着把所有正则都换成字符串匹配。我们给示例接口 /v1/orders/search 加一条固定规则，用来识别订单号：

var orderNoPattern = `^OD-[0-9]{12}$`

func searchHandler(w http.ResponseWriter, r *http.Request) {
    pattern := r.URL.Query().Get("q")
    re, err := regexp.Compile(orderNoPattern)
    if err != nil {
        http.Error(w, "invalid rule", http.StatusInternalServerError)
        return
    }
    ok := re.MatchString(pattern)
    writeSearchResult(w, ok)
}

用8个并发客户端、每次请求携带12个字符长度的订单号做本地压测，先跑满60秒记录基线：平均耗时74ms，P95是118ms，进程CPU占用约186%，每秒会触发约4200次正则编译。这里的数值只是演示用途，真正有参考价值的是改动前后用完全相同的输入集合和压测窗口跑出来的对比数据。

先用 pprof 证明，慢在编译而不是匹配逻辑

如果服务已经暴露了标准的 pprof 端点，可以在压测过程中采集CPU样本：

go tool pprof -top http://127.0.0.1:6060/debug/pprof/profile?seconds=30

重点看调用树里 regexp.Compile、syntax.Parse 和相关的内存分配逻辑是不是连续出现在热点里。如果热点主要落在匹配函数上，才需要进一步检查规则复杂度、输入长度或者回溯风险；如果编译和解析占比很高，优先调整调用的位置。

这一步的判断很关键：固定规则重复编译，优化方向是复用编译好的对象；规则本身复杂度太高，才需要重写表达式或者拆分匹配逻辑。两个问题表面看都是“正则慢”，但解决思路完全不一样。

用多组小输入确认结论

不要只拿一个超长字符串做实验。提前准备正常订单号、明显不匹配的值和接近长度上限的异常输入各一组，确认优化前后的返回状态完全一致。如果只盯着成功样本测，很容易漏掉错误分支里隐藏的重复解析逻辑。

把固定规则移到初始化阶段

固定规则可以用 regexp.MustCompile 在包初始化时就完成编译。如果规则是程序内置配置，编译失败本身就代表部署包有问题，应该直接让进程启动失败：

var orderNoRE = regexp.MustCompile(`^OD-[0-9]{12}$`)

func searchHandler(w http.ResponseWriter, r *http.Request) {
    query := r.URL.Query().Get("q")
    writeSearchResult(w, orderNoRE.MatchString(query))
}

如果规则来自配置文件，使用 regexp.Compile 也完全可行，但要在加载配置的时候就完成编译并返回错误，不能等第一笔请求进来才触发编译：

func loadOrderRule(raw string) (*regexp.Regexp, error) {
    if len(raw) == 0 || len(raw) > 160 {
        return nil, errors.New("order rule length is outside the limit")
    }
    return regexp.Compile(raw)
}

这里保留长度限制，是为了防止把一段没经过约束的用户输入直接当成正则规则。做性能优化不能顺手把配置的边界校验逻辑一起删掉。

重新压测：核对 P95、CPU 和结果一致性

改动后的压测还是用同样的并发数、请求体和持续时间。示例结果是平均耗时31ms，P95 47ms，CPU约92%，编译调用降为启动时的1次。这个结果只能说明热路径的开销被移走了，不能直接推导到所有接口都能拿到同比例的性能提升。

回归检查至少要覆盖三类输入：

• 合法值：OD-202607201234 应返回匹配成功。
• 长度正确但格式错误的值：应返回业务层面的“不匹配”，而不是直接抛500错误。
• 超长输入和错误配置：前者应提前被输入边界限制拦截，后者应在启动或配置刷新阶段就被拒绝。

如果用的是动态规则，可以把编译后的对象放进带容量上限的缓存，同时给规则版本设置失效时间。缓存命中率、规则数量和编译失败数都要留日志或者埋指标上报，不然只是把请求期暴露的问题藏到了缓存层里。

哪些情况下不该简单套用全局复用正则的方案

第一种是规则由用户自由提交。哪怕编译后的对象可以缓存，也要限制规则长度、字符集、输入长度和单用户可创建的规则数量；必要时把匹配逻辑放到隔离的任务进程里执行。

第二种是规则会频繁变化。每次配置热更新都重新编译并替换只读引用，旧规则继续服务完当前请求再回收资源。不要在共享map上边读边改，也不要为了省一次锁把还没编译完的规则发布出去。

第三种是规则只做前缀、后缀或者简单包含判断。这时候 strings.HasPrefix、strings.HasSuffix 和 strings.Contains 逻辑更直白，后续做基准测试也更容易排查问题。

相关问题：正则优化后还要检查什么

regexp.Regexp 可以在多个请求间复用吗？

可以。编译完成后，*regexp.Regexp 的匹配方法本身是并发安全的；规则更新时应该通过替换引用的方式发布新对象。

为什么平均耗时下降，P95 却没有变化？

这通常说明长尾请求的根因来自数据库、网络或者锁等待，和正则编译没关系。继续用 trace、慢查询和依赖耗时拆分请求全链路，不要死盯着CPU指标查问题。

所有正则都应该改成 MustCompile 吗？

不是。只有规则是代码里的常量且编译失败应视为程序本身错误的场景才适合用MustCompile；外部配置读取的规则必须返回错误，同时提供清晰的加载失败提示。

把优化结论落成一条可复查的规则

固定规则：启动时编译，请求中直接复用；外部规则：先做限制，再做缓存，同时记录命中和失败指标；简单匹配场景：优先用原生字符串函数实现。每次改动都保留同一套压测输入，复查 P95、CPU、编译次数和返回结果四项，才能确认这次优化真正解决了目标问题。