正则的麻烦之处在于：它能匹配你手头那几个例子，不代表它能匹配真实数据里的所有情况。常见的翻车场景是上线后发现有些合法输入被误判为非法，或者某些恶意输入绕过校验钻了进来。写好正则只是第一步，用足够的用例去验证它，才是决定这段代码能不能上线的关键。
不要只测"应该匹配"的
大多数人的测试只有一半：拿几个正确样本试一下，能匹配就认为完成了。真正重要的是另一半——那些不应该被匹配的字符串。手机号正则要能拒绝带空格的、带区号的、少一位的；邮箱正则要能拒绝没有 @ 的、@ 后面没有点的。把正例和反例成对列出来，两边都通过才算验证完成。
边界情况清单
有几类输入几乎必然藏着问题：空字符串、超长字符串、首尾带空格、含换行符、纯特殊字符。很多正则用 ^ 和 $ 限定边界，却忘了处理尾部换行——在某些实现里 $ 会匹配换行符之前的位置，导致"abc\n"被判定为合法。另外要注意大小写，默认区分大小写的规则在用户输入场景下经常需要显式加忽略标记。
贪婪和懒惰的影响
量词默认是贪婪的，会尽可能多地吃掉字符。用 <.+> 去匹配一段 HTML，它会从第一个尖括号一直吃到最后一个，把中间所有内容都当成一次匹配结果，而不是你想要的每个标签单独匹配。改成 <.+?> 变成懒惰模式就能按最短匹配。验证时一定要在多标签、多重复的样本上测试，单个样本看不出贪婪模式的问题。需要现成写法做参照时，可以翻常用正则表达式对照。
留意回溯带来的卡顿
嵌套量词是性能杀手，类似 (a+)+b 这种写法在遇到一长串 a 却不匹配时，会尝试近乎指数级的组合路径，几 KB 的输入就能让程序卡住几十秒。验证正则时不只要看结果对不对，也要拿一个明显不匹配的超长字符串试一次，观察耗时是否异常。必要时把嵌套量词改写成更确定的形式，或者拆成多次简单匹配。
把用例固化下来
验证通过的正则，记得把那组正反例一起存进代码的单元测试，而不是验证完就丢掉。下次有人调整正则时，跑一遍测试就知道有没有改坏原有行为——正则这种东西，隔半年再看连作者自己都读不懂，没有测试兜底谁都不敢动。写法细节记不清的时候查一下正则表达式语法速查，比凭记忆试错快得多。