用正则铁路图调试：5 种从图上一眼看出来的坑

Q: 铁路图最基本要怎么看？

线 = 顺序，分叉 = 选项，环路 = 量词，终点 = 匹配成功。基本元素：(1) 横线——从左到右依次匹配，相当于字符串拼接；(2) 上下分叉（多条平行线汇合）——a|b|c 这类选择，匹配走任意一条；(3) 向上的环（圆弧回到起点）——*、+、?、{n,m} 量词，每次循环消耗 0 或多个字符；(4) 小方框 / 椭圆——具体字符或字符类，文字标签写出来；(5) 虚线 / 标记节点——前瞻 (?=...)、后瞻 (? ...)、非捕获 (?:...)，本工具用不同形状或颜色区分。读图顺序：从左边的 START 沿主轨道走到右边的 END，每个节点都是必须满足的条件；遇到分叉选一条；遇到回环可以走 0 次到 N 次。练手：在工具里贴 ^[A-Z][a-z]+$ 看图——START → 锚点 → A-Z 字符类 → 回环（a-z 一次或多次）→ 锚点 → END，这条路径就是你的正则。

Q: 嵌套量词的"环中环"具体长什么样？为什么是回溯灾难？

铁路图里一个圆弧内部又包含一个圆弧，就是回溯灾难的视觉信号。经典灾难正则：(a+)+$——外层 + 包外层捕获组，组内 a+ 又一个 +，图上是大圆弧套小圆弧。灾难原理：(1) 输入 aaaaaaaaaa! 时（最后一个非 a 让锚点失败），引擎尝试所有"外层把字符串分成几段，每段内部 a+ 各匹配多少 a"的组合；(2) 10 个 a 的分配方式 ≈ 2^9 = 512 种；(3) 30 个 a 时 ≈ 5 亿种，浏览器 hang 几秒；(4) 50 个 a 时 ≈ 10^14 种，几小时算不完。铁路图上的可视识别：(1) 你能用眼睛数出嵌套的两层环——必然有问题；(2) 三层及以上几乎一定挂；(3) 即便只有两层，如果内外环匹配的字符集有重叠（都是 a），就是灾难候选。安全的"两层"：(1) (\d+)\.\d+——外环数字、外面是分隔符，不嵌套；(2) (?:abc)+——内部是固定字符串无量词，安全。解法：(1) 把内层量词去掉，写成 a+$；(2) 用原子组 (?>a+)+（PCRE / Java，JS 不支持）；(3) 用占有量词 a++（JS 不支持）。

Q: 怎么从铁路图看出"少了 anchor"？

主轨道两端没有 ^ 和 $ 这两个标志节点——就是裸露的。对比：(1) ^\d{6}$——START → ^ → 数字×6 → $ → END，两端被锚住；(2) \d{6}——START → 数字×6 → END，两端开放，意思是"字符串里任意位置出现 6 位数字就算匹配"。典型坑：(1) "校验手机号是否合法"，正则写成 \d{11}——会匹配 abc12345678901xyz，因为没要求"字符串完全等于 11 位数字"；(2) "校验邮箱"忘加锚点——a@b.c 是子串，会被 a@b\.c 命中即便外面包了垃圾。铁路图识别：(1) 找最左和最右节点；(2) 不是 START of line / END of line / START of input / END of input → 必须警觉；(3) 工具里这两个节点通常用特殊形状（盒子带角标或竖线）标注。例外：(1) String.match 和 RegExp.test 只判断"是否含有"，本来就不需要锚点；(2) String.replace 全局替换不加锚点是对的；(3) 用 test 校验输入合法性是常见误用——test(/\d{6}/) 不等于"输入是 6 位数字"。

Q: 铁路图能看出"过度宽容"吗？

能——看节点的字符集是否包含了不该有的字符。最常见的过度宽容是 .（任意字符）。例：(1) 想匹配 IPv4 写 \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}——三个 \. 是字面点，对，但 \d{1,3} 接受 999、500 这些非法八位组；(2) 想匹配日期写 \d{4}-\d{2}-\d{2}——会匹配 9999-99-99；(3) 想匹配文件路径写 .*\.txt——.* 会贪婪吃掉所有内容包括 \n（除非 s 标志关掉）。铁路图视觉信号：(1) 节点标 "any character"、"any single character" → 警觉；(2) 字符类 [0-9] 是 0–9，但 [0-9]{1,3} 也是 0–999，工具会显示范围"1 至 3 次"——你心算最大值就知道是否合理；(3) \w 实际是 [A-Za-z0-9_]，常被误以为"字母"——下划线也算。关键问句："这个字符类最宽容能匹配什么？我能不能立刻构造一个反例？"——构造不出 → 大概是对的；构造得出 → 改严。

