Go regexp 复用编译结果的初始化方案

在 Go 服务里反复调用正则匹配时，真正需要复用的是已经编译好的 *regexp.Regexp，而不是把同一个表达式字符串交给 regexp.Compile 很多次。固定模式可以在包初始化阶段使用 regexp.MustCompile；动态模式则应使用 regexp.Compile 接收错误，并只对经过约束的模式做缓存。

这篇只讨论三件事：固定表达式怎样初始化、动态表达式怎样返回错误、缓存怎样避免被任意输入撑大。Go 的 Regexp 文档说明它可以被多个 goroutine 并发使用，但配置类方法仍要单独管理。

官方资料：https://pkg.go.dev/regexp

Go 编码参考：https://go.dev/doc/effective_go

先判断表达式是不是固定的

初始化方案的分界线不是“这条正则会不会匹配很多次”，而是模式本身是否由程序控制。如果模式写在源码里，例如校验内部任务编号、提取固定格式的版本字符串，程序启动后它就不会变化，可以把编译结果作为包级资源。

如果模式来自配置文件、请求参数或租户规则，就属于动态模式。它可能语法错误，也可能产生大量不同的字符串。此时不能为了省掉错误处理而直接使用 MustCompile，也不能把每个输入都永久放进一个无上限的 map。

固定模式用 MustCompile 初始化

MustCompile 是 Compile 的便捷初始化形式：表达式无法解析时会 panic。因此它适合放在包级变量中，表达“这条模式是程序自身的一部分，写错就不应继续启动”。后续请求只调用已经存在的正则对象。

package matcher

import "regexp"

var (
	// 固定模式属于程序配置，初始化时只编译一次。
	jobIDPattern = regexp.MustCompile(`^job-[a-z0-9]{8}$`)
	// 共享的 Regexp 只执行匹配，不在请求中修改配置。
	versionPattern = regexp.MustCompile(`^v([0-9]+)\.([0-9]+)(?:\.([0-9]+))?$`)
)

func IsJobID(value string) bool {
	// 调用方只传入待匹配文本，不重复编译固定表达式。
	return jobIDPattern.MatchString(value)
}

func VersionParts(value string) []string {
	// 没有匹配时返回 nil，避免把空结果误当成版本号。
	return versionPattern.FindStringSubmatch(value)
}

这里的要点有两个。第一，MustCompile 的 panic 语义只对程序自有表达式合理；第二，*regexp.Regexp 的复用不等于复用可变状态，代码不要在请求路径上调用会改变匹配配置的方法。

动态模式用 Compile 处理错误

动态模式的第一责任是把解析错误变成普通错误。调用方可以把它转换成配置加载失败、请求参数错误或规则拒绝，而不是让一次输入直接让进程 panic。

package matcher

import (
	"fmt"
	"regexp"
)

func CompileRule(pattern string) (*regexp.Regexp, error) {
	// 动态模式来自配置或外部输入，必须保留解析错误。
	if pattern == "" {
		return nil, fmt.Errorf("正则表达式不能为空")
	}
	re, err := regexp.Compile(pattern)
	if err != nil {
		// 用 %w 保留底层解析错误，调用方仍可继续判断。
		return nil, fmt.Errorf("编译正则表达式失败: %w", err)
	}
	return re, nil
}

这里的动态模式不应只做语法判断。还要根据业务限制长度、允许的字符或规则数量，并把拒绝原因记录到配置审计中。若只是少数产品选项，更简单的做法是预先编译白名单，而不是搭建通用缓存。

动态缓存要限制键和值

缓存的性能收益来自“相同模式再次出现时复用编译对象”，风险则来自“每个新字符串都变成一个长期对象”。因此缓存键不能只是一段未经约束的请求文本。可以先把输入映射到有限的规则名，再从规则名取得模式；如果业务必须接受动态模式，也至少要设置长度、数量和淘汰策略。

package matcher

import (
	"fmt"
	"regexp"
	"sync"
)

var rulePatterns = map[string]string{
	// 只开放业务需要的规则名，不让请求直接控制缓存键空间。
	"user-name": `^[a-z][a-z0-9_]{2,31}$`,
	"ticket-id": `^T-[0-9]{10}$`,
}

var (
	// 白名单模式在初始化阶段复用编译结果。
	compiledRules = make(map[string]*regexp.Regexp, len(rulePatterns))
	compiledOnce  sync.Once
)

func rule(name string) (*regexp.Regexp, error) {
	pattern, ok := rulePatterns[name]
	if !ok {
		return nil, fmt.Errorf("未知规则: %s", name)
	}
	compiledOnce.Do(func() {
		for key, expression := range rulePatterns {
			// 规则表是源码常量，编译失败应暴露为初始化错误。
			compiledRules[key] = regexp.MustCompile(expression)
		}
	})
	return compiledRules[name], nil
}

这个版本把缓存键收敛成两个固定值，容量天然有上限。如果产品确实允许用户提交任意表达式，缓存就不能只用一个全局 map；应采用有界 LRU、按租户隔离的容量或定期清理，并把超长模式和超出配额的输入在编译前拒绝。

并发复用时把锁留给缓存

官方文档说明，Regexp 可以被多个 goroutine 并发使用。通常需要同步的是缓存容器，而不是每一次 MatchString。把读写锁长期包住匹配调用，会把正则本身的复用优势变成不必要的串行等待。

如果使用可变缓存，建议采用“锁内查找、锁外匹配”的职责划分：锁只保护键到编译对象的关系，拿到指针后再执行匹配。缓存的淘汰动作也应在锁内完成，并明确谁负责限制容量、谁负责记录命中或拒绝原因。

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

func (c *PatternCache) Get(name string) (*regexp.Regexp, bool) {
	// 只在读取 map 时加读锁，返回后的匹配不占用缓存锁。
	c.mu.RLock()
	re, ok := c.items[name]
	c.mu.RUnlock()
	return re, ok
}

这段代码只展示缓存访问边界，初始化和淘汰策略仍应由调用方补齐。不要把它误解为一个完整的无限容量缓存；一旦键空间来自用户，必须再加配额、淘汰和审计记录。

一张速查表：该选哪种初始化方式

最终判断可以归纳为一句话：固定表达式让初始化负责失败，动态表达式让调用方负责错误，缓存只负责复用已经允许存在的结果。这样既能减少重复编译，也不会把输入校验、容量控制和并发同步混在一个全局变量里。

相关问题

• MustCompile 适合放在 init 函数里吗？可以，但包级变量通常更直观；只要表达式属于程序自身，初始化阶段失败是可接受的。
• Regexp 需要每个 goroutine 一份吗？一般不需要，官方文档允许并发使用；只有需要不同配置时才考虑独立对象。
• 动态表达式能不能直接用 sync.Map 缓存？容器并发安全不等于容量安全，仍要限制模式来源、长度、数量和淘汰周期。