Go regexp 编译正则失败时怎么把错误交给配置层

配置驱动的正则表达式最容易在两个地方出问题：表达式来自文件或管理后台，语法却在服务启动后才被编译；配置热加载时，新规则失败了，旧规则是否还能继续使用也没有明确约定。处理这类输入时，优先调用 regexp.Compile，把返回的 error 包装成带配置键的领域错误，再由启动或刷新边界决定拒绝、回滚还是告警。MustCompile 只适合源码中已经固定、并且编译失败就代表程序无法启动的常量正则。

外部配置不要直接交给 MustCompile。先用 regexp.Compile 得到 *regexp.Regexp 和原始错误，再附上配置键名；热加载场景应在新规则完整编译后再替换旧规则。

为什么配置正则不能直接用 MustCompile

regexp.Compile(expr) 会解析表达式，成功时返回可复用的 *regexp.Regexp，失败时返回错误；regexp.MustCompile(expr) 则在解析失败时 panic。两者的差别不是“写法长短”，而是错误所有权不同：源码常量的错误属于开发阶段，配置文件的错误属于配置层，应该能被记录、拒绝或回滚。

例如，配置值为 ^[a-z]+( 时，原始错误会包含缺少右括号等线索。配置层应该保留这部分诊断信息，但不要把可能包含敏感业务规则的完整表达式直接打进公开日志。

在配置层保留键名并包装原始错误

最小实现是让加载函数同时接收键名和表达式。使用 %w 包装原始错误，调用方仍可通过 errors.Is 或 errors.As 继续判断；展示给运维人员的消息则补上配置路径，避免只有一串 regexp 解析文本。

package rules

import (
	"fmt"
	"regexp"
)

type PatternConfig struct {
	Key  string
	Expr string
}

type PatternError struct {
	Key string
	Err error
}

func (e *PatternError) Error() string {
	// 错误消息只暴露配置键和解析原因；完整表达式不直接写入公共日志。
	return fmt.Sprintf("配置 %q 的正则无效: %v", e.Key, e.Err)
}

func (e *PatternError) Unwrap() error { return e.Err }

func compilePattern(cfg PatternConfig) (*regexp.Regexp, error) {
	// 外部输入走 Compile，失败交给调用方决定拒绝、告警或回滚。
	re, err := regexp.Compile(cfg.Expr)
	if err != nil {
		return nil, &PatternError{Key: cfg.Key, Err: err}
	}
	return re, nil
}

这里的返回值设计很重要：失败时返回 nil 和包装后的错误，成功时才把编译结果交给规则对象。不要在错误分支里偷偷返回旧的 *Regexp，否则调用方很难区分“本次配置成功”还是“继续沿用旧规则”。

把编译结果放入规则对象，再决定是否替换

如果配置一次包含多条规则，建议先构造临时对象，逐条编译；只有整组成功，才把它替换为当前对象。这样热加载失败时，旧对象仍然完整可用，避免半组新规则和半组旧规则同时存在。

type CompiledRules struct {
	ByKey map[string]*regexp.Regexp
}

func compileAll(configs []PatternConfig) (*CompiledRules, error) {
	// 临时 map 只在整组规则成功后交给上层，避免部分替换。
	compiled := make(map[string]*regexp.Regexp, len(configs))
	for _, cfg := range configs {
		re, err := compilePattern(cfg)
		if err != nil {
			return nil, err
		}
		compiled[cfg.Key] = re
	}
	return &CompiledRules{ByKey: compiled}, nil
}

启动阶段可以把错误返回给主流程，让服务不启动；热加载阶段则通常记录配置键、拒绝本次刷新并继续使用旧对象。空表达式也要提前定策略：它可能是合法的“匹配空字符串”，也可能代表配置缺失，不能把业务含义交给 regexp 包猜。

上线前的配置错误检查清单

排查时先确认错误来自配置解析、正则编译还是规则替换；这三层的修复动作不同。Go 的 regexp 使用 RE2 风格语法，并保证匹配时间与输入规模线性相关，但这并不意味着任意业务表达式都正确，配置仍需要在进入运行时前完成语法和业务约束检查。

常见问题

配置正则编译失败时，应该让服务启动失败吗？

启动必须依赖该规则时应失败并明确指出配置键；如果规则可选，可以跳过该规则，但要有告警和可观测记录，不能静默忽略。

可以把 regexp.Compile 的错误直接返回给 API 吗？

内部错误可以保留在 error 链中，面向用户的 API 应返回稳定的错误码和配置字段名，避免暴露完整表达式或内部文件路径。

热加载失败后还能继续使用旧规则吗？

可以，前提是旧规则对象本身仍完整有效，并且替换动作是原子的。先编译临时对象、成功后再替换，是最容易审查的边界。