Q: 贪婪量词的"匹配最长"在图上能看出来吗？

铁路图里量词节点会标注 greedy / lazy / possessive，但具体匹配多长仍要心算。贪婪 vs 惰性：(1) .*"——贪婪，输入 "a" "b" 会匹配整个 "a" "b"（最长）；(2) .*?"——惰性，输入 "a" "b" 会匹配 "a"（最短）；(3) 占有 .*+"——贪婪且不回溯（JS 不支持）。图上的标注：本工具会在量词节点标 0+、1+、{n,m}，配 greedy / lazy 字样。怎么用图判断：(1) 找 .* 这种"任意字符 + 任意次数"节点；(2) 看它后面紧跟什么——.*" 后接 " → 想想从字符串最右那个 " 倒着退；(3) 倒着退过程中匹配的内容就是结果。经典坑：(1) HTML 提取 想抓单个标签——会抓整段 ... ；(2) JSON 抓字符串 ".*"——同上问题。修法：(1) 改惰性 、".*?"；(2) 改字符类排除 ]+>、"[^"]*"（更稳，因为不依赖回溯）；(3) 能用 [^X] 排除的别用 .*?——性能差几十倍。

Q: 前瞻 (?=...) 和后瞻 (?<=...) 在铁路图里怎么显示？为什么常被读错？

通常用虚线框 / 浅色 / "lookahead/behind" 标签表示——关键是它们不消耗输入。消耗 vs 不消耗：(1) 普通字符 a——主轨道前进 1 字符；(2) 前瞻 (?=a)——检查"接下来是不是 a"，但指针不动；(3) 后瞻 (?<=a)——检查"前面是不是 a"，指针也不动。铁路图视觉：(1) 实线节点 = 消耗，主轨道继续向右；(2) 虚线 / 浅色节点 = 不消耗，主轨道回到当前位置；(3) 工具一般在前瞻 / 后瞻节点旁边写 "zero-width" 或 "0 chars" 提示。经典误用：(1) 想"匹配后面跟着数字的字母"写成 a-z——结果只匹配字母，数字仍在原位等下次匹配；(2) 后续 replace 时只替换字母，数字保留；(3) 用 [a-z]\d 才会同时消耗两者。用法对：(1) "密码必须含数字"：(?=.*\d).{8,}——前瞻不动指针，后面的 .{8,} 才是真匹配的内容；(2) "数字之间加千分位逗号"：\B(?=(\d{3})+(?!\d))——纯定位 0 宽匹配。记忆：前瞻 / 后瞻是"约束 + 不消耗"，画图时检查后面还有没有真消耗的节点——没有就只是约束。

Q: 命名捕获 (? ...) 和普通捕获 (...)、非捕获 (?:...) 在图上有什么区别？

视觉差异主要在标签——铁路图会标 Group 1、Group "name"、non-capturing。三种的差别：(1) 普通捕获 (abc)——内容存入捕获组 1，可在 replace 用 $1 引用、在 JS 用 match[1]；(2) 命名捕获 (? \d{4})——内容同时存入 group 1 和 groups.year，可读性强；(3) 非捕获 (?:abc)——只用括号分组（让量词作用于整组），不存任何东西，最快。性能差异：(1) 非捕获 )，可读性救命；(4) 同一正则混用别太多种——读图会乱。铁路图利用：把鼠标悬在分组节点上，工具会显示该组的"组号 / 名字 / 捕获状态"——一眼看出哪些是有用信息、哪些只是结构。

Q: 什么时候铁路图也救不了，必须拆分正则？

