拒绝玄学：JS 正则表达式的几个实战“坑点”

工作中遇到表单验证、日志分析或者数据清洗，正则表达式几乎绕不开。但很多时候，它在我们手里就像一段“玄学代码”：网上找个现成的模板，改两个字符，运气好能跑通，一旦换个场景就报错。其实，正则本身逻辑并不复杂，真正让人头疼的往往是那些隐蔽的特性。

聊聊最常见的一个误区：全局标志 g 带来的状态污染。

当你定义一个带 g（global）标志的正则对象，比如 const reg = /\d+/g;，它在 JavaScript 引擎中是有“记忆”的。第一次调用 reg.exec(str) 找到数字后，它的 lastIndex 属性会自动移动到本次匹配结束的位置。如果紧接着再来一次调用，搜索会从上次结束的地方继续，而不是从头开始。这导致很多人反复 test 同一字符串，结果有时候返回 true，有时候又是 false。除非你每次用完重置 lastIndex，或者干脆在循环外新建一个正则实例，否则这种状态残留极易引发难以复现的 Bug。

再比如处理文本提取时的贪婪与非贪婪问题。

假设你要从 <div class="box">内容</div> 里抓取中间的文字。新手常写 <div.*?</div>，看起来没问题，可一旦 HTML 结构稍微复杂，变成 <div>A</div><div>B</div>，默认的贪婪模式 .* 就会直接从第一个 <div 一直匹配到最后一个 </div>，把中间所有内容全吞掉，只剩个空壳。这时候必须明确使用非贪婪匹配，也就是在量词后加个问号 *?，告诉引擎：“够用了就停，别贪心”。这个小小的符号差异，决定了你是拿到干净的数据，还是一堆混乱的 HTML 源码。

还有一个容易忽视的性能黑洞，叫 catastrophic backtracking（回溯灾难）。

当你写成类似 ^(a+)+$ 这样的规则去匹配一个包含大量重复字符但不符合条件的长字符串时，正则引擎会在内部进行指数级的尝试匹配。页面可能瞬间卡死甚至崩溃。并不是所有复杂的逻辑都适合用正则硬解。如果规则嵌套过深，或者涉及多层量词组合，哪怕暂时能用，未来也是定时炸弹。此时不如拆分成多个简单的逻辑判断，或者交给专门的解析库处理。

最后，别在没有工具辅助的情况下裸写复杂正则。

浏览器控制台虽然方便，但调试不够直观。现在有很多在线可视化调试工具可以帮你高亮匹配区域，一眼看出哪里捕获错了分组。记住，正则的初衷是解决问题，不是炫技。如果一段正则需要同事盯着看五分钟才能明白意图，那它就失败了。尽量给正则加上注释，或者封装成函数并命名清晰，毕竟维护代码的人，往往包括明天的你自己。

掌握这些细节，比背下一百个语法规则更有价值。别让正则成为拦路虎，把它当成手中的瑞士军刀，该锋利时锋利，该收刃时收刃。