Go regexp 怎样避免重复编译表达式

如果正则表达式是固定配置，最直接的做法是把 regexp.Compile 或 regexp.MustCompile 放到初始化阶段，只保留一个可复用的 *regexp.Regexp。请求处理函数只负责调用 MatchString、FindString 等匹配方法；不要每次请求都重新解析同一段表达式。

Go regexp 官方文档：https://pkg.go.dev/regexp

固定表达式编译一次、并发读取多次；只有表达式本身动态变化时，才需要设计带容量和淘汰边界的缓存。

先区分重复编译和重复匹配

regexp.Compile 做的不只是保存字符串，它会把表达式解析成后续匹配需要的数据结构。业务代码如果在一个循环或 HTTP handler 中反复调用它，就把“准备规则”的成本放进了每次请求。真正应该重复的是对输入文本的匹配，而不是对同一规则的编译。

可以先看表达式从哪里来：写死在代码中的邮箱、请求 ID、日志字段规则通常是固定配置；配置文件启动时加载的规则也往往可以在初始化阶段完成编译。相反，用户提交的搜索语句或租户自定义规则属于动态输入，不能简单套用一个全局变量。

在初始化阶段编译固定表达式

固定规则可以用包级变量初始化。表达式是程序内置常量、写错就应该让构建或启动尽快暴露时，MustCompile 很直观；表达式来自配置文件、需要把错误展示给运维或调用方时，使用带错误返回的 Compile 更合适。

package matcher

import "regexp"

// 固定规则只在包初始化阶段编译一次，后续请求只读取这个对象。
var requestID = regexp.MustCompile(`^[a-zA-Z0-9_-]{8,64}$`)

// IsRequestID 只做匹配，不修改 requestID 的配置状态。
func IsRequestID(value string) bool {
	return requestID.MatchString(value)
}

如果想把配置错误作为启动错误返回，可以把编译放进初始化函数：

package matcher

import "regexp"

// CompileFixed 将配置错误留给启动流程处理，而不是在请求期间 panic。
func CompileFixed(expr string) (*regexp.Regexp, error) {
	// 返回原始错误，调用方可以在启动日志中记录具体表达式来源。
	return regexp.Compile(expr)
}

这里的关键不是“必须使用全局变量”，而是让编译结果的生命周期覆盖需要它的工作范围。也可以把 *regexp.Regexp 放进服务结构体，在构造服务时完成编译，再把结构体交给处理器。

在并发读取路径共享 Regexp

固定表达式的复用通常意味着多个 goroutine 会同时调用它。Go 的 Regexp 提供的匹配方法适合并发使用；但配置动作和匹配动作应该分开。比如 Longest 会改变 Regexp 的匹配选择配置，应在对象交给并发请求之前完成，而不要在每个请求里切换。

package matcher

import "regexp"

type Service struct {
	// ready 表示对象已经完成所有初始化配置，可以被并发读取。
	ready *regexp.Regexp
}

// NewService 在构造阶段完成编译和策略设置。
func NewService(expr string) (*Service, error) {
	re, err := regexp.Compile(expr)
	if err != nil {
		// 动态配置不合法时，阻止一个未准备好的服务被启动。
		return nil, err
	}
	// 这里只在没有并发读者时设置策略，之后只调用匹配方法。
	re.Longest()
	return &Service{ready: re}, nil
}

// Match 在请求路径中只读取已配置好的 Regexp。
func (s *Service) Match(input string) bool {
	return s.ready.MatchString(input)
}

如果既需要默认的“最左最先”，又需要另一套“最左最长”规则，就构造两个独立对象。不要让请求代码在同一个对象上来回修改策略，也不要把 Regexp.Copy 当作解决初始化竞态的替代方案。

为动态表达式建立有限缓存

动态表达式不能全部变成包级变量，但也不代表只能每次都重新编译。一个更稳妥的边界是：先限制表达式长度，再用键为表达式文本的缓存复用已编译对象，并明确缓存容量。下面的示例展示核心关系，淘汰策略使用 FIFO；生产代码还应根据业务决定是否需要按租户隔离。

package matcher

import (
	"container/list"
	"fmt"
	"regexp"
	"sync"
)

type entry struct {
	expr string
	re   *regexp.Regexp
}

type Cache struct {
	mu    sync.Mutex
	limit int
	items map[string]*list.Element
	order *list.List
}

// NewCache 创建有容量上限的缓存，避免动态规则无限增长。
func NewCache(limit int) (*Cache, error) {
	if limit  256 {
		return nil, fmt.Errorf("表达式长度不在允许范围内")
	}

	c.mu.Lock()
	defer c.mu.Unlock()
	if elem, ok := c.items[expr]; ok {
		return elem.Value.(entry).re, nil
	}
	re, err := regexp.Compile(expr)
	if err != nil {
		return nil, err
	}
	elem := c.order.PushBack(entry{expr: expr, re: re})
	c.items[expr] = elem
	if c.order.Len() > c.limit {
		oldest := c.order.Front()
		delete(c.items, oldest.Value.(entry).expr)
		c.order.Remove(oldest)
	}
	return re, nil
}

这个示例把编译放在互斥锁内，目的不是证明所有场景都该使用长时间持锁，而是避免两个并发请求在缓存未命中时同时编译同一表达式。若编译时间和缓存规模都很大，可以进一步做“加载中”状态或按键分段锁，但必须先用实际命中率和等待时间说明复杂度值得。

用基准和边界检查缓存是否值得

固定表达式通常不需要复杂缓存；动态规则则要观察自己的输入分布。建议至少记录缓存命中次数、未命中次数、编译错误次数和当前条目数。命中率很低时，缓存只是在增加锁和淘汰逻辑，未必比直接编译更好。

基准测试应把两种工作拆开：一种是每次调用 regexp.Compile 后立即匹配，另一种是在基准开始前编译一次、循环中只匹配。不要把日志输出放进计时区，也不要拿一次本地运行的绝对纳秒数当成所有机器的结论。

func BenchmarkReuse(b *testing.B) {
	re := regexp.MustCompile(`^user-[0-9]+$`)
	b.ResetTimer()
	for i := 0; i 

边界检查也很重要：规则来源是否可信、是否需要按租户隔离、是否允许缓存负结果、表达式过长时如何拒绝、配置更新时如何替换服务实例。缓存解决的是重复工作，不会自动解决规则权限、内存上限和配置热更新的一致性。

几个容易混淆的判断

每次匹配都要重新 Compile 吗？

不需要。表达式固定时，在初始化阶段编译并共享 *regexp.Regexp；只有表达式动态变化时，才考虑缓存或按请求编译。

并发调用 MatchString 需要自己加锁吗？

只读匹配通常可以直接共享已经配置好的对象。需要加锁的是你自己维护的缓存 map，或者会改变对象配置的操作，不是为了把每一次只读匹配都包进一把全局锁。

MustCompile 什么时候不合适？

当表达式来自文件、环境变量、数据库或用户输入时，不应把错误变成进程 panic。使用 Compile 返回错误，并在启动或请求边界明确处理。

缓存容量应该设多大？

没有通用数字。先按表达式数量、命中率、内存预算和租户隔离要求设上限，再用指标调整；没有淘汰边界的动态缓存不适合作为长期服务状态。

归纳起来，Go regexp 的复用策略可以按输入来源分层：固定规则在初始化阶段编译一次，动态规则只在有明确命中收益时进入有限缓存，所有共享对象在配置完成后再交给并发读取。这样优化的重点不是把每段代码都改成全局变量，而是让编译、匹配和缓存三个生命周期彼此清楚。