节点超过 50、嵌套深度超过 4 层、图横向滚动两屏以上——这三个信号任意一个出现都该拆。铁路图的极限：(1) 30 节点以内 → 一眼看懂；(2) 30–50 → 需要顺着轨道仔细读；(3) 50+ → 图大到看不全，分支多到无法心算；(4) 100+ → 图本身比正则源码更难懂。典型该拆的场景：(1) 一个正则同时干"解析 + 校验 + 提取" → 拆成两步：先校验 test()，再用更宽松正则 match() 提字段；(2) 多种格式 OR 在一起 (formatA|formatB|formatC) 且每种内部都复杂 → 三个独立正则按格式分支处理；(3) HTML / XML / JSON 这类嵌套结构 → 正则本质上无法表达嵌套，用解析器；(4) URL 完整解析 → 用 new URL() 或 URL.parse，不要写 200 字符正则；(5) 日期完整校验（闰年 + 月日合法性） → 先用宽松正则切出 Y/M/D，再用 Date 对象验证。拆分的好处：(1) 每段铁路图都 < 30 节点，能看懂；(2) 单元测试每段独立；(3) 出 bug 时能定位到哪一段。反面教材：见过最长的"邮箱完整正则"是 RFC 5322 的实现，500+ 字符——铁路图横向滚动 5 屏，没人能审计，最后都退回到 [^@]+@[^@]+\.[^@]+。

2026-05-11 · 约 4 分钟 🛤️ 正则铁路图

正则铁路图（railroad diagram）把抽象的正则字符串变成可视化流程图——但它的真正价值不是”好看”，而是让一些原本要跑测试才能发现的 bug 在视觉上立刻暴露。这篇讲清楚 5 种从图上一眼能看出来的反模式。

铁路图怎么读：三句话总览

视觉元素	含义
横线 / 实线节点	顺序匹配，消耗字符
上下分叉	`\|` 选项，走任一条
向上回环	量词 `*` `+` `?` `{n,m}`，循环 0 到 N 次
虚线 / 浅色节点	前瞻 / 后瞻，不消耗字符
特殊形状两端	`^` `$` 锚点
方框 + 标签	字符 / 字符类 / 字面量

读图就是从左边 START 沿主轨道走到右边 END，每个节点都是必须满足的条件。

反模式 1：嵌套量词 = 回溯灾难

视觉信号：圆弧套圆弧，一个量词环里又有量词环。

经典灾难：

(a+)+$

铁路图大概长这样（示意）：

START ──[ 大环 ]── $ ── END
         │
         └──[ 小环 ]──
              │
              a

为什么挂：输入 aaaa...a!（末尾非 a 让 $ 失败）时，引擎要回溯所有可能的”a 的分组方式”——n 个 a 大约 2^(n-1) 种，30 个 a 时 5 亿种，浏览器卡死。

安全的”两层”对比：

正则	安全吗	原因
`(\d+)\.\d+`	✅	外层是 `.` 分隔，不嵌套
`(?:abc)+`	✅	内部固定字符串无量词
`(a+)+`	❌	内外都匹配 a，灾难
`(a)`	❌	同上
`(.)`	❌	最严重

眼力训练：在工具里贴 (\w+\s?)*$ 看图——你能数出两层环、且内外字符集重叠（\w 和 \s 在某些场景下都可空）→ 这是灾难候选。

反模式 2：裸露的两端（缺 anchor）

视觉信号：主轨道最左和最右没有锚点节点，直接是 START → 字符 → … → END。

正则             图的两端       含义
^\d{6}$         START → ^ → ...→ $ → END    完全等于 6 位数字
\d{6}           START → ... → END           含有 6 位数字

典型场景误用：用 test() 校验输入合法性：

/\d{11}/.test('abc12345678901xyz')  // true！但不是 11 位手机号
/^\d{11}$/.test('abc12345678901xyz') // false ✓

铁路图自检：找最左和最右节点——不是 Start of String/Start of Line/End of String/End of Line 就警觉。

例外：用 replace 全局替换、用 match 提取子串本来就不该加锚点。校验和提取是两个意图，正则也是两类。

反模式 3：字符类过度宽容

视觉信号：字符类节点标签写得很宽（“any character”、“0–999”、\w）。

想匹配	你写的	实际能匹配
IPv4 八位组	`\d{1,3}`	999
日期月份	`\d{2}`	99
邮箱用户名	`\w+`	包括下划线
文件路径	`.*`	包括换行（除非 `s`）
单行内容	`.+`	不含换行（合理）但可空

用图自检：

找每个字符类节点
心算”最宽容能匹配什么”
立刻构造一个”通过正则但语义错误”的反例
构造得出 → 改严（用更窄的字符类，或后置校验）

反模式 4：贪婪量词 + 错误终止符

