Go regexp 编译放请求路径为什么拖慢 p99：预编译、缓存和基线对比

接口只是给订单号做一次格式校验，线上p99却从18ms慢到70ms，CPU使用率没有明显变化。排查这类抖动时，先看请求函数里是否每次都调用了 regexp.Compile：匹配本身可能很快，但编译规则、分配对象和错误处理的开销，会被每个请求重复承担。

固定规则在包初始化阶段预编译；规则来自用户或配置时，先限制缓存容量，再用命中率、编译次数和p99一起验收。不要为了“缓存一下”把无限增长的pattern当成方案。

先把regexp.Compile的成本从匹配成本里拆出来

先写一组小基线对照，比凭感觉改代码可靠得多。下面的代码模拟固定订单号规则，第一组在每次调用时编译，第二组只复用已经编译好的 *regexp.Regexp。

package regexpbench

import "regexp"

const orderIDPattern = `^ORD-[0-9]{12}$`

func matchOnRequest(value string) bool {
	re, err := regexp.Compile(orderIDPattern)
	if err != nil {
		return false
	}
	return re.MatchString(value)
}

var orderID = regexp.MustCompile(orderIDPattern)

func matchWithPrepared(value string) bool {
	return orderID.MatchString(value)
}

两个函数得到的匹配结果完全相同，但计时范围完全不同。固定规则只需要解析一次，后续请求直接进入 MatchString。如果规则写死在源码里，初始化阶段失败通常意味着程序不能按预期启动，使用 MustCompile 更容易让问题提前暴露；如果规则来自配置文件，则应在加载配置时检查错误并拒绝无效配置。

用benchmark看清“编译加匹配”和“只匹配”的差距

测试时不要只打印一个总耗时就下结论。把输入固定下来，并让benchmark结果包含分配次数统计，才能知道性能差异的真实来源。

func BenchmarkCompileAndMatch(b *testing.B) {
	for i := 0; i 

运行 go test -bench='Regexp' -benchmem -count=5，重点看 ns/op、B/op 和 allocs/op。这里的数值会随Go版本、CPU和正则复杂度变化，不应把某台机器的绝对数字当作线上性能承诺。可复现的判断标准是：当同一个固定pattern被请求重复使用时，预编译组的编译次数应为零，内存分配和尾延迟也会明显低于每次编译的对照组。

再做一次输入长度对比。Go regexp的实现保证匹配时间随输入长度线性增长，但“线性”不等于“没有额外成本”：把2KB、32KB、512KB的请求字段混在同一个接口里，p99仍可能被大输入推高。长度限制应该在进入正则逻辑之前完成。

动态规则只能做有限缓存

搜索过滤、租户配置或后台自定义规则会让pattern变成动态值。这时不能简单地把每个pattern放进全局map：规则数量一旦跟请求数一起增长，缓存会从性能优化工具变成内存故障源。

type PatternCache struct {
	mu    sync.RWMutex
	limit int
	items map[string]*regexp.Regexp
}

func (c *PatternCache) Get(pattern string) (*regexp.Regexp, error) {
	c.mu.RLock()
	re := c.items[pattern]
	c.mu.RUnlock()
	if re != nil {
		return re, nil
	}

	compiled, err := regexp.Compile(pattern)
	if err != nil {
		return nil, err
	}
	c.mu.Lock()
	if len(c.items) >= c.limit {
		c.evictOne()
	}
	c.items[pattern] = compiled
	c.mu.Unlock()
	return compiled, nil
}

示例只展示边界思路，不是完整的并发缓存库。生产代码还要明确淘汰策略、重复编译竞争处理、无效pattern是否短时记忆，以及缓存命中率的统计方式。规则来自外部输入时，先做长度、字符集和总数量限制；缓存容量则应该有明确的配置上限，例如按租户设置256或1024条，而不是让它随业务数据无限增长。

压测验收要同时看命中率、编译次数和p99

只看平均耗时很容易产生误判。给编译路径加计数器，至少记录 pattern_cache_hit、pattern_cache_miss、pattern_compile_error，并把请求p50、p95、p99放在同一时间窗口里做对比。

• 固定规则接口：编译计数应只在启动阶段产生，稳定运行的请求期间不再新增。
• 高重复动态规则：命中率上升后，p99应随编译未命中次数减少逐步收敛。
• 低重复动态规则：缓存命中率低时，优先限制规则数量和输入大小，不要盲目扩大缓存容量。
• 异常规则：编译错误要快速返回，不能反复尝试同一条明显无效的pattern。

压测流量要混合三类输入：常用固定pattern、少量重复的动态pattern、几乎不重复的随机pattern。第三类流量专门检验缓存上限和淘汰动作是否正常生效。改动前后使用同一份输入分布，并在GC、CPU、内存分配和请求延迟维度上保留记录，这样才能判断优化是真的减少了重复编译，还是只是把成本转移到了其他地方。

几个容易把优化做反的边界

把所有规则都放进全局缓存

缓存适合有重复率、数量可控的规则集合。对于一次性pattern，缓存根本命中不了，反而额外增加锁、索引和淘汰的开销。

用正则代替简单前缀判断

如果需求只是判断 ORD- 前缀，strings.HasPrefix 更直接。正则不是越通用越好，先看业务条件能不能用普通字符串操作实现。

只用benchmark结果推断线上p99

benchmark能隔离单个函数的成本，不能代替网络、锁竞争、GC和真实输入分布的影响。最终还要在接口层验证，而且要同步记录规则命中率与输入长度分布。

相关问题

Go的regexp会出现灾难性回溯吗？

标准库regexp使用RE2风格语法，并保证匹配时间随输入长度线性增长，但长输入依然会增加耗时，所以仍需设置字段长度上限。

配置里的正则应该用MustCompile吗？

不建议直接使用。配置加载阶段应调用 regexp.Compile，把错误和对应的规则名称一起返回；只有源码中固定且必须有效的规则才适合用 MustCompile。

缓存需要做成LRU吗？

不一定。规则量小且可控时，简单的固定容量淘汰就够用；只有在命中率和访问分布证明需要更精细的保留策略时，才值得引入LRU实现。

收束：先预编译，再用数据决定缓存

固定规则的优化动作很明确：把 regexp.Compile 移出请求路径。动态规则则要把缓存容量、淘汰策略、输入限制和指标体系一起设计。先用benchmark分离编译与匹配的开销，再用真实流量看p99、编译次数和命中率，通常比直接增大缓存容量更快找到真正的瓶颈。