Go 怎样缓存正则编译结果

如果一个接口每次请求都拿同一条规则调用 regexp.Compile，问题通常不在“正则匹配太慢”，而在“编译被重复做了”。更合适的做法是把编译结果缓存成 *regexp.Regexp：固定规则在包初始化阶段编译一次，动态规则按 pattern 复用，并为缓存设置清晰的输入边界。

固定规则用 regexp.MustCompile；动态规则用受锁保护的 map 缓存。*regexp.Regexp 可以被多个 goroutine 并发匹配，但不能把无限变化的用户输入无条件放进全局 map。

本文从一个常见的重复编译现象开始，依次判断规则类型、选择缓存方式，再处理非法表达式和高基数 key。

为什么不要在热路径重复 Compile

先看调用关系：规则文本经过 regexp.Compile 才得到可执行的 Regexp 对象；真正的业务匹配只需要调用这个对象的方法。若规则固定，把两件事放进每次请求的函数里，就会让“构建对象”和“使用对象”绑定在一起。

Go 官方文档将 Regexp 定义为已编译的正则表示，并说明它可以被多个 goroutine 并发使用，配置方法除外。因此固定规则最先排查的不是加锁，而是能不能把编译移出请求路径。

固定规则：包级 MustCompile 最直接

邮件地址、内部编号或日志字段这类规则通常由代码决定，启动时就知道。可以把编译结果声明为包级变量：

package matcher

import "regexp"

// userIDPattern 只在包初始化时编译一次，后续请求共享同一个只读对象。
var userIDPattern = regexp.MustCompile(`^usr_[a-z0-9]{8}$`)

// IsUserID 只负责匹配，不在热路径重新解析规则。
func IsUserID(value string) bool {
	return userIDPattern.MatchString(value)
}

MustCompile 在规则写错时会 panic，适合“规则属于程序，错误属于发布配置”的场景。若规则来自配置文件、环境变量或管理员输入，就不要用它掩盖错误，应改用 Compile 把错误返回给调用方。

动态规则：按 pattern 缓存编译结果

动态规则的 key 是 pattern 本身。读缓存时可以先使用读锁，未命中后再拿写锁，并再次检查一次，避免多个 goroutine 同时编译同一个规则。下面的实现保留了错误返回，也没有把非法 pattern 写进缓存。

package regexpcache

import (
	"regexp"
	"sync"
)

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

// New 创建空缓存；调用方应复用同一个 Cache，而不是每次请求新建。
func New() *Cache {
	return &Cache{items: make(map[string]*regexp.Regexp)}
}

// Get 编译并缓存合法 pattern；错误规则只返回错误，不进入缓存。
func (c *Cache) Get(pattern string) (*regexp.Regexp, error) {
	c.mu.RLock()
	re, ok := c.items[pattern]
	c.mu.RUnlock()
	if ok {
		return re, nil
	}

	compiled, err := regexp.Compile(pattern)
	if err != nil {
		return nil, err
	}

	// 写锁内再次检查，避免并发未命中时覆盖已经生成的对象。
	c.mu.Lock()
	if existing, ok := c.items[pattern]; ok {
		c.mu.Unlock()
		return existing, nil
	}
	c.items[pattern] = compiled
	c.mu.Unlock()
	return compiled, nil
}

这里的二次检查让并发行为更稳定，但它不等于“同一时刻绝不会有两次编译”：两个调用可能都在写锁前完成编译，最终只保留一个对象。如果编译代价很高且同一 key 的并发 miss 很集中，可以再设计按 key 合并请求；不要为了追求绝对唯一而把整个匹配路径锁住。

复查三个缓存边界

第一，确认 pattern 的数量是有界的。若 key 直接来自用户输入，缓存可能持续增长，应在业务层限制规则来源、数量或生命周期，必要时使用带淘汰策略的缓存实现。

第二，确认规则失败如何反馈。固定规则可以在启动时快速失败；动态规则要区分语法错误与业务输入错误，不能把错误的 pattern 当成空匹配。

第三，确认缓存对象被正确复用。Regexp 适合并发匹配，sync.Once 适合只初始化一次的固定构建；不要把每次请求的新 sync.Once 或新 map 当成缓存。

常见问题

缓存了 Regexp 后还需要每次加锁吗？

匹配本身不需要为每个调用加业务锁；官方文档允许多个 goroutine 并发使用。只有缓存容器的读写需要同步，配置类操作要单独评估。

为什么不直接用 regexp.MatchString？

它适合一次性的简单匹配，但当同一规则被反复使用时，显式保存编译结果能把规则生命周期和缓存边界写清楚。

总结

Go 缓存正则编译结果的核心是区分“固定规则”和“动态规则”：前者把 Compile 移到初始化阶段，后者以 pattern 为 key 复用 *regexp.Regexp，同时用锁保护 map、返回编译错误，并限制 key 的增长。先消除重复编译，再根据真实的 key 数量决定是否需要更复杂的淘汰或请求合并。