视觉信号：.* 这类”任意字符 + 任意次数”节点，后面跟单字符终止符。

经典：

<.*>    匹配 HTML 标签？错——会抓整段 <div>xxx</div>

图上看：. 是”任意单字符”（含 >），* 是贪婪 → 引擎从字符串末尾的 > 倒着退，结果是包含中间所有 > 的最长串。

三种修法：

写法	速度	何时用
`<.*?>` 惰性	中	简单场景
`<[^>]+>` 排除字符类	快	推荐
`<[^>]*+>` 占有量词	最快	PCRE/Java，JS 不支持

铁路图技巧：量词节点本身会标 greedy / lazy，但性能差异不在贪婪 / 惰性本身，在于是否依赖回溯——能用排除字符类时永远优先。

反模式 5：前瞻 / 后瞻不消耗带来的 off-by-one

视觉信号：前瞻 / 后瞻节点是虚线或浅色，主轨道在该节点处”原地回到起点”。

[a-z](?=\d)      匹配后面跟数字的字母——但只消耗字母

输入	匹配结果	注意
`a1b2c3`	`a`、`b`、`c`	数字仍在原位
用 `replace('X')`	`X1X2X3`	数字被保留

如果想”匹配字母 + 数字一起替换”，应该用 [a-z]\d 消耗两者。

前瞻的正确用法：

(?=.*\d).{8,}    密码至少 8 位且含数字

前瞻只是”约束”，真正消耗的是后面的 .{8,}——铁路图里前瞻是虚线、.{8,} 是实线。

铁路图救不了的情况

节点 > 50、嵌套深度 > 4、横向滚动 > 2 屏——任一信号就该拆。

不要硬塞进单个正则	用什么替代
HTML / XML 嵌套结构	DOM 解析器
JSON	`JSON.parse`
URL 完整解析	`new URL()`
完整日期校验（含闰年）	宽松正则切字段 + `Date` 验证
RFC 5322 完整邮箱	`[^@]+@[^@]+\.[^@]+` + 后置规则

拆分的好处：每段图都 < 30 节点能看懂；单元测试可独立；调 bug 能定位到段。

一份”铁路图自检清单”

每次写完正则贴进工具看图，按顺序问自己：

主轨道两端有 ^ 和 $ 吗？是否符合”校验 vs 提取”的意图？
有没有圆弧套圆弧？两层环的字符集重叠吗？
每个字符类的最大边界是什么？能不能构造反例？
.* / .+ 后面跟的是排除字符类还是单字符？惰性写够了吗？
前瞻 / 后瞻节点（虚线）后面有没有真正消耗的实线节点？
图横向滚动超过一屏吗？要不要拆？

一句话总结

铁路图的真正价值不是”画得好看”，而是把”环中环 = 回溯灾难、裸露两端 = 缺 anchor、宽容字符类 = 反例可构造、贪婪 + 错终止 = 抓太多、虚线节点 = 不消耗”这五种 bug 模式从抽象正则变成视觉信号——一眼可见。

❓ 常见问题

铁路图最基本要怎么看？

线 = 顺序，分叉 = 选项，环路 = 量词，终点 = 匹配成功。基本元素：(1) 横线——从左到右依次匹配，相当于字符串拼接；(2) 上下分叉（多条平行线汇合）——a|b|c 这类选择，匹配走任意一条；(3) 向上的环（圆弧回到起点）——*、+、?、{n,m} 量词，每次循环消耗 0 或多个字符；(4) 小方框 / 椭圆——具体字符或字符类，文字标签写出来；(5) 虚线 / 标记节点——前瞻 (?=...)、后瞻 (?<=...)、命名捕获 (?<name>...)、非捕获 (?:...)，本工具用不同形状或颜色区分。读图顺序：从左边的 START 沿主轨道走到右边的 END，每个节点都是必须满足的条件；遇到分叉选一条；遇到回环可以走 0 次到 N 次。练手：在工具里贴 ^[A-Z][a-z]+$ 看图——START → 锚点 → A-Z 字符类 → 回环（a-z 一次或多次）→ 锚点 → END，这条路径就是你的正则。

嵌套量词的"环中环"具体长什么样？为什么是回溯灾难？

