JavaScript正则表达式的能力取决于对RegExp行为边界、replace()回调机制及转义规则的理解;字面量与new RegExp()转义不同,需双重反斜杠;replace()支持函数参数获取匹配上下文;test()/exec()受lastIndex影响,需重置或改用matchAll();u标志配合\p{Letter}支持Unicode字符。
JavaScript 正则表达式本身并不“天生强大”,它的能力完全取决于你是否理解 RegExp 对象的行为边界、String.prototype.replace() 的回调机制,以及哪些元字符在字面量写法和 new RegExp() 构造函数中需要双重转义。
写 /\d+/ 没问题,但用构造函数时写 new RegExp("\d+") 会失效——因为字符串先被 JS 解析,\d 被当作非法转义而静默降级为字面 d。必须写成 new RegExp("\\d+"),即两个反斜杠才表示一个正则中的 \d。
常见错误现象:
new RegExp("https?://") → 匹配失败(? 被字符串解析吞掉)new RegExp("https\?://") → 语法错误(JS 字符串不认 \?)new RegExp("https\\?://") 或更安全的 new RegExp("https\\?:\\/\\/")
String.prototype.replace() 的替换逻辑远不止填个字符串那么简单。当第二个参数是函数时,它能拿到匹配的全部上下文,这才是动态替换的核心。
函数参数顺序固定为:(match, p1, p2, ..., offset, string),其中 p1、p2 是捕获组内容。
const text = "price: $19.99 and $29.50"; text.replace(/\$(\d+\.\d{2})/g, (match, dollars) => { return `¥${(parseFloat(dollars) * 7.2).toFixed(2)}`; }); // → "price: ¥143.95 and ¥212.40"
注意点:
g 标志才能全局替换,否则只处理第一个undefined,会被转成字符串 "undefined",不是跳过RegExp.prototype.test() 和 exec() 在带 g 标志时会维护内部 lastIndex,连续调用可能因位置偏移导致漏匹配或死循环。
典型场景:遍历匹配所有邮箱
const re = /\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/gi;
let match;
while ((match = re.exec(text)) !== null) {
console.log(match[0]); // ✅ 安全
}但下面这段会出问题:
const re = /\d+/g;
console.log(re.test("a1b2")); // true
console.log(re.test("c3d4")); // false ← 因为 lastIndex 还停在上一次末尾解决方式:
re.lastIndex = 0
String.prototype.matchAll()(返回迭代器,不改 lastIndex)g 的正则对象做多次独立 test()
\w 在 JS 中默认只匹配 ASCII 字母、数字和下划线(等价于 [a-zA-Z0-9_]),对中文、emoji、带重音的拉丁字母统统无效。
要真正支持 Unicode 单词字符,必须启用 u 标志,并用 \p{Letter} 类语法:
const re = /\p{Letter}+/gu;
"Hello 你好 ?".match(re); // ["Hello", "你好", "?"]但注意:
u 标志在 Node.js 12+ 和现代浏览器可用,IE 全系不支持\p{...} 不能和 g 以外的标志混用(比如 gi 可以,gm 也可以,但某些旧引擎对 gim 组合有 bug)[\u4e00-\u9fa5] 匹配中文更兼容,但无法覆盖生僻汉字或扩展区最常被忽略的是:正则的“强大”从不来自功能堆砌,而来自对 lastIndex、字符串预处理、标志组合影响、以及回调参数结构的稳定掌控。写错一个反斜杠、漏掉一个 g、或在不该复用正则的地方复用了,结果就不可控。