用超长正则表达式（不拆分不注释，直接 500 字符正则）

正则表达式在前端开发中无处不在，从表单验证到文本处理都依赖它。但面对复杂匹配规则时，开发者可能被迫写出超长正则表达式，这种未拆解、未注释的"庞然大物"既难以维护又容易出错，却在实际场景中真实存在。

超长正则的典型应用场景

表单验证是超长正则的重灾区。比如要验证一个支持多国邮箱的复杂规则，可能会写出这样的怪物：

const emailRegex = /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))|([\u4e00-\u9fa5]+@([a-zA-Z0-9]+\.)+[a-zA-Z0-9]{2,})|([\u3040-\u309F\u30A0-\u30FF]+@([a-zA-Z0-9]+\.)+[a-zA-Z0-9]{2,})|([\uAC00-\uD7AF]+@([a-zA-Z0-9]+\.)+[a-zA-Z0-9]{2,})$/;

这个543字符的正则同时匹配：

1. 标准英文邮箱格式
2. 中文邮箱（如"张三@qq.com"）
3. 日文邮箱（如"あいうえお@example.com"）
4. 韩文邮箱（如"홍길동@naver.com"）

超长正则的性能陷阱

未优化的长正则可能导致灾难性回溯。考虑这个URL验证正则：

const urlRegex = /^(?:(?:https?|ftp):\/\/)(?:\S+(?::\S*)?@)?(?:(?!(?:10|127)(?:\.\d{1,3}){3})(?!(?:169\.254|192\.168)(?:\.\d{1,3}){2})(?!172\.(?:1[6-9]|2\d|3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d?|1\d\d|2[01]\d|22[0-3])(?:\.(?:1?\d{1,2}|2[0-4]\d|25[0-5])){2}(?:\.(?:[1-9]\d?|1\d\d|2[0-4]\d|25[0-4]))|(?:(?:[a-z\u00a1-\uffff0-9]-*)*[a-z\u00a1-\uffff0-9]+)(?:\.(?:[a-z\u00a1-\uffff0-9]-*)*[a-z\u00a1-\uffff0-9]+)*(?:\.(?:[a-z\u00a1-\uffff]{2,}))\.?)(?::\d{2,5})?(?:[/?#]\S*)?$/i;

当输入"http://"时，引擎需要尝试所有可能的IP段组合验证，在移动端可能导致线程阻塞。实际测试显示，在低端Android设备上，这个正则处理50个字符的异常字符串需要超过200ms。

维护地狱的真实案例

某电商平台的价格解析正则最初只有120字符，经过三年迭代变成这样：

const priceRegex = /(?<!\d)(?:(?:USD|CNY|JPY|EUR|GBP|HKD|CAD|AUD|SGD|CHF|SEK|DKK|NOK|MXN|NZD|BRL|RUB|INR|IDR|KRW|THB|MYR|PHP|VND)\s*)?[£¥€＄\$]?\s*-?\s*(?:\d{1,3}(?:,\d{3})*(?:\.\d{1,2})?|\d+(?:\.\d{1,2})?)(?:\s*(?:万|億|千万|百万)?\s*(?:元|円|刀|块|円|镑|欧|克朗|卢比|盾|铢|林吉特|比索|dong))?(?!\d)/gi;

新加入的实习生需要3天才能理解这个正则的匹配逻辑，期间还误删了韩元符号的匹配规则导致线上事故。

极端情况下的正则解法

处理HTML标签时（虽然不推荐用正则），可能被迫写出这样的模式：

const htmlTagRegex = /<\/?([a-z][a-z0-9]*)\b[^>]*>|<!--[\s\S]*?-->|<!\[CDATA\[[\s\S]*?\]\]>|<\?[\s\S]+?\?>|<([A-Za-z][A-Za-z0-9]*)\b[^>]*\/>|&(?:[a-z\d]+|#\d+|#x[a-f\d]+);/gi;

这个正则试图匹配：

• 常规HTML标签（含属性）
• 注释块
• CDATA段
• XML处理指令
• 自闭合标签
• HTML实体

现代JavaScript的替代方案

虽然不建议，但可以通过动态生成来构建长正则：

const buildEmailRegex = () => {
  const localPart = '([^<>()[\\]\\\\.,;:\\s@"]+(\\.[^<>()[\\]\\\\.,;:\\s@"]+)*)|(".+")';
  const domainPart = '(\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}])|(([a-zA-Z\\-0-9]+\\.)+[a-zA-Z]{2,})';
  const chinese = '[\\u4e00-\\u9fa5]+';
  const japanese = '[\\u3040-\\u309F\\u30A0-\\u30FF]+';
  const korean = '[\\uAC00-\\uD7AF]+';
  
  return new RegExp(
    `^(${localPart})@(${domainPart})|(${chinese}@([a-zA-Z0-9]+\\.)+[a-zA-Z0-9]{2,})|(${japanese}@([a-zA-Z0-9]+\\.)+[a-zA-Z0-9]{2,})|(${korean}@([a-zA-Z0-9]+\\.)+[a-zA-Z0-9]{2,})$`
  );
};

正则可视化工具的救赎

面对800字符的信用卡校验正则时：

const creditCardRegex = /^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11}|62[0-9]{14}|(?:81[0-9]{14}|82[0-9]{14}|84[0-9]{14}|85[0-9]{14}|86[0-9]{14}|88[0-9]{14}|89[0-9]{14})$/;

使用regexper.com等可视化工具可以生成流程图，否则人类几乎无法理解这个匹配Visa、MasterCard、JCB等16种卡型的模式。