Go regexp.MatchString 怎样避免重复编译：MustCompile、并发复用与输入边界

很多校验代码把 regexp.MatchString(`^go-`, value) 直接写进循环里，功能没问题，压测时却会发现 CPU 花在“反复解析同一个模式”上。Go 的正则对象可以安全地被多个 goroutine 并发使用，真正需要判断的是：模式是否固定、编译错误是否可接受，以及输入是不是用户动态提供的。

规则很简单：固定模式在初始化阶段编译一次，运行时只调用 MatchString；固定且确定合法的模式可以用 regexp.MustCompile；动态模式必须保留 Compile 的错误，不要把用户输入直接交给 MustCompile。

最小可用写法：固定规则只编译一次

假设服务要判断资源名是否以 go- 开头，模式是代码的一部分，不会随请求改变。把它编译成一个长期复用的 *regexp.Regexp 即可：

package main

import (
    "fmt"
    "regexp"
)

var goName = regexp.MustCompile(`^go-[a-z0-9-]+$`)

func validName(s string) bool {
    return goName.MatchString(s)
}

func main() {
    fmt.Println(validName("go-parser")) // true
    fmt.Println(validName("go_parser")) // false
}

MustCompile 在模式非法时会 panic，所以它更像“把配置错误前移到启动阶段”的声明。这个选择适合编译期就能看见的常量；如果模式来自环境变量，启动失败是否可接受要由配置策略决定。

三种写法放在一起：重复编译、一次编译和动态编译

差异不在 MatchString 这个方法，而在它前面是否每次都创建了正则对象：

便捷函数 regexp.MatchString 适合“模式和输入都只用一次”的小工具。它内部仍要完成编译；如果一个请求要检查几千个值，应该先 Compile，再复用返回的对象。

旧写法的风险：把 Compile 放进循环

func bad(values []string) int {
    hit := 0
    for _, value := range values {
        ok, err := regexp.MatchString(`^go-[a-z0-9-]+$`, value)
        if err != nil {
            continue
        }
        if ok {
            hit++
        }
    }
    return hit
}

func good(values []string) (int, error) {
    re, err := regexp.Compile(`^go-[a-z0-9-]+$`)
    if err != nil {
        return 0, err
    }
    hit := 0
    for _, value := range values {
        if re.MatchString(value) {
            hit++
        }
    }
    return hit, nil
}

两段代码的结果相同，但第一段把固定模式的准备工作重复了很多次。这里别急着上缓存：模式如果本来就是固定字符串，最简单可靠的缓存就是一个包级正则变量。只有模式真正动态时，才需要考虑按模式做有上限的缓存，并处理恶意输入造成的模式数量膨胀。

动态模式要守住两道边界

例如搜索接口允许用户输入前缀，业务想把它拼成正则。第一道边界是语法错误，第二道边界是语义是否允许。只处理第一道边界还不够：

func prefixMatcher(prefix string) (*regexp.Regexp, error) {
    // QuoteMeta 防止前缀中的 .、+、[ 等字符改变正则含义。
    pattern := `^` + regexp.QuoteMeta(prefix)
    return regexp.Compile(pattern)
}

func matches(prefix, value string) (bool, error) {
    re, err := prefixMatcher(prefix)
    if err != nil {
        return false, err
    }
    return re.MatchString(value), nil
}

QuoteMeta 让“前缀”保持普通文本语义；如果产品本来就允许用户提交正则，则应在接口层限制长度、记录失败原因，并为模式数量和执行耗时设上限。不要用 MustCompile 掩盖这类输入问题。

并发复用怎么验证：共享正则，不共享可变状态

编译完成后，多个 goroutine 可以同时调用 MatchString、FindString 等匹配方法。典型的 HTTP 服务可以把对象放在 handler 外部：

var routeName = regexp.MustCompile(`^route/[a-z0-9-]+$`)

func checkRoutes(values []string) int {
    total := 0
    for _, v := range values {
        if routeName.MatchString(v) {
            total++
        }
    }
    return total
}

回归时用 go test -race ./... 检查周边代码。若你把统计计数、临时切片或缓存也挂在共享对象上，竞态来自那些可变数据，不是来自 *regexp.Regexp 的匹配调用。

输入验收：正则匹配的 true 还差什么

• 需要完整匹配时加 ^ 和 $，否则 abc-go-1 可能被部分命中。
• 明确是否允许换行；Go 的 $ 与多行模式组合时要单独写测试。
• 先做字节长度或业务长度限制，再编译动态模式。
• 把空字符串、超长字符串、非法 UTF-8 来源和特殊字符放进表驱动测试。
• 性能判断使用同一批输入跑基准，不要只凭一次请求的耗时下结论。

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

基准代码的目的，是把“编译一次、匹配多次”的真实路径固定下来。若要对比旧写法，另写一个基准函数，不要在同一个循环中混合两种策略。

迁移清单：从便捷函数改成可复用对象

1. 确认模式是否固定；固定模式移到初始化位置。
2. 固定常量使用 MustCompile，动态输入使用 Compile 并返回错误。
3. 批量输入只编译一次，再调用 MatchString。
4. 动态前缀、关键词等普通文本先调用 QuoteMeta。
5. 为完整匹配、空值、特殊字符、超长输入和并发调用补回归测试。

常见问题

regexp.Regexp 可以作为全局变量吗？

固定模式可以。编译后的正则匹配方法支持并发使用，全局复用能避免每次请求重新准备模式。

regexp.MatchString 和 re.MatchString 有什么区别？

前者接收模式字符串，适合一次性使用；后者复用已经编译的 *Regexp，适合批量匹配和热路径。

为什么不能把配置模式都写成 MustCompile？

配置和请求输入可能非法，MustCompile 会 panic。是否让服务启动失败要由配置加载阶段决定，不能把运行时输入错误交给 panic。

QuoteMeta 会让正则失效吗？

它会转义正则元字符，正是为了让输入按普通文本匹配。如果业务需要用户编写正则，就不能对整段模式调用它，而要改用单独的安全校验。

小结

Go 正则的性能边界通常很明确：固定模式编译一次，动态模式检查错误，批量输入复用同一个 *regexp.Regexp。先用模式来源决定 API，再用基准和边界测试确认结果，基本就能避免把一次性的便捷写法误放进热循环。