Go regexp.Compile 和 MustCompile 怎样选择

我在把用户可配置的筛选条件接入 Go 服务时，最容易犯的错不是正则语法写错，而是把 regexp.MustCompile 当成了 regexp.Compile 的“更简短版本”。两者都能得到 *regexp.Regexp，但失败时的处理契约完全不同：前者返回错误，后者会直接触发 panic。

官方地址：https://pkg.go.dev/regexp

固定在源码里的常量表达式可以考虑 MustCompile，因为错误应在程序初始化阶段暴露；来自配置、请求、数据库或插件的表达式应使用 Compile，把错误交给当前业务边界处理。不要用 MustCompile 代替输入校验。

先把保护对象和输入边界分开

正则表达式本身不是可信度的来源。真正需要保护的是服务进程的可用性、请求处理链路和配置加载过程。一个包级变量里的固定表达式，失败意味着程序员把错误提交进了代码；一个 HTTP 参数里的表达式，失败则只是当前请求或配置不符合约定。

因此可以先问三个问题：表达式是谁写入的、什么时候第一次编译、编译失败后是否还有机会给调用方一个可处理的错误。答案分别是“开发者、启动前、没有”时，MustCompile 的 panic 具有明确的故障边界；只要输入来自外部或可变配置，默认就应该保留 Compile 的 error。

Compile 和 MustCompile 的差别不在匹配能力

两者最终都依赖同一套正则编译逻辑，成功后得到的 *Regexp 用法没有本质区别。差别集中在编译失败时：Compile 返回 (*Regexp, error)，调用方可以附加字段名、配置来源或请求信息；MustCompile 在解析失败时 panic，适合简化安全初始化。

“安全初始化”这里有一个容易忽略的限定：安全指表达式来源固定、错误属于开发缺陷，而不是说任意正则都可以放心 panic。Go 官方文档对 MustCompile 的说明也把重点放在初始化全局变量上。把这个范围扩大到用户输入，会把一个可返回的 400 或配置错误升级为进程级异常。

package main

import (
	"fmt"
	"regexp"
)

// 固定表达式属于源码的一部分，写错应在初始化阶段暴露。
var requestIDPattern = regexp.MustCompile(`^req-[0-9a-f]{8}$`)

func compileUserPattern(raw string) (*regexp.Regexp, error) {
	// 外部输入必须把解析错误留给调用方，不能让请求触发 panic。
	return regexp.Compile(raw)
}

func main() {
	// 固定表达式只验证程序内部约定的请求 ID。
	fmt.Println(requestIDPattern.MatchString("req-1a2b3c4d"))

	// 可变表达式失败时保留可读的错误分支。
	if _, err := compileUserPattern("["); err != nil {
		fmt.Println("invalid user pattern:", err)
	}
}

这段代码把两条路径并列放在一起：包级常量使用 MustCompile，调用时不需要重复判断；可变表达式使用 Compile，错误可以被 HTTP 层转成参数错误，也可以被配置加载器附加文件名后返回。

哪些场景适合直接让启动失败

我更愿意把 MustCompile 限定在三个条件同时成立的地方：表达式由仓库代码固定提供、它在启动或包初始化时就能被发现、程序没有合理的运行时降级方案。路由约束、固定格式的内部 ID、代码生成器输出的常量模式，通常满足这个边界。

启动阶段 panic 的价值是让错误靠近源头。比起服务启动后才发现某个请求永远匹配不到，初始化时立刻暴露表达式问题更容易回滚和修复。不过如果服务需要持续接收配置热更新，就不应在热更新函数里调用 MustCompile；新配置失败时应保留旧的有效正则，并把错误写入审计日志。

哪些输入必须保留 Compile 的错误

来自查询参数、表单、配置中心、数据库字段、租户规则和插件元数据的表达式，都应该先 Compile，再决定拒绝、降级或保留旧值。这里的关键不是“用户一定恶意”，而是输入的正确性不由当前代码完全控制。

在 HTTP 服务中，推荐把错误包装到参数名和请求上下文里，但不要把原始表达式直接回显给前端；在配置加载中，可以返回带文件路径和字段名的错误；在热更新中，可以先编译临时对象，成功后再替换共享引用。这样即使表达式损坏，也不会把已经运行的规则一起清空。

package main

import (
	"fmt"
	"regexp"
)

type PatternConfig struct {
	Rule string
}

func loadPattern(cfg PatternConfig) (*regexp.Regexp, error) {
	// 先编译临时结果，成功后才允许上层替换旧规则。
	re, err := regexp.Compile(cfg.Rule)
	if err != nil {
		return nil, fmt.Errorf("compile rule: %w", err)
	}
	return re, nil
}

func acceptConfig(cfg PatternConfig, current *regexp.Regexp) (*regexp.Regexp, error) {
	// 新规则失败时保留旧规则，避免热更新把服务置于无规则状态。
	next, err := loadPattern(cfg)
	if err != nil {
		return current, err
	}
	return next, nil
}

这个边界的重点是“先编译、后替换”。不要先把旧指针置空，再尝试编译新表达式；也不要为了少写一个 error 分支而让配置中心的内容触发 panic。若业务要求失败后停止启动，可以由最外层启动器显式返回错误，而不是让任意输入在深层函数里制造不可区分的异常。

把失败路径写成可审计的决策

安全威胁建模最有用的地方，是把“是否会 panic”改写成可检查的决策。记录表达式来源、编译时机、失败动作和审计字段，后续看到一处 MustCompile 时就能判断它是否越过了输入边界。

日志也要有边界：记录足以定位问题的来源和错误类型即可，不要为了排障把可能含有隐私的完整规则、令牌或用户数据写入普通业务日志。正则的复杂度、输入长度和调用频率仍是独立的资源控制问题，不能靠选择 Compile 或 MustCompile 解决。

我的选择结论

如果表达式是包级固定常量，我会选择 MustCompile，让错误在部署或测试阶段尽快暴露；如果表达式来自任何运行时输入，我会选择 Compile，并由当前边界决定返回参数错误、拒绝配置还是保留旧规则。两者不是性能开关，也不是“一个安全、一个不安全”的简单二选一，而是两种不同的故障责任分配。

最后再检查一遍：固定规则是否真的不会由环境替换？失败时是否需要给调用方上下文？热更新是否先编译后切换？审计日志是否避免保存敏感原文？这四个问题比机械搜索项目里的 MustCompile 数量更能判断使用是否合理。

Compile 成功后得到的 Regexp 可以并发使用吗？

匹配和查找类方法可以被多个 goroutine 并发调用；不要在并发使用期间调用会修改对象状态的方法，例如改变最长匹配偏好的操作。

配置里的正则编译失败要不要让服务退出？

启动时的关键配置可以拒绝启动，但应由启动层统一处理错误；热更新通常保留旧规则并告警，避免一次坏配置让现有请求全部失去规则。

MustCompile 会比 Compile 匹配更快吗？

两者成功后都返回已编译的 Regexp，主要差异是错误处理方式。不要用 MustCompile 作为未经测量的性能优化。