JavaScript正则表达式是内建的编译型模式匹配引擎，需严格锚定首尾、注意Unicode支持与转义差异；字面量适合静态规则，RegExp构造函数用于动态模式；test()是布尔验证首选，避免match/exec误判；可维护性优于单行复杂正则。
JavaScript 中的正则表达式不是“字符串匹配工具”的泛泛概念，而是一套内建于语言的、支持编译执行的模式匹配引擎——它直接参与运行时逻辑，且对 Unicode、边界、捕获组等行为有明确规范，不能简单当成“搜关键词”来用。
正则表达式字面量 vs RegExp 构造函数，选哪个？
两者功能等价，但行为差异影响验证逻辑：
- 字面量写法：
/^\d{3}-\d{2}-\d{4}$/—— 每次引用都复用同一实例，适合静态、固定规则（如身份证号格式） -
RegExp构造函数：new RegExp('^' + userInput + '$')—— 适合动态拼接模式，但需手动双转义反斜杠（\\d），且每次调用新建实例，性能略低 - 注意：
RegExp对非法模式抛SyntaxError，而字面量在定义时就报错，调试更早暴露问题
test() 是验证字符串格式最常用的方法
别用 match() 或 exec() 做布尔判断——它们返回数组或 null，在 if 中容易因空数组被误判为真；test() 明确只返回 true/false：
const phoneRegex = /^\(?([0-9]{3})\)?[-.\s]?([0-9]{3})[-.\s]?([0-9]{4})$/;
console.log(phoneRegex.test('123-456-7890')); // true
console.log(phoneRegex.test('(123) 456.7890')); // true
console.log(phoneRegex.test('123456789')); // false
关键点：
- 必须加
^和$锚定首尾，否则'abc123def'也会通过/\d{3}/ - 如果要忽略大小写，用
i标志：/^[a-z]+$/i - 中文字符验证慎用
\w（它不匹配汉字），改用[\u4e00-\u9fa5]或[\p{Script=Han}]（需u标志）
常见验证场景中容易漏掉的边界条件
格式验证不是“看起来像就行”，而是要覆盖用户真实输入习惯和规范要求：
-
邮箱：
/^[^\s@]+@[^\s@]+\.[^\s@]+$/比 “包含 @ 和点” 严格得多，但依然不校验 MX 记录——前端验证只是防误输，不是替代后端校验 - URL：
https?:\/\/[^\s/$.?#].[^\s]*这类简版正则会放过http://..，真正健壮的方案应优先用URL构造函数尝试解析 - 密码强度：单靠正则难兼顾“至少一个大写+一个数字+长度≥8”，建议拆成多个
test()调用，比写一个超长正则更易读、易维护 - 空格处理：用户可能粘贴带首尾空格的手机号，验证前先
.trim()，否则/^\d{11}$/会失败
正则验证最常被低估的是「可维护性」——一个 50 字符的单行正则，半年后连自己都看不懂它到底允不允许中间有空格、是否接受全角数字。把复杂逻辑拆成多个小正则，或者配合 String.prototype.includes() 等基础方法组合判断，往往比追求“一行解决”更可靠。
