写好javascript正则的关键是匹配逻辑与边界条件可靠，需拆解原子规则、慎用标志、避免回溯灾难，并用真实数据反复验证。
JavaScript 正则表达式写得对不对，关键看 test()、exec()、match() 这几个方法是否返回你预期的结果——不是语法没错就行，而是匹配逻辑和边界条件都得压得住。
怎么写一个能真正用起来的正则？
别从「我要匹配邮箱」这种模糊目标开始，先拆成可验证的原子规则：
- 邮箱必须含一个
@，且前后都有非空字符 -
@前不能有空格、不能以点开头或结尾、不能连续两个点 - 域名部分至少含一个点，顶级域通常是 2–6 个字母
对应写出来就是：
/^[^\s@]+@[^\s@]+\.[a-zA-Z]{2,6}$/。注意这里没用 \w（它会匹配下划线，而邮箱本地部分通常不允许），也没用 .*（太宽泛，容易跨行或吞掉不该吞的内容）。
g、i、m 标志到底影响什么？
标志不是装饰，直接决定匹配行为：
立即学习“Java免费学习笔记（深入）”；
-
g：让exec()和match()能多次匹配；但test()用g时会维护lastIndex，连续调用可能跳过开头——这是最常踩的坑 -
i：只影响字母大小写，不影响 Unicode 字符（比如中文、emoji 不受它影响） -
m：只在开启多行模式后，才让^和$匹配每行首尾；否则它们只匹配整个字符串的开头和结尾
例如：
const re = /^start/gm; 'restart\nstart'.match(re); // ['start', 'start']，不是 ['restart', 'start']
为什么 match() 有时返回 null？
这不是 bug，是设计：当没匹配到，或用了 g 但没匹配到任何内容时，match() 就返回 null，而不是空数组。
- 想安全取结果，别直接解构：
const [full] = str.match(/.../) || [] - 全局匹配推荐用
matchAll()（返回迭代器），它不会返回null，而且带捕获组信息更全 - 如果只是判断存在性，用
test()更轻量，比match()快 2–3 倍（V8 引擎优化过）
示例：
const text = 'id:123 name:abc'; const re = /id:(\d+)/g; [...text.matchAll(re)][0][1]; // '123'，安全取第一个捕获组
性能差？多半是回溯炸了
像 /(a+)+b/ 这种嵌套量词，在遇到不匹配的字符串（如 'aaaaaaaaaa'）时，引擎会指数级尝试所有组合，导致卡死或超时。
- 避免嵌套量词：
(a+)+→ 改成a+ - 用原子组（JS 不支持）？改用先行断言：
(?=(a+))\1不现实，不如重构逻辑 - 长文本匹配前先用
includes()快速过滤，避免进正则引擎 - 用
RegExp.prototype.toString()检查是否意外创建了重复或过度复杂的正则
真正难的不是写出能跑的正则，而是写出在各种边界输入（空字符串、换行符、Unicode 表情、超长文本）下依然稳定、不慢、不崩的正则——这需要反复用真实数据验证，而不是只测一两个例子。