铁路图里一个圆弧内部又包含一个圆弧，就是回溯灾难的视觉信号。经典灾难正则：(a+)+$——外层 + 包外层捕获组，组内 a+ 又一个 +，图上是大圆弧套小圆弧。灾难原理：(1) 输入 aaaaaaaaaa! 时（最后一个非 a 让锚点失败），引擎尝试所有"外层把字符串分成几段，每段内部 a+ 各匹配多少 a"的组合；(2) 10 个 a 的分配方式 ≈ 2^9 = 512 种；(3) 30 个 a 时 ≈ 5 亿种，浏览器 hang 几秒；(4) 50 个 a 时 ≈ 10^14 种，几小时算不完。铁路图上的可视识别：(1) 你能用眼睛数出嵌套的两层环——必然有问题；(2) 三层及以上几乎一定挂；(3) 即便只有两层，如果内外环匹配的字符集有重叠（都是 a），就是灾难候选。安全的"两层"：(1) (\d+)\.\d+——外环数字、外面是分隔符，不嵌套；(2) (?:abc)+——内部是固定字符串无量词，安全。解法：(1) 把内层量词去掉，写成 a+$；(2) 用原子组 (?>a+)+（PCRE / Java，JS 不支持）；(3) 用占有量词 a++（JS 不支持）。

怎么从铁路图看出"少了 anchor"？

主轨道两端没有 ^ 和 $ 这两个标志节点——就是裸露的。对比：(1) ^\d{6}$——START → ^ → 数字×6 → $ → END，两端被锚住；(2) \d{6}——START → 数字×6 → END，两端开放，意思是"字符串里任意位置出现 6 位数字就算匹配"。典型坑：(1) "校验手机号是否合法"，正则写成 \d{11}——会匹配 abc12345678901xyz，因为没要求"字符串完全等于 11 位数字"；(2) "校验邮箱"忘加锚点——a@b.c 是子串，会被 a@b\.c 命中即便外面包了垃圾。铁路图识别：(1) 找最左和最右节点；(2) 不是 START of line / END of line / START of input / END of input → 必须警觉；(3) 工具里这两个节点通常用特殊形状（盒子带角标或竖线）标注。例外：(1) String.match 和 RegExp.test 只判断"是否含有"，本来就不需要锚点；(2) String.replace 全局替换不加锚点是对的；(3) 用 test 校验输入合法性是常见误用——test(/\d{6}/) 不等于"输入是 6 位数字"。

铁路图能看出"过度宽容"吗？

能——看节点的字符集是否包含了不该有的字符。最常见的过度宽容是 .（任意字符）。例：(1) 想匹配 IPv4 写 \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}——三个 \. 是字面点，对，但 \d{1,3} 接受 999、500 这些非法八位组；(2) 想匹配日期写 \d{4}-\d{2}-\d{2}——会匹配 9999-99-99；(3) 想匹配文件路径写 .*\.txt——.* 会贪婪吃掉所有内容包括 \n（除非 s 标志关掉）。铁路图视觉信号：(1) 节点标 "any character"、"any single character" → 警觉；(2) 字符类 [0-9] 是 0–9，但 [0-9]{1,3} 也是 0–999，工具会显示范围"1 至 3 次"——你心算最大值就知道是否合理；(3) \w 实际是 [A-Za-z0-9_]，常被误以为"字母"——下划线也算。关键问句："这个字符类最宽容能匹配什么？我能不能立刻构造一个反例？"——构造不出 → 大概是对的；构造得出 → 改严。

贪婪量词的"匹配最长"在图上能看出来吗？

铁路图里量词节点会标注 greedy / lazy / possessive，但具体匹配多长仍要心算。贪婪 vs 惰性：(1) .*"——贪婪，输入 "a" "b" 会匹配整个 "a" "b"（最长）；(2) .*?"——惰性，输入 "a" "b" 会匹配 "a"（最短）；(3) 占有 .*+"——贪婪且不回溯（JS 不支持）。图上的标注：本工具会在量词节点标 0+、1+、{n,m}，配 greedy / lazy 字样。怎么用图判断：(1) 找 .* 这种"任意字符 + 任意次数"节点；(2) 看它后面紧跟什么——.*" 后接 " → 想想从字符串最右那个 " 倒着退；(3) 倒着退过程中匹配的内容就是结果。经典坑：(1) HTML 提取 <.*> 想抓单个标签——会抓整段 <div>...</div>；(2) JSON 抓字符串 ".*"——同上问题。修法：(1) 改惰性 <.*?>、".*?"；(2) 改字符类排除 <[^>]+>、"[^"]*"（更稳，因为不依赖回溯）；(3) 能用 [^X] 排除的别用 .*?——性能差几十倍。

