regexp.Compile 不能每次都调用，因为每次调用都会解析正则、构建状态机、做语法检查，是纯 CPU 密集型操作且无法复用；高并发下反复编译同一正则的性能损耗远超匹配本身。
为什么 regexp.Compile 不能每次都调用
因为每次调用 regexp.Compile 都会解析正则字符串、构建状态机、做语法检查——这是纯 CPU 密集型操作，且无法复用。在高并发或高频匹配场景下（比如 HTTP 中间件里校验请求路径），反复编译同一正则，性能损耗远超匹配本身。
常见错误现象：cpu profile 显示 regexp.compile 占比异常高，或者压测时 QPS 上不去但 CPU 利用率卡在单核瓶颈。
- 所有固定正则（如
^/api/v\d+/users/\d+$）必须提前用regexp.Compile编译一次，全局复用 - 若正则含运行时拼接（如用户输入的关键词），改用
regexp.CompilePOSIX要更谨慎——它不支持 \d、\s 等 Perl 语法，且错误提示更模糊 - 注意：编译失败会 panic 吗？不会，
regexp.Compile返回(*Regexp, error)，必须显式检查err，否则线上可能静默匹配空结果
如何安全地复用 *regexp.Regexp 实例
*regexp.Regexp 是完全线程安全的，可放心在 goroutine 间共享。但复用不等于“随便塞进 map 或结构体就完事”——容易踩的坑是生命周期管理混乱，导致本该复用的实例被重复编译，或过早 GC。
- 推荐方式：定义包级变量，用
var validEmail = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)——MustCompile在 init 阶段 panic，问题暴露早 - 避免在函数内声明
var re = regexp.MustCompile(...)：Go 不保证函数内包级常量初始化顺序，可能触发竞态或 panic 延迟 - 如果正则需动态构造（如租户定制规则），缓存到
sync.Map[string]*regexp.Regexp，但要加长度限制和 LRU 清理逻辑，否则内存泄漏
FindStringSubmatch 和 FindAllString 性能差在哪
表面看只是返回值类型不同，实际底层开销差异明显：FindStringSubmatch 返回 []string 会拷贝原始字节；而 FindAllString 返回切片时，若源字符串后续被修改，结果可能意外变化（因内部仍引用原底层数组）。更关键的是，带 Submatch 的方法默认捕获所有子表达式，即使你只用第 0 组，也多做了分组匹配计算。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只取完整匹配？用
FindString或MatchString，它们跳过子匹配逻辑，快 20%~40% - 需要捕获组但只用其中几个？显式写
re.FindStringSubmatchIndex+ 手动切片，避免分配无用[]string - 匹配大文本（>1MB）时，优先用
FindReaderIndex配合strings.Reader，减少内存拷贝
Go 1.22+ 的 regexp/syntax 调优信号
新版 regexp 包对回溯控制更严格，默认拒绝可能指数级爆炸的正则（如 (a+)+b），但错误信息仍是 error parsing regexp，不提示具体哪部分危险。这时得靠 regexp/syntax 手动解析 AST 做静态分析。
- 上线前跑一遍
regexp/syntax.Parse(pattern, syntax.Perl)+ast.CaptureCount()，超过 10 个捕获组就告警 - 避免嵌套量词：
(x+)+、(.*a){2,}这类写法在 Go 1.22+ 会被直接拒绝，老版本则可能卡死 - 如果必须支持用户自定义正则，用
syntax.Literal模式预检，禁用^ $ . * + ?等高危元字符
真正难的不是写对正则，是预判它在线上百万次匹配后会不会突然变慢——编译一次、复用到底、绕开子匹配、盯紧回溯，这四件事漏掉任何一环，都可能让服务在某个凌晨三点开始抖动。
