Go regexp.Longest 并发使用 Longest 配置时如何安排初始化

很多人在Go项目里用regexp标准库做正则匹配开发的时候，碰到高并发场景下复用开启了Longest配置的正则实例，经常搞不清楚初始化的正确安排方式，要么平白多做很多重复编译拖慢性能，要么触发预期之外的匹配结果异常，实际只要在程序启动阶段提前完成所有开启Longest属性的正则编译，后续直接跨goroutine复用生成好的*regexp.Regexp实例就可以正常使用，完全不需要给每个请求单独编译实例，也不用额外加锁做特殊保护。

如果一个服务把同一个 *regexp.Regexp 交给多个 goroutine 使用，匹配阶段通常不需要加锁；但 Regexp.Longest() 是例外。它会修改正则实例的匹配策略，不能和匹配方法并发调用。稳妥的安排是：启动阶段完成编译和 Longest 配置，请求处理阶段只读共享实例；如果业务同时需要两种策略，就准备两个独立实例。

Longest 改变的是实例配置，不是一次匹配参数

Go 的 regexp.Compile 默认采用 leftmost-first：从最早的起点开始，在候选中沿着常规回溯搜索会优先得到的结果选择匹配。调用 Longest 后，后续搜索会偏向同一起点下更长的匹配。这个选择保存在 Regexp 实例里，因此不能把它当成一个只影响当前调用的选项。

官方文档同时给出两个关键边界：Regexp 可以被多个 goroutine 并发使用，但配置方法（包括 Longest）不在这个保证范围内；Longest 也不能与其他方法并发调用。问题不在于“正则匹配天生不支持并发”，而在于读操作和改变匹配策略混在了一起。

把 Compile 和 Longest 固定在启动阶段

可以用构造函数集中完成策略选择。构造函数返回前，正则已经完成编译和配置；后面的业务代码不再调用 Longest。

package matcher

import "regexp"

// newLongestMatcher 在启动阶段完成编译和匹配策略配置。
// 返回后只允许调用匹配方法，避免请求路径修改共享状态。
func newLongestMatcher() (*regexp.Regexp, error) {
	// Compile 保留错误，生产服务可以决定是否降级或终止启动。
	re, err := regexp.Compile(`go(?:lang)?-[a-z]+`)
	if err != nil {
		return nil, err
	}
	// Longest 修改实例配置，因此必须在交给并发调用者之前完成。
	re.Longest()
	return re, nil
}

如果表达式是程序内固定且写错就不应该启动，可以使用 regexp.MustCompile，再在初始化函数中调用 Longest。如果表达式来自配置文件，则更适合显式返回错误，让启动检查暴露配置问题。

并发阶段只读共享 Regexp

初始化得到的实例可以放在服务对象中，由多个请求处理函数调用。关键是不要在 handler、worker 或定时任务中再次切换策略。

type Matcher struct {
	re *regexp.Regexp
}

// Match 在并发请求中只执行匹配读取，不改变 re 的配置。
func (m *Matcher) Match(text string) bool {
	// MatchString 使用构造阶段已经固定的 leftmost-longest 策略。
	return m.re.MatchString(text)
}

因此，下面这种写法不安全：

func (m *Matcher) MatchLongest(text string) bool {
	// 错误示例：请求之间共享 m.re，却在匹配前修改策略。
	m.re.Longest()
	return m.re.MatchString(text)
}

即使某次测试没有触发明显错误，也不能把它当作安全依据。并发访问改变的是共享实例状态，结果可能取决于调用交错顺序。

两种策略并存时如何选择实例

如果同一个表达式既要普通匹配，又要 leftmost-longest 匹配，不要让两个调用方轮流改同一对象。最简单的方案是编译两次；也可以先复制，再分别设置。官方文档说明，Copy 已不再是为了并发性能而需要，但仍适合保留不同的 Longest 设置。

func buildMatchers(expr string) (normal, longest *regexp.Regexp, err error) {
	// 先构造默认策略实例，并保留表达式错误。
	normal, err = regexp.Compile(expr)
	if err != nil {
		return nil, nil, err
	}
	// Copy 只为隔离配置，不是用来掩盖请求路径上的共享写入。
	longest = normal.Copy()
	longest.Longest()
	return normal, longest, nil
}

在现代 Go 代码里，若两种策略都需要长期存在，分别 Compile 也更直观；使用 Copy 时要在初始化阶段立即完成配置，并把两个返回值当作不同策略的只读对象。

用边界输入验证初始化安排

测试重点不是给 Longest 加锁，而是验证所有实例在并发开始前已经配置完成，并且请求代码不会再写配置。准备一个能区分“短匹配”和“长匹配”的输入，分别断言普通实例与 Longest 实例的结果；再让多个 goroutine 只调用匹配方法，配合 go test -race 检查共享使用。

排查时可以按这个顺序判断：第一，确认 Longest 是否只出现在构造或初始化代码；第二，确认是否把同一个指针同时交给两种策略；第三，确认测试输入确实存在多个同起点候选。若只检查最终是否匹配成功，很容易漏掉“结果长度不同”的策略错误。

常见问题

Longest 调用一次后，后续所有 goroutine 都会使用长匹配吗？

会，前提是它们共享同一个已经配置完成的实例，并且之后不再修改该实例。也正因为配置是实例级状态，应该在并发使用前完成。

给每个 goroutine 调用 Copy 就一定更好吗？

不一定。普通并发匹配不需要靠 Copy 避免锁竞争；只有当调用方需要不同的 Longest 配置时，独立副本才有明确意义。

参考：Go regexp 包文档与标准库源码中的 Regexp 并发使用说明。