什么时候该换引擎

判据：先看这条正则是不是「跨语言共用」。是，就只用四列全 ✓ 的交集写法；不是，就大方用本语言最顺手的特性，别为了假想中的可移植性把正则写得又长又怪。

编译期报错反查

编译过了，但结果不对

预定义简写：同一个 \w，四种答案

这张表解释了一类真实事故：同一条「用户名只能是字母数字」的校验，Python 后端放行中文、JS 前端拦下中文。跨端共用的正则必须把字符集写死，别依赖 \w。

点号的边界（实测）

• JS /a.b/ 对 "a\nb" 为 false，加 s 标志后为 true；
• 所以拿 .* 去抓「整段内容」在多行文本上会静默少抓——症状是「本地测试通过，线上少了一半数据」；
• C++ std::regex 没有 dotAll，. 永远不含换行，这条没有开关可开。

否定类会吃掉换行（实测）

JS:     /"[^"]*"/.test('"a\nb"')   →  true
Python: re.search('"[^"]*"', '"a\nb"')  →  命中，且跨了行

• [^"] 的字面意思是「除了引号之外的任意字符」，换行也在其中；
• 抓「一行里引号内的内容」时这会一路吞到下一行的引号，把两条记录粘成一条。要限制在本行必须写 [^"\n]*；
• 同类问题也出现在 [^>]* 抓 HTML 属性、[^,]* 抓 CSV 字段上——凡是「按行」的语义，都要把 \n 一并排除。

同一个 \w，四门语言四种答案（实测）

• Python 的「认」是默认行为，加 re.ASCII 才退回 ASCII（实测 re.findall(r"\w+", "你好 abc") 得 ['你好', 'abc']，加 re.ASCII 后只剩 ['abc']）；
• JS 的 \p{Han} 简写不存在——实测直接 SyntaxError: Invalid property name，必须写全 \p{Script=Han}；
• 这张表解释了一类真实事故：同一条「用户名只能是字母数字」的校验正则，Python 后端放行中文、JS 前端拦下中文，两边行为不一致。跨端共用正则时必须显式写死字符集，别依赖 \w。

抓多了 / 抓少了：改写配方

经验法则：能用「排除法」描述边界，就别用懒惰量词。否定字符类每一步都是确定的，懒惰量词要一步步试探回溯。

「量词只管紧前面那一个」的三个后果

• ab+ 是「a 后面跟一个或多个 b」，不是「ab 重复」——要后者必须写 (?:ab)+；
• \d{3}-\d{4} 里两个 {n} 各管各的 \d，这是对的；但 \d-\d{3} 里 {3} 只作用于第二个 \d，不是「整个 \d-\d 重复三次」；
• 量词后面直接跟量词（如 a**）大多数引擎会报错，但 a*+ 在支持独占量词的引擎里是合法的「独占」语义——实测 JS 报 Nothing to repeat，Python 3.11+ 则正常匹配。同一串在两门语言里一个报错一个静默改变语义，这是移植时的隐蔽坑。

比懒惰更该先想到的是否定字符类

• 抓引号内容时，"[^"]*" 比 ".*?" 又快又准：前者每一步都是确定的，后者要一步步试探回溯；
• 更重要的是语义：".*?" 在 "a" 和 "b" 这种输入上仍会正确停在第一个引号，但把 . 换成能跨行之后行为就变了；而 [^"\n]* 的边界是写死的，读代码的人一眼能确认；
• 经验法则：能用「排除法」描述边界，就别用懒惰量词。

$ 吃末尾换行：一条真实的校验漏洞

Python:  re.match(r"^\d+$",  "123\n")   →  匹配   ← 换行被放行了
Python:  re.match(r"^\d+\Z", "123\n")   →  不匹配
Go:      ^\d+\z  与  ^\d+$  对 "123\n"  →  都不匹配
JS:      /^\d+$/.test("123\n")          →  false

• Python（与 PCRE / Perl）的 $ 在非多行下也匹配「末尾换行之前」的位置——这是从 Perl 继承来的历史行为；
• 后果很实际：用 ^\d+$ 做「只允许数字」的校验，攻击者在末尾加一个换行就能带进额外字节，后续按行处理时可能被拆成两条记录；
• Python 侧的正解是 \Z（3.14+ 也可用 \z），Go 用 \z。 JS 与 C++ 的 $ 本来就是绝对末尾，没有这个坑。

$ 的行尾语义：一个真实的校验绕过（实测）

Python:  re.match(r"^\d+$",  "123\n")  →  匹配成功
Python:  re.match(r"^\d+\Z", "123\n")  →  不匹配
Python:  re.match(r"^\d+\z", "123\n")  →  不匹配（3.14 起可用）
JS:      /^\d+$/.test("123\n")         →  false

• Python / PCRE 的 $ 在无多行模式下也会匹配「末尾换行之前」的位置——于是 ^\d+$ 会接受 "123\n"；
• 这不是学术问题：用它做「只允许数字」的输入校验，攻击者在末尾加一个换行就能带进额外字节（后续按行处理时可能被拆成两条）；
• 正解是用绝对末尾锚点：Python 用 \Z（或 3.14+ 的 \z）、Go 用 \z。JS 的 $ 本来就是绝对末尾，没有这个坑；
• 反过来，开了多行（/m / re.M）之后 ^ $ 才变成每一行的首尾——而 \A \Z \z 不受多行影响，这正是它们存在的意义。

\b 处理中文时直接失效（实测）

Python:  re.findall(r"\b\w+\b", "你好，世界")  →  ['你好', '世界']
JS:      "你好，世界".match(/\b\w+\b/g)          →  null

• 原因不在 \b 本身，而在它依赖的 \w：\b 的定义是「\w 与非 \w 之间的位置」，\w 不认中文，边界自然无从谈起；
• 所以上一张卡那张 \w 对照表在这里直接结账：Python 能用、JS/Go/C++ 完全失效；
• 在 JS 里要做中文「词」边界，只能自己界定：(?<!\p{L})…(?!\p{L}) 配 /u，即「前后都不是字母」。但中文本来就不用空格分词，「词边界」这个概念在中文文本上多数时候是伪需求——真要分词该用分词库；
• \b 是零宽的：它不消耗字符，所以 \bcat\b 的长度就是 cat，替换时不会误删两侧的字符。

同一个「第 1 组」，三处写法互不相同

• 跨语言搬正则时，模式往往能直接用，替换串几乎总要改——这张表就是为这件事准备的；
• Go 的替换串必须用 ${1} 形式，只要引用后面紧跟字母或数字：实测 $1x 被当成组名 1x、取到空串，${1}x 才对。这一条不报错，只是结果静悄悄地少一截；
• Python 的替换串不认模式语法：写 \d 会报 bad escape \d，它只认 \1 与 \g<…>；
• 组号从 1 开始，0 表示整体匹配（JS 写 $&，Python 写 \g<0>，Go 写 $0）。

Go 为什么没有反向引用

• RE2 保证匹配时间与输入长度成线性关系，代价就是放弃反向引用与环视——这两样都需要回溯，而回溯正是指数级爆炸的来源；
• 所以这不是「Go 的正则弱」，是一个明确的工程取舍：用能力换「任何输入都不会把服务卡死」的保证；
• 在 Go 里需要反向引用时，标准做法是先用正则粗匹配、再在代码里比较——通常也更好读。

重名组：ES2025 放宽了，但你的运行时未必（实测）

Node 22:  new RegExp("(?<n>a)|(?<n>b)")
          → SyntaxError: Duplicate capture group name
Node 22:  new RegExp("(?:(?<n>a)|(?<n>b))")   ← 互斥分支
          → 同样报错
Python:   re.compile(r"(?P<n>a)|(?P<n>b)")
          → PatternError: redefinition of group name 'n'

• ES2025 的放宽是「允许出现在互斥的交替分支里」，但实测 Node 22 两种写法都报错——需要 Node 24+ / 较新的 V8；
• 所以「网上说 JS 现在允许重名组了」这条要配上运行时版本一起看，照抄进 Node 22 的项目会直接编译失败；
• 组名还必须是合法标识符：不能以数字开头、不能含连字符。

| 的优先级低到超出直觉

^cat|dog$    实际含义是  (^cat) | (dog$)
                        不是  ^(?:cat|dog)$

「abc」 匹配 ^cat|dog$ ？  否
「cat123」 匹配？          是（^cat 命中）
「123dog」 匹配？          是（dog$ 命中）

• | 是整个正则里优先级最低的运算符，两侧会一路延伸到最近的分组边界或字符串边界；
• 规则很简单：只要用了 |，就把它包进 (?:…)——哪怕看起来不需要；
• 另一半是顺序：回溯引擎的交替是「最左优先」而不是「最长优先」。(?:a|ab) 对 "ab" 只会吃到 a，更长的分支必须放前面。这与 POSIX 引擎的「最长匹配」语义相反，是从 awk/grep 迁过来的人最容易出错的一处。

支持度：这是四门差距最大的一处

四门的安全交集只有「先行断言」。只要这条正则可能跑在 Go 上就别用环视——RE2 放弃它是为了换线性时间保证，这件事不会改。替代办法是先用正则粗匹配，再在代码里判断，通常还更好读。

支持度：这是四门差距最大的一处（实测）

• JS 的后行断言反而是四门里最强的（ES2018 起支持变长），这与「JS 正则弱」的刻板印象正好相反；
• Go 的「完全不支持」和前一章反向引用是同一个原因：RE2 用能力换线性时间保证；
• 结论很实际：只要这条正则可能要跑在 Go 上，就别用环视；要跨四门通用，能用的只有「先行断言 + 定长后行」这个交集。

千位分隔：一个纯位置匹配

JS:  "1234567".replace(/\B(?=(\d{3})+(?!\d))/g, ",")  →  1,234,567
        └─ 不在词边界      └─ 后面剩的数字个数是 3 的整数倍

• 它匹配的是位置而不是字符——所以 replace 是在往位置里「插入」逗号，原数字一个都没被改；
• 这条正则依赖后行断言吗？不依赖，只用了先行——所以它是少数几个四门里都能跑的环视用法之一（Go 除外，Go 连先行都没有）；
• Python 里同样写法可用，但更地道的是 f"{n:,}"——有内置格式化就别写正则。

lastIndex：JS 独有的状态陷阱

const r = /a/g;
r.test("aa")  →  true    lastIndex = 1
r.test("aa")  →  true    lastIndex = 2
r.test("aa")  →  false   ← 同一个字符串，第三次就 false 了

三种解法，按推荐顺序：①校验用途别加 g；②每次现造一个正则；③手动 r.lastIndex = 0。把正则提成模块级常量再反复 test，是 JS 里最难查的一类 bug——单测里通常只调一次，永远复现不出来。

lastIndex：JS 独有的状态陷阱（实测）

const r = /a/g;
r.test("aa")  →  true   lastIndex = 1
r.test("aa")  →  true   lastIndex = 2
r.test("aa")  →  false  ← 同一个字符串，第三次就 false 了

• 带 g（或 y）的正则对象是有状态的：test/exec 会从 lastIndex 继续找，并把它往后推；
• 于是把正则提成模块级常量再反复 test，结果会随调用次数「跳着变」——这是 JS 里最经典、也最难查的一个正则 bug，因为单测里通常只调一次；
• 三种解法：①校验用途别加 g（最简单）；②每次现造一个正则；③手动 r.lastIndex = 0；
• String.prototype.match/replace/matchAll 会自己处理这件事，只有 test 与 exec 会踩。

开了 x 之后，空格的含义变了（实测）

Python:  re.match(r"a b", "ab", re.X)   →  匹配（模式里的空格被忽略）
Python:  re.match(r"[ a]", " ", re.X)   →  匹配（字符类内的空格仍是字面量）

• 规则是「类外忽略、类内保留」——所以开了 x 之后要匹配真正的空格，写 [ ]、\s 或转义的 \ ；
• # 之后到行尾算注释，要匹配字面 # 得转义；
• JS 没有 x 标志（实测 new RegExp("a b", "x") 报 Invalid flags），只能用字符串拼接来模拟——但拼接会把注释留在 JS 代码里而不是正则里，效果其实差不多。

四门的支持度差到无法通用（实测）

• Python 的位置限制是实测出来的：Hello(?i)world 直接报 global flags not at the start of the expression——而这个写法在 Perl/PCRE 里是合法的，从那边搬过来就会炸；
• ES2025 给 JS 加了 (?i:…)，但实测 Node 22 仍不支持，需要更新的引擎；
• C++ 的情况最危险：(?i)abc 可能既不报错也不生效，只能靠构造时传 std::regex::icase——移植时这类「静默失效」比报错难查得多。

ReDoS：危险结构与改写

触发条件三个缺一不可：①回溯型引擎；②嵌套量词或可重叠分支；③一个「差一点就匹配上」的输入。第三条决定了它难以在测试中发现——正常输入都很快，只有精心构造的输入才炸。

它不是 /u 的超集，是替代品（实测）

new RegExp("a", "uv")   →  SyntaxError: Invalid flags   ← 只能二选一
new RegExp("[[]", "u")  →  允许（类内未转义的 [ 当字面量）
new RegExp("[[]", "v")  →  SyntaxError: Unterminated character class

• /v 换来的是类内的集合运算：差集 --、交集 &&、以及多字符元素——这让「所有字母但排除 ASCII」这种需求能直接写出来；
• 代价是语法更严格：一批在 /u 下宽容通过的写法会直接报错。所以从 /u 切到 /v 不是「加个字母」，要重测；
• 这是 JS 独有的特性，Python / Go / C++ 都没有对应物——跨语言共用的正则里别出现它。

该停手的信号

• 需要递归，通常意味着你在匹配的是一门语言而不是一个模式：嵌套括号、JSON、HTML、配置文件——这些都该用解析器；
• 经典结论「正则不能解析 HTML」的准确说法是：正则（正规语言）表达不了任意深度的嵌套结构（上下文无关文法）。PCRE 的递归扩展本身已经超出了「正则」的定义；
• 四门标准库（JS、Python re、Go、C++ std::regex）全都不支持递归；真需要时用 PCRE2 或 Python 的第三方 regex 库；
• 即便能用，递归正则性能开销大、嵌套深时会栈溢出，而且几乎不可维护——它在工程里的正确用途是「一次性脚本」，不是产品代码。

它在四门标准库里根本不存在（实测）

Python:  re.search(r"ab\Kc", "abc")   →  PatternError: bad escape \K
JS:      new RegExp("ab\Kc")          →  编译通过，但 \K 被当成字面字符 K

• JS 的行为比 Python 危险：不报错、静默当字面量——照抄 PCRE/Perl 的 \K 过来会得到一条永远匹配不上的正则，而且没有任何提示；
• \K 的价值在于「变长后行」：前缀\K目标 等价于 (?<=前缀)目标 但前缀可以是任意长度。而 Python 的后行必须定长（实测 (?<=a+) 直接报错）；
• 替代方案：用捕获组取子串。 把「前缀」和「目标」都放进模式，只取目标那一组——多一行代码，但四门通用。

爆炸的形状：嵌套量词 + 可重叠的分支

危险：  (a+)+$        (a|a)*$       (\s*\S*)+$
        └─ 量词套量词，同一段输入有指数级多种拆分方式

对 "aaaaaaaaaaaaaaaaaaaaaaaaaaX" 这类输入，
引擎要把每一种拆分都试一遍才能确定失败

• 触发条件有三个，缺一不可：①回溯型引擎；②嵌套量词或可重叠的交替；③一个「差一点就匹配上」的输入；
• 第三条决定了它难以在测试中发现——正常输入都很快，只有精心构造的输入才炸；
• 三条防线，按可靠性排序：①用 RE2（Go 的标准库、以及各语言的 re2 绑定）——线性时间是引擎级保证；②用独占量词/原子组砍掉回溯（Python 3.11+）；③给正则匹配加超时；
• 不要靠「把正则写好一点」当防线——能不能看出一条正则有指数回溯，本身就是很难的判断。这也正是 Go 当初选择 RE2、放弃反向引用与环视的理由。

用这些模式前先过三道

邮箱：正则校验是个陷阱

• 完整符合 RFC 5322 的邮箱正则有几千个字符，而且即便完全正确，也证明不了这个地址真的存在；
• 业界共识是「只做最粗的形状检查 + 发验证邮件」：形状上只要求「有 @、@ 前后非空、后面有点」就够了；
• 严格的正则反而会误伤合法地址：加号别名（a+tag@b.com）、新顶级域（.museum）、国际化域名，都被大量流传的「严谨邮箱正则」拒之门外；
• 结论：这类正则的正确用途是「拦住明显的手滑」，不是「保证有效」。

校验数字时最容易漏的四种输入

• 前导零：007 该不该收？\d+ 会收；
• 正负号与小数点：-1.5、.5、1. 各算不算？
• 科学计数法：1e10 在 \d+ 下会被拆成 1 和 10；
• 末尾换行：Python/PCRE 下 ^\d+$ 会接受 "123\n"（见「位置锚点」那一卡的实测），校验场景必须用 \z/\Z；
• 金额还要多想一层：别用浮点存钱。正则只负责「形状对不对」，值该用定点数或整数分来存。

正则只能验形状，验不了「这天存在吗」

• \d{4}-\d{2}-\d{2} 会痛快地接受 2026-02-31 和 2026-13-45；
• 把月份和天数的合法组合写进正则是可能的（(?:0[1-9]|1[0-2]) 之类），但闰年规则写不进去——写得进去也没人愿意维护；
• 正确分工：正则粗筛形状，然后交给日期库真正解析。 解析失败就是无效日期，这一步顺便还替你处理了时区与格式变体；
• 更好的做法是从一开始就用 ISO 8601（2026-07-26T12:00:00Z），格式唯一、可直接字典序排序、各语言都有现成解析。

\d{1,3} 四段是错的

• \d{1,3}(\.\d{1,3}){3} 会接受 999.999.999.999——每段的上界是 255，正确写法要按位数分支：(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)；
• 端口同理：上界 65535，\d{1,5} 会放进 99999；
• IPv6 用正则基本不现实：压缩写法（::）、内嵌 IPv4、区域标识符加起来的组合太多；
• 结论和日期一样：有解析函数就用解析函数。 Python ipaddress、Go net.ParseIP、JS 侧的成熟库——它们连「这是不是私有地址」都能一并告诉你。

手机号与身份证：正则做不到的那一半

• 手机号：号段是会变的（工信部不断放号）。把号段写死进正则，意味着每次放新号段都要改代码——更稳的做法是只校验「1 开头的 11 位数字」，真实性交给短信验证码；
• 身份证：18 位的最后一位是校验码，用前 17 位加权求和算出来。正则完全表达不了这个计算——只写正则的校验会放进大量伪造号；
• 两者的共同结论：正则负责形状，业务规则负责有效性。 把业务规则往正则里塞，得到的是又长又错、还要不断修改的东西。

四条最容易踩的 API 差异

JS 侧最该记住的三件事

• 带 g 的正则对象有状态：lastIndex 会累加，反复 test() 同一个字符串会跳着给出 true/true/false（实测）。校验用途别加 g；
• \w 与 \b 只认 ASCII，加 /u 也不改（实测 "你好".match(/\w+/gu) 为 null）。中文要用 \p{Script=Han}；
• /u 与 /v 互斥（实测传 "uv" 直接报 Invalid flags）；
• 好消息是 JS 的后行断言不要求定长，这一点强于 Python。

std::regex 是四门里最弱的一个

• 不支持：命名组、后行断言、\p{}、内联标志、独占量词、原子组、递归、条件分组；
• 而且性能长期被诟病：std::regex 的构造与匹配开销都很大，热路径上常常比手写字符串处理慢一个数量级；
• 内联标志的失效方式最危险：(?i)abc 从别的语言搬过来时可能既不报错也不生效，只能靠构造时传 std::regex::icase；
• 结论：C++ 里但凡正则稍微复杂一点，主流做法就是链接 PCRE2——它支持本页提到的几乎全部特性，包括递归与 \K。

自测：会了没有