regexp.compile 编译失败会 panic 而非返回 error，应改用显式错误检查；matchstring 在回溯模式下可能指数级慢；findallstring 默认非重叠匹配；go 正则基于 re2 不支持 \k 等 pcre 特性。
regexp.Compile 报错 panic: regexp: Compile: error parsing regexp
正则表达式编译失败时，regexp.Compile 不会返回 nil，而是直接 panic —— 这和多数 Go 标准库函数「错误返回、不 panic」的习惯相反，容易在没做 recover 的服务中导致崩溃。
必须用 regexp.Compile 的孪生兄弟 regexp.CompilePOSIX 或更稳妥的 regexp.Compile + 显式错误检查：
-
regexp.Compile返回(*Regexp, error)，错误类型是*syntax.Error，包含Err（错误描述）、Expr（出问题的正则片段）、Pos（字符位置） - 常见触发点：未闭合的括号
(、未转义的[或{、重复量词连用如**、POSIX 字符类写成[:digit:]却没用[:digit:]包裹在[...]内 - 线上服务里别依赖 defer+recover 捕获这个 panic，应该在初始化阶段就校验所有硬编码正则，例如：
if _, err := regexp.Compile(`\d{2,}`); err != nil { log.Fatal("invalid regex:", err) }
regexp.MatchString 在大量文本中性能突然变慢
regexp.MatchString 看似轻量，但底层仍需构建 NFA/DFA，对长文本或复杂模式（尤其含回溯结构）可能指数级耗时。不是“匹配慢”，而是“最坏情况失控”。
典型高危模式包括：
立即学习“go语言免费学习笔记（深入）”；
- 嵌套量词：
a+b+遇到aaaaabbbbb一般快，但遇到aaaaaX（结尾不匹配）时会反复回溯 - 可选+重复组合：
(a|b)*c对aaaaaaaaa这种无c的输入，会穷举所有分割方式 - 使用
.*开头又带捕获组，如^(.*):(.*)$处理超长单行日志时极易卡住 - 替代方案优先级：能用
strings.Contains/strings.HasPrefix就不用正则；必须用正则时，用regexp.MustCompile预编译（只在 init 或包级变量中调用），避免运行时重复编译
regexp 匹配结果被截断或漏掉重叠内容
Regexp.FindAllString 和 FindStringSubmatch 默认非重叠扫描 —— 找到一个匹配后，从匹配结束位置继续往后找，不会倒退或滑动一个字符再试。这导致像 aaa 中查找 aa 只返回一个 aa，而非两个。
如果你需要重叠匹配（比如分词、n-gram 提取），得手动实现滑动窗口：
- 别用
FindAllString，改用FindIndex循环调用，每次start = start + 1而非start = match[1] - 注意边界：手动循环时要检查
start ，且每次传入 <code>text[start:]给FindIndex，否则索引错位 - 性能敏感场景慎用：纯手动滑动比内置方法慢一个数量级，10MB 文本上可能多花几百毫秒
Go 正则不支持 \K 或 (*SKIP) 等 PCRE 特性
很多从 PHP/Python 切过来的人习惯用 \K 丢弃前面已匹配内容，或用 (*SKIP)(*F) 实现条件排除，但 Go 的 regexp 包基于 RE2 引擎，明确禁用回溯和这些高级语法 —— 不是 bug，是设计选择。
实际应对方式很朴素：
- 想“匹配 A 但不要 B 前缀”，拆成两步：
rePrefix.FindStringIndex找前缀位置，再用reTarget.FindString在剩余子串里找目标 - 想“排除某模式”，用负向先行断言不行，就用两次匹配：先
MatchString确认不含黑名单模式，再用主正则提取 - 别试图用
ReplaceAllStringFunc替代逻辑判断，它只是字符串替换，无法表达“匹配但跳过”这种控制流
RE2 的安全性和确定性是以牺牲部分表达力换来的，接受这点比强行模拟 PCRE 更可靠。真正棘手的文本处理需求，往往该交给专用解析器，而不是塞进正则里硬扛。
