验证场景优先用 test()，它返回布尔值、语义清晰、性能略优；match() 返回数组或 null，适合提取内容而非校验，全局模式下空数组易致误判。
JavaScript 数据验证该用 test() 还是 match()？
直接结论：验证场景优先用 test()，它返回布尔值，语义清晰、性能略优；match() 返回数组或 null，适合需要提取匹配内容的场景，但用于单纯校验反而容易因返回值类型出错。
常见错误是写成 if (str.match(/^[a-z]+$/)) ——看似能用，但一旦正则带 g 标志，match() 在全局模式下可能返回空数组 []（非 null），导致条件误判为真。
-
test()始终返回true或false，和验证意图完全对齐 - 正则对象需复用：定义一次，多次调用
test()，避免重复编译开销 - 注意字符串为空时的行为：
""对/^.$/返回false，但对/^.*$/返回true，需按业务决定是否允许空
邮箱、手机号、密码强度——这些正则为什么总“漏判”或“误判”？
根本原因：用过于简化的正则替代真实业务规则。比如 /^\w+@\w+\.\w+$/ 会放过 a@b.c（合法语法但极可能无效），也拦不住 test@domain.co.uk（含点号的二级域名）。
更务实的做法是分层处理：
立即学习“Java免费学习笔记（深入）”；
- 基础格式校验用宽松正则（如邮箱：
/^[^\s@]+@[^\s@]+\.[^\s@]+$/），只筛掉明显非法输入 - 关键字段（如注册邮箱）必须配合后端验证，前端正则只是体验优化
- 手机号别硬套
^1[3-9]\d{9}$：国内号段持续更新，且要区分是否含区号、国际格式；建议用libphonenumber类库，或至少加inputmode="tel"和长度限制 - 密码强度不要只靠单个正则：用多个
test()分别检查大小写字母、数字、符号、最小长度，组合逻辑更可控
正则中的 ^、$ 和 \b 到底该不该加？
不加锚点（^、$）等于默认“子串匹配”，这在验证中几乎总是错的。例如：/abc/.test("xabcx") 返回 true，但你本意可能是要求整个字符串就是 "abc"。
正确做法取决于验证目标：
- 完整字符串匹配（如身份证号、固定格式编码）：必须用
/^xxx$/ - 关键词存在性检查（如“密码不能含 admin”）：用
/admin/即可，无需锚点 - 单词边界需求（如防止 “admin123” 被当成含 “admin”）：用
/\badmin\b/，注意\b只匹配位置，不消耗字符 - 中文文本慎用
\b：它基于 ASCII 单词边界，在中文里基本失效；改用(? 或直接前后加空格/标点判断
正则写出来跑不通？先查这三处
90% 的“正则无效”问题出在转义、标志位或字符串构造上，而不是逻辑本身。
- 字符串字面量中反斜杠要双写：
"\\d+"才等价于正则/\d+/；若用new RegExp("d+")，则不需要额外转义 - 忘记加
u标志处理 Unicode：匹配 emoji 或中文时，/^\w+$/会失败，应改为/^\w+$/u - 动态拼接正则易出错：避免
new RegExp("^[a-z]{" + min + "," + max + "}$")，特殊字符未转义会崩；改用模板字符串 + 字符类白名单，或直接函数校验
真正难的不是写出一个“看起来对”的正则，而是明确验证边界的粒度——是防用户手抖输错，还是替后端挡恶意输入？后者永远需要服务端兜底，前端正则只是第一道滤网。