前瞻 (?=...) 和后瞻 (?<=...) 在铁路图里怎么显示？为什么常被读错？

通常用虚线框 / 浅色 / "lookahead/behind" 标签表示——关键是它们不消耗输入。消耗 vs 不消耗：(1) 普通字符 a——主轨道前进 1 字符；(2) 前瞻 (?=a)——检查"接下来是不是 a"，但指针不动；(3) 后瞻 (?<=a)——检查"前面是不是 a"，指针也不动。铁路图视觉：(1) 实线节点 = 消耗，主轨道继续向右；(2) 虚线 / 浅色节点 = 不消耗，主轨道回到当前位置；(3) 工具一般在前瞻 / 后瞻节点旁边写 "zero-width" 或 "0 chars" 提示。经典误用：(1) 想"匹配后面跟着数字的字母"写成 a-z——结果只匹配字母，数字仍在原位等下次匹配；(2) 后续 replace 时只替换字母，数字保留；(3) 用 [a-z]\d 才会同时消耗两者。用法对：(1) "密码必须含数字"：(?=.*\d).{8,}——前瞻不动指针，后面的 .{8,} 才是真匹配的内容；(2) "数字之间加千分位逗号"：\B(?=(\d{3})+(?!\d))——纯定位 0 宽匹配。记忆：前瞻 / 后瞻是"约束 + 不消耗"，画图时检查后面还有没有真消耗的节点——没有就只是约束。

命名捕获 (?<name>...) 和普通捕获 (...)、非捕获 (?:...) 在图上有什么区别？

视觉差异主要在标签——铁路图会标 Group 1、Group "name"、non-capturing。三种的差别：(1) 普通捕获 (abc)——内容存入捕获组 1，可在 replace 用 $1 引用、在 JS 用 match[1]；(2) 命名捕获 (?<year>\d{4})——内容同时存入 group 1 和 groups.year，可读性强；(3) 非捕获 (?:abc)——只用括号分组（让量词作用于整组），不存任何东西，最快。性能差异：(1) 非捕获 < 普通捕获 < 命名捕获，但差异在毫秒级，业务代码不用为此优化；(2) 真正影响性能的是回溯，不是捕获类型。实际建议：(1) 不需要回引 → 非捕获 (?:)，少占内存；(2) 简单 1–2 个组 → 普通捕获 ()，$1、$2 直观；(3) 5+ 个组或长正则 → 命名捕获 (?<name>)，可读性救命；(4) 同一正则混用别太多种——读图会乱。铁路图利用：把鼠标悬在分组节点上，工具会显示该组的"组号 / 名字 / 捕获状态"——一眼看出哪些是有用信息、哪些只是结构。

什么时候铁路图也救不了，必须拆分正则？

节点超过 50、嵌套深度超过 4 层、图横向滚动两屏以上——这三个信号任意一个出现都该拆。铁路图的极限：(1) 30 节点以内 → 一眼看懂；(2) 30–50 → 需要顺着轨道仔细读；(3) 50+ → 图大到看不全，分支多到无法心算；(4) 100+ → 图本身比正则源码更难懂。典型该拆的场景：(1) 一个正则同时干"解析 + 校验 + 提取" → 拆成两步：先校验 test()，再用更宽松正则 match() 提字段；(2) 多种格式 OR 在一起 (formatA|formatB|formatC) 且每种内部都复杂 → 三个独立正则按格式分支处理；(3) HTML / XML / JSON 这类嵌套结构 → 正则本质上无法表达嵌套，用解析器；(4) URL 完整解析 → 用 new URL() 或 URL.parse，不要写 200 字符正则；(5) 日期完整校验（闰年 + 月日合法性） → 先用宽松正则切出 Y/M/D，再用 Date 对象验证。拆分的好处：(1) 每段铁路图都 < 30 节点，能看懂；(2) 单元测试每段独立；(3) 出 bug 时能定位到哪一段。反面教材：见过最长的"邮箱完整正则"是 RFC 5322 的实现，500+ 字符——铁路图横向滚动 5 屏，没人能审计，最后都退回到 [^@]+@[^@]+\.[^@]+。