JavaScript正则关键在写对用稳：字面量适合静态，new RegExp适合动态但需双写反斜杠；match/exec/test/replace行为差异大；常见失败因转义、标志、边界处理不当；应平衡性能与可读性，复杂场景优先用专用解析器。
JavaScript 中正则表达式不是“用不用”的问题，而是“怎么写对、怎么用稳”的问题。错一个标志位、漏一个转义、搞混 test() 和 match() 的返回值，就可能匹配不到、报错、或意外匹配太多。
正则字面量 vs new RegExp()：什么时候该用哪个？
字面量写法 /pattern/flags 更简洁，适合静态正则；new RegExp('pattern', 'flags') 适合 pattern 来自变量或需动态拼接的场景。
注意：new RegExp() 的第一个参数是字符串，所有反斜杠要双写 —— 比如想匹配 d+，得写成 new RegExp('\d+', 'g')，否则 'd' 在字符串里直接被解释为非法转义（JS 会报 SyntaxError: Invalid escape）。
常见误用：
立即学习“Java免费学习笔记（深入）”；
- 用字面量写动态内容：
const key = 'user'; const re = /{key}d+/; // 错！{} 不会被替换 - 拼接时忘了双写反斜杠：
new RegExp('w+') → 实际传入的是 'w+'，但字符串中 是退格符，不是单词边界
match()、exec()、test()、replace() 四个核心方法的区别
它们返回值和行为差异极大，混用容易出 bug：
-
str.match(/re/g)：有g标志时返回匹配字符串数组（无捕获组），没g时返回含index、input、groups的数组，可能为null -
re.exec(str)：每次调用返回下一个匹配（含捕获组），配合g可循环；不带g永远只返回第一个。注意：同一正则对象多次调用会维护内部lastIndex，容易状态混乱 -
re.test(str)：只返回true/false，但带g或y时也会修改lastIndex，连续调用可能结果翻转 -
str.replace(/re/g, 'x')：支持字符串或函数作为替换项；函数参数依次是匹配值、捕获组、索引、原字符串 —— 常用于提取+重构
示例：提取所有邮箱
const text = '联系 admin@site.com 或 dev@test.org';
const emailRe = /[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Z|a-z]{2,}/g;
console.log(text.match(emailRe)); // ['admin@site.com', 'dev@test.org']
// 注意：没 g 标志时 match 返回的是 ['admin@site.com', index: 8, input: '...', groups: undefined]
常见匹配失败原因：转义、标志、边界没处理好
很多“明明正则在线测试能过，JS 里却不行”，基本卡在这三类：
- 在 JS 字符串中写正则时，反斜杠被吃掉：比如想匹配路径
C: emp ile.txt，正则应为/C:\\temp\\file\.txt/（字面量）或new RegExp('C:\\temp\\file\.txt')（因为字符串一层、正则一层） - 忘了加
g标志：只调match()不带g，永远只拿第一个；用exec()循环又忘了重置lastIndex - 没考虑边界：用
/d+/匹配"abc123def456"会得到['123', '456']，但若想确保是独立数字（如排除abc123def中的123），得加或(?<=^|D)等零宽断言
特别注意：中文字符、emoji、Unicode 字符在正则中默认不被 w 或 匹配，需显式用 u 标志 + p{L} 等 Unicode 属性类。
性能与可读性平衡：别写“一行天书”正则
像 /^(?=.*[a-z])(?=.*[A-Z])(?=.*d)(?=.*[@$!%*?&])[A-Za-zd@$!%*?&]{8,}$/ 这种密码校验正则，JS 能跑，但难调试、难改、难交接。更稳妥的做法是拆成多个小检查：
function isValidPassword(s) {
return s.length >= 8 &&
/[a-z]/.test(s) &&
/[A-Z]/.test(s) &&
/d/.test(s) &&
/[@$!%*?&]/.test(s);
}
它比单正则慢不了多少，但每个条件含义清晰，出问题能快速定位是哪个规则没过。真正需要复杂匹配（如解析 Markdown 行、提取 URL 参数）时，再上完整正则，并配上注释说明每段意图。
最常被忽略的一点：正则不是万能胶。遇到嵌套结构（如 HTML 标签、括号配对）、上下文敏感内容（如引号内换行是否允许），优先考虑专用解析器，而不是硬怼正则 —— 后者后期维护成本远高于初期省下的几行代码。
