正则测试器案例：手机号 / 邮箱 / URL
1. 案例写法：先定义边界，再定义内容
参考标准正则教程的思路，业务规则建议按“边界 + 主体 + 可选段”拆解。边界通常用 ^ 和 $ 确保整行匹配，主体用字符类和量词表达，可选段用分组配合 ? 控制。你在 JSONTOP 测试器中可以把这三段分步输入，逐步验证，而不是一次写完整条复杂正则。这样做的好处是每次问题都能定位到具体子表达式，后期维护更稳定。
2. 手机号案例：提取与校验要分开
如果目标是“从大段文本提取手机号”，可以使用类似 1[3-9]\d{9} 配合 g。如果目标是“表单整行校验”，应改成 ^1[3-9]\d{9}$。这两个规则逻辑不同，不能混用。常见错误是把提取规则直接用于校验，导致多余字符也被放过。建议在测试文本里同时放“正确号码、长度错误、号段错误、前后带空格”四类样本。使用匹配详情检查每一条命中的起止位置，确保没有误抓。
3. 邮箱案例：分组与优先级要清晰
邮箱规则容易因为优先级造成歧义。比如你希望本地名支持点号和加号，但域名只允许字母数字短横线，这就需要分组明确每段规则边界。写法上推荐先构造简化版本，再逐步增强。不要一开始就追求 RFC 全覆盖，否则可读性和可维护性会急剧下降。正则只做“格式层第一道过滤”，是否可投递、域名是否有效，应交给后端流程。这个分层思路能显著降低规则复杂度。
4. URL 案例：管道符与分组组合
URL 里最常见的分支是协议：http 或 https。这类需求应该写成 https? 或使用分组 (http|https)，而不是随意放 |。因为管道符优先级最低，如果分组不当，很容易匹配出意外结果。你可以准备几组 URL 样本：带协议、不带协议、带端口、带查询参数、错误域名。在测试器中逐个对比命中情况，确认规则既不过严也不过宽。
5. 案例回归模板（建议固定执行）
每次更新规则前后，都跑一次固定回归： 第一，正样本必须全部命中； 第二，负样本必须全部拒绝； 第三，复杂文本提取时命中数量要稳定； 第四，切换 flags 后行为变化要可解释。 这四步看起来基础，但能挡住绝大多数线上误匹配。你可以把样本保存在团队文档里，每次需求变更只改样本和规则，不改流程。
6. 从工具使用到工程落地
JSONTOP 正则测试器更适合作为“规则实验场”，而生产代码应把规则封装到校验层，统一维护版本。对于高风险字段（如账号、链接、标识符），建议在后端追加白名单策略或语义校验。正则擅长模式匹配，不擅长复杂业务判断。把两者职责分开，你的规则会更稳，系统也更容易演进。