严Phy我是在一个不算太正式的场合重新正视正则表达式的：当时有个刚入职不久的同事，在表单校验里为了判断手机号，写了一段十几次 indexOf 加 substring 的代码。代码能跑，但谁看了都头疼。我跟他说，你花十分钟把正则表达式基础过一遍，这个问题三行就能解决。半小时后他回来，第一句话是：这种模式描述也太好用了，为什么我之前一直躲着它。
这个场景在前端开发里太常见了。很多人把正则当成一门晦涩难懂的语言，觉得面试八股才需要背，日常开发能复制粘贴就复制粘贴。但实际上，正则表达式就是一套“描述字符串形状”的语法。只要你输入的是一段文本，需要判断它是否合法、从中提取信息、或者批量替换内容，正则都是前端工具箱里性价比最高的一件工具。这篇文章不搞学院派那套，也不追求把正则的所有边角语法堆给你，而是站在前端日常开发和面试实战的角度，把正则拆成一个能直接上手的知识体系：它到底在解决什么问题、必会的语法有哪些、手机号邮箱密码这些高频写法怎么推导出来、以及那些让老手都翻过车的坑。
如果你正在学前端、准备跳槽面试、或者写表单校验已经复制粘贴到怕了，这篇内容值得你花十五分钟读一遍，最好跟着敲一遍。
1. 真正理解正则：它解决的是“怎样描述一类字符串”的问题
1.1 正则不是一门语言，而是一种匹配思维
很多人第一次接触正则，会被 ^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$ 这种长串吓到，下意识觉得这是一门外语。其实它的运行逻辑极其朴素：你给出一个“模式”，引擎拿着这个模式去目标字符串里做匹配，回答两个问题——“符合条件吗”和“哪里符合”。
这和你在地址簿里找人是一个道理。你说“找姓张、名字两个字的”，人脑会自动处理模糊匹配；但对计算机来说，你必须给它一套精确规则。^张\w$ 就是这套规则：以“张”开头，后面跟一个任意“字类”字符，然后结束。它不关心具体是“张伟”还是“张强”，它关心的是形状。
前端开发者尤其需要建立这种思维，因为前端处理的东西本质上都是字符串：接口返回的 JSON、用户输入的手机号、URL 上的 query、textarea 里的整段文本。你多掌握一点字符串形状的描述能力，就少写一堆垃圾判断代码。
1.2 前端三点一线：匹配、提取、替换
正则的能力，归纳起来就三件事：
- 匹配：判断一个字符串是否符合规则，比如校验手机号、邮箱；
- 提取：从一段杂乱文本里抓出符合规则的片段，比如从长文本里抓出所有手机号；
- 替换：把符合规则的片段替换成别的内容，比如把用户输入的连续空格统一成单个空格、脱敏手机号中间四位。
这三个需求对应到 JS 的 API，分别是 RegExp.prototype.test()、String.prototype.match() / RegExp.prototype.exec()、String.prototype.replace()。很多刚入门的朋友搞不清这些 API 的差别，本质上就是没想明白自己到底要做“匹配”还是“提取”还是“替换”。
举一个我正在用的例子：运营传了一个包含大量联系方式的 CSV 片段，需要前端展示前给手机号脱敏。原始文本可能是：
code复制张三 13812345678 李四 13911112222
要提取手机号，用 /\b1[3-9]\d{9}\b/g 去 match；要脱敏，就在 replace 里配合捕获分组写成：
javascript复制text.replace(/\b(1[3-9]\d)\d{4}(\d{4})\b/g, '$1****$2')
懂了这个三分法，几乎所有的正则使用场景都能归位。
1.3 从需求到正则的翻译模型
我在带人写正则时，总结了一个特别管用的“翻译模型”：先把中文需求拆成三个要素。
- 固定部分：必须出现的字面字符，比如手机号必须是数字1开头；
- 可变部分：某一段长度不确定、字符类型不确定，比如手机号后面可以跟9位数字；
- 边界部分：匹配到哪里结束，避免把“1381234567890 秒杀价”里的手机号误判成 13 位。
拿“13 位数字手机号码正则表达式”这个很多人搜过的需求来说。你要的不是“13 位数字”，而是“以 1 开头，第二位在 3-9 之间，后面跟 9 位数字”的 11 位号码。如果只写 ^\d{13}$，用户输入任意 13 位数字都会通过，那校验等于没做。这就是翻译需求时最常见的错误：只看到了“数字”和“位数”，没看到号码本身的构成规则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 前端必会的正则语法地图：从字符、量词到断言
这一节我用的是“地图”思路，不会事无巨细地把所有元字符都讲一遍，而是按前端实际使用频率，把语法分成四个区块。每块记住几个关键点，其余用到查表就好。
2.1 字符匹配：字面量、字符类与简写
正则最基本的能力是匹配单个字符。a 就是匹配字母 a，5 就是匹配数字 5，这是字面量匹配，没有技术含量。真正的威力来自字符类（character class），它用方括号表示“这一位允许出现哪些字符”。
前端最常用的一组字符类我整理成了这张表：
| 写法 | 含义 | 等价类 | 典型场景 |
|---|---|---|---|
[0-9] |
任意数字 | \d |
手机号、金额 |
[a-zA-Z] |
任意字母 | 无简写，等价 \d 之于数字 |
用户名、验证码 |
[a-zA-Z0-9_] |
字母数字下划线 | \w |
变量名、单词 |
\s |
空白：空格、Tab、换行 | [\t\n\r\f ] |
去除空白、分词 |
. |
除换行外的任意字符 | 无 | 兜底匹配、日志解析 |
[^...] |
排除字符类 | 无 | 禁止特殊字符 |
使用 \d、\w、\s 这类简写，代码更短，但要注意它的语义边界。\d 在 JS 里默认只匹配 ASCII 数字 0-9，不会匹配阿拉伯文数字、全角数字。这一点处理国际化表单时经常踩坑，后面我会专门展开。
2.2 量词：精确次数与“贪婪/懒惰”的博弈
字符类解决的是“这一位是什么”，量词解决的是“这一位出现多少次”。正则里的量词一共六个：
{n}：前面字符恰好出现 n 次；{n,}：至少 n 次；{n,m}：出现 n 到 m 次；+：1 次或多次，等价于{1,}；*：0 次或多次；?：0 次或 1 次，等价于{0,1}。
真正值得展开的是“贪婪 vs 懒惰”。默认情况下，量词是贪婪的，它会尽可能多地匹配字符。比如对字符串 "a123b456c" 执行 /a.+b/，匹配结果是 a123b，贪婪匹配会从第一个 a 一路吃到最后一个 b，但它不会跨越到第二个 b，因为正则的回溯机制决定了它在找到第一个 b 后，尝试验证后续是否能满足整体匹配，如果满足就结束。
如果你只想匹配 a123b 中尽可能少的内容，就在量词后面加个问号，写成 /a.+?b/。对于同样一段字符串，它匹配的是从 a 到后面最近的 b。前端处理 HTML 标签、日志关键字提取时，懒惰匹配几乎是标配，否则很容易“多吃”一段。
2.3 位置与断言：不占字符的锚点
正则里有一类特殊结构，它匹配的不是字符，而是位置。最有名的三个是 ^、$ 和 \b。
^ 表示字符串开头，$ 表示字符串结尾。/^abc/ 要求字符串必须以 abc 开头；/abc$/ 要求必须以 abc 结尾。两个合用 /^abc$/，就是严格匹配整个字符串等于 abc。这就是为什么手机号正则一定要写 ^ 和 $，否则中间那串数字出现在一长段文本里也能被匹配出来。
\b 是单词边界，表示“单词字符”和“非单词字符”之间的位置。它特别适合做整词提取。比如提取字符串里的 cat，但不希望匹配到 category。用 /\bcat\b/，category 里的 cat 前后都不是边界，就会被自动排除。
再往上是零宽断言：(?=...)（前瞻）、(?!...)（负前瞻）、(?<=...)（后顾）、(?<!...)（负后顾）。名字听着唬人，逻辑很简单：它要求在某个位置后面（或前面）必须出现（或不出现）某种内容，但它本身不消费字符。前端处理密码规则时很容易用到，比如要求密码里必须包含数字，就是 (?=.*\d)。
2.4 分组与引用：括号不只是分组
括号在正则里有两层作用：一是改变优先级，把一整个片段当成一个整体，比如 (ab)+ 表示 ab 这个组合连续出现多次，而不是 a 后面跟 b 的若干次；二是产生“捕获组”，引擎会把括号内匹配到的内容单独存起来，供后续提取或替换使用。
捕获组最常见的用法就是上面提过的手机号脱敏。/(1[3-9]\d)\d{4}(\d{4})/ 有两个捕获组，replace 时通过 $1 和 $2 取出原内容。如果你需要提取文本里所有 URL 的协议、域名、路径，分组加 matchAll 基本是最优解。
有时候括号只是为了分组，不需要捕获内容，那就用非捕获分组 (?:...)。它的好处是性能更好，也不会污染编号。多个捕获组混在一起时，编号很容易数错，教训就是：能不用捕获组就别用，用了就给它起名字（命名捕获组 (?<name>...)），尤其是正则复杂度上来以后。
3. 高频场景拆解：手机号、邮箱、密码强度这些写法到底怎么来
很多人看过很多正则表，一到写真实校验就懵。原因是你总在“背答案”，没有练过“从需求推写法”的过程。这一章我把前端最常遇到的几个校验场景完整拆一遍。
3.1 手机号正则：从最简到可用
先限定国内 11 位手机号。需求拆解：
- 必须以 1 开头；
- 第二位目前开放的是 3-9；
- 后面 9 位可以是任意数字。
于是得到：
javascript复制const phoneReg = /^1[3-9]\d{9}$/
这个写法基本可以覆盖国内主流号码。注意几个演进细节：
- 以前很多老代码写
^1[3|5|7|8|9]...，把第二位限死在某些号段。现在运营商新号段越来越多，再做白名单意义不大，直接用[3-9]更稳妥； ^\d{11}$是最低级的写法，它会放过“99999999999”这种完全不可能是手机号的串，不推荐；- 前置的
^和后置的$一定要写，它们是防止“从长文本中误匹配”的防线。
如果你要处理“输入的字符串里有空格或短横线”，比如用户复制来的 138 1234 5678，那就要在正则里显式处理：
javascript复制const phoneReg = /^1[3-9]\d{9}$/;
const input = '138 1234 5678'.replace(/\s+/g, '');
通常的做法是先清洗再校验，不在正则在硬塞复杂规则，逻辑更清晰。
3.2 邮箱正则：该松就松，该紧就紧
邮箱正则是前端校验里争论最多的地方。网上流传的各种“完美邮箱正则”，动不动上百字符，非要按 RFC 5322 把整个标准实现一遍。但现实是：用户在绝大多数场景根本不需要那么严格的校验。
我推荐的是一个均衡型写法：
javascript复制const emailReg = /^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$/
拆解一下：
[a-zA-Z0-9_.+-]+：邮箱本地部分，允许字母数字以及_ . + -，至少一位；@：固定分隔符；[a-zA-Z0-9-]+：域名主体，字母数字和短横线；\.：点号需要转义，因为.在正则里有特殊含义；[a-zA-Z0-9-.]+：顶级域名部分。
这个正则允许 test+a@example.com、nice.name@sub.example.org 等常见格式，又不会把明显不合理的 @@abc 放进来。没必要去校验顶级域名是不是真实存在，那应该交给后端和验证邮件来做，前端只需要拦截明显错误的输入。
3.3 密码强度校验：把规则拆成多个小正则
密码强度校验如果试图用一个巨型正则解决，很快就会变成不可维护的天书。更好的做法是拆成多个可读的小判断：
需要满足：至少 8 位；包含大小写字母；包含数字；可选的包含特殊字符。
javascript复制const hasUpper = /[A-Z]/;
const hasLower = /[a-z]/;
const hasDigit = /\d/;
const hasSpecial = /[!@#$%^&*(),.?":{}|<>]/;
const score = [hasUpper, hasLower, hasDigit, hasSpecial]
.filter(reg => reg.test(password)).length;
const valid = password.length >= 8 && score >= 3;
用测试每个独立规则的思路，后期想调整“必须有特殊字符”还是“三选三满足即可”，只需要改动一行条件，而不是去解谜一个 60 字符的长正则。
3.4 身份证、URL、IPv4 等实用案例
身份证号的格式校验，前端一般只做位数和末位字符检查：18 位，前 17 位数字，末位可能为数字或 X（大小写不敏感）。
javascript复制const idReg = /^\d{17}[\dXx]$/
URL 的校验要区分是“必须完整 http(s) 链接”还是“宽松识别 www 开头”。完整链接我常用：
javascript复制const urlReg = /^https?:\/\/[\w-]+(\.[\w-]+)+([\w.,@?^=%&:/~+#-]*)$/
IPv4 四段地址，用正则逐个段限制会清晰很多：
javascript复制const ipv4Reg = /^((25[0-5]|2[0-4]\d|1\d{2}|[1-9]?\d)\.){3}(25[0-5]|2[0-4]\d|1\d{2}|[1-9]?\d)$/
这里用到了 0-255 的分段表达，是一个很经典的分支结构练习。写多了会对“正则里分支的优先级”有更深的体会。
4. 那些让前端栽过跟头的正则陷阱
4.1 一个斜杠引发的血案：转义与斜杠地狱
正则本身有元字符，比如 .、+、*、?、(、)、[、]、{、}、^、$、\、/。当你要匹配这些字符本身时，必须用反斜杠转义。
前端更麻烦的是：正则可以写在 /.../ 字面量里，也可以写在 new RegExp('...') 构造函数里。构造函数里传的是字符串，而字符串本身也有一套转义规则。于是经常出现“写一层转义不够，一报错又加一层”的悲剧。
一个经典例子：匹配一个小数点。字面量写法是 /\./，构造函数写法必须是 new RegExp('\\.')。你会看到字符串里有双反斜杠，因为正则层需要 \.，而 JS 字符串层要把这个反斜杠本身表达出来，就得再转义一次。
再说一个匹配斜杠本身的例子。URL 里常见 https://，要匹配它：
javascript复制const reg1 = /https:\/\//; // 字面量
const reg2 = new RegExp('https://'); // 错了，字符串里没转义
const reg3 = new RegExp('https:\\/\\/'); // 对了，正则层的 \/ 在字符串里写成 \\/
这种“双重转义”是最容易让新手崩溃的地方。我的建议是：能用字面量就尽量用字面量，只有在正则需要动态拼装时才用构造函数，而且写完后一定在浏览器控制台里打印一遍 reg 出来核对。
4.2 死循环与灾难性回溯
正则性能问题在纯前端场景里不如后端那么致命，但一旦出错，可以直接卡死浏览器 Tab。
问题出在“嵌套量词 + 不匹配”的组合。比如这个经典例子：
javascript复制const dangerous = /^(a+)+$/
如果用它对 "aaaaaaaaaX" 做 test，引擎会尝试各种方式把字符串喂给 (a+)+ 这个嵌套结构，发现最后那个 X 匹配不上，再做回溯，然后把一个个小分组拆开重新组合，继续匹配。字符串每增加一个 a，回溯次数会呈指数级增长。这就是灾难性回溯（catastrophic backtracking）。
我在处理富文本输入美化时，曾经用过一个比较复杂的正则去匹配整段 Markdown 标题符号，当时只在小样本上测试没问题，结果用户粘贴了一篇上万字的文章，页面直接无响应。后来定位到就是嵌套贪婪量词导致的。
避免办法很朴素：少写嵌套无限量词；实测时一定要用长文本压一遍；复杂校验拆成多个小正则，不要指望一个大正则应万变。必要的时候还可以用在线工具分析回溯步数。
4.3 全角半角、中文与 Unicode：前端特有的字符问题
中文字符匹配是前端特别容易踩的坑。在传统写法里，匹配中文一般写 [\u4e00-\u9fa5]，这是 CJK 统一汉字的常用范围。大多数场景足够用，但它不是一个覆盖所有汉字和扩展区的权威方案。
更好的做法是使用 Unicode 属性，不过需要开启 u 修饰符：
javascript复制const chineseReg = /\p{Script=Han}/u;
这个写法能识别更完整的汉字体系，代码语义也更清晰。
还有个冷门问题：全角数字、全角字母、中文标点和英文标点混在用户输入里。\d 默认不匹配全角数字，\w 也不匹配全角字母。处理国际化表单时，要么在输入层统一做半角转换，要么显式使用 Unicode 属性来匹配，别假设用户输入是标准的 ASCII。
4.4 test() 的 lastIndex 坑：全局匹配的隐藏状态
这个坑隐藏得很深。如果你给正则加了 g 修饰符，同一个正则对象反复调用 test()，结果会“抽风”。
javascript复制const reg = /abc/g;
console.log(reg.test('abc')); // true
console.log(reg.test('abc')); // false
console.log(reg.test('abc')); // true
原因就是 g 修饰符会让正则对象维护一个 lastIndex 状态，每次匹配结束后把位置往后移，第二次 test 时是从上一次结束的位置继续找，而不是从头开始。
解决办法：如果只是判断是否存在，就用不带 g 的正则；如果必须带 g，每次 test 前手动把 lastIndex 归零，或者改用 String.prototype.includes() 等字符串方法。这个 bug 在列表循环校验时非常不显眼，经常是“为什么第一次校验成功，第二次就失败”的终极答案。
5. 正则与前端代码的配合：JS 里那四个 API 怎么用才算到位
5.1 String 家族的 match、matchAll、replace、split、search
正则的语法本身再熟练，最终还是要落到 JS API 上。我见过不少同事，正则会写，但不知道用哪个方法取结果，最后硬是用 replace 去“曲线救国”。这五个方法的分工其实是清清楚楚的：
| 方法 | 作用 | 返回结果 | 注意事项 |
|---|---|---|---|
str.match(regexp) |
匹配结果 | 非全局时返回第一个匹配及分组；全局时返回所有完整匹配 | 非全局和全局返回结构不同 |
str.matchAll(regexp) |
迭代所有完整匹配及分组 | 迭代器 | 必须带 g，ES2020 引入 |
str.replace(regexp, replacer) |
替换匹配内容 | 新字符串 | 全局替换必须带 g |
str.split(regexp) |
按匹配位置拆分成数组 | 数组 | 比 split(',') 灵活 |
str.search(regexp) |
查找匹配的起始位置 | 索引或 -1 | 不关心匹配内容 |
最值得多提一句的是 matchAll。以前想提取文本里所有符合条件的片段并拿到捕获组，只能用 exec 配合循环，写起来又臭又长：
javascript复制const reg = /(1[3-9]\d{9})/g;
let match;
while ((match = reg.exec(text)) !== null) {
console.log(match[1]);
}
现在可以这样：
javascript复制const matches = [...text.matchAll(/(1[3-9]\d{9})/g)];
matches.forEach(m => console.log(m[1]));
matchAll 返回的每一项包含了完整匹配、捕获组、索引等完整信息。它让“提取一堆符合规则的片段”这件事变成了标准的流式处理。
5.2 replace 中的 $1 与函数回调：动态替换怎么选
replace 是唯一同时支持“字符串”和“函数”做替换内容的方法，这个设计非常巧妙。
字符串替换适合“格式重组”场景，配合捕获组引用：
javascript复制'2024-05-06'.replace(/(\d{4})-(\d{2})-(\d{2})/, '$2/$3/$1');
// "05/06/2024"
函数替换适合“根据匹配内容动态决定新值”的场景。比如把文本中的数字乘以 100：
javascript复制'商品价格 10 元'.replace(/\d+/, match => Number(match) * 100);
// "商品价格 1000 元"
函数接到的参数依次是完整匹配、各个捕获组、匹配位置、原始字符串。记不清参数顺序没关系，大多数情况你只需要第一个参数。需要分辨捕获组时，再数后面的位置。我的习惯是：只要替换结果依赖匹配内容本身，都优先用函数，可读性远高于嵌套的字符串拼接。
5.3 在 Vue/React 表单校验中如何组织正则
正则写好了，放在什么位置、怎么组织，也是项目里容易乱的地方。
我的做法是建立独立的 validators.js 模块，把正则和校验函数全部沉淀下来，而不是散落在各个组件的 handleSubmit 里。每个校验函数输出统一的错误消息，组件里只需要调用并展示。
javascript复制// validators.js
export const phoneReg = /^1[3-9]\d{9}$/;
export const emailReg = /^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$/;
export function validatePhone(value) {
if (!value) return '手机号不能为空';
if (!phoneReg.test(value)) return '手机号格式不正确';
return '';
}
export function validateEmail(value) {
if (!value) return '邮箱不能为空';
if (!emailReg.test(value)) return '邮箱格式不正确';
return '';
}
这样的好处非常明显：同一个校验规则在注册页、联系页、结算页被复用的时候，永远只有一份来源。后端的 Java、Python 校验规则如果也需要同步，也可以按同一套正则去维护，团队沟通成本会低很多。
6. 面试与实战中真正有用的正则思维
6.1 面试必背的几类手写题
前端面试里的正则题，很少让你背语法，更多是现场手写处理函数。以下几个高频题目覆盖了正则八成的高频考点，每个都值得亲手练一遍。
第一题：去除字符串首尾空格。最简单的方式：
javascript复制str.replace(/^\s+|\s+$/g, '')
这题考的是 ^ 和 $ 与“或分支”的结合。
第二题：判断字符串是否为回文。
javascript复制const isPalindrome = s => {
const clean = s.toLowerCase().replace(/[^a-z0-9]/g, '');
return clean === clean.split('').reverse().join('');
};
正则在其中负责清洗非字母数字字符，这是它与数组反转配合的经典例子。
第三题：驼峰转短横线命名。
javascript复制'fooBarBaz'.replace(/[A-Z]/g, m => '-' + m.toLowerCase());
// "foo-bar-baz"
这题考的是 replace 函数回调，非常实用。
第四题：提取字符串中所有数字。
javascript复制'abc123def456'.match(/\d+/g); // ["123", "456"]
这题是 match 配合 g 的基础用法。
第五题：校验必须同时包含字母和数字。
javascript复制const isValid = /^(?=.*[a-zA-Z])(?=.*\d).+$/;
这题考察零宽断言，是正则面试题的进阶常客。
6.2 用正则 vs 用代码：什么时候别迷信正则
写了多年正则之后，我最大的体会是：正则不是万能的，而且很多时候不该是首选。
判断一个字符串里括号是否配对，正则做不到，应该用栈。解析 HTML 片段，正则很容易因为标签嵌套而出错，简单场景可以用正则抓标签，复杂场景直接上 DOM 解析。提取 JSON 中的特定字段，直接 JSON.parse 后按对象访问，比正则又快又稳。
正则适合的是“字符级模式清晰、结构有限”的场景。一旦模式需要递归、等长平衡、大量嵌套，就应该停下来想想是不是用代码逻辑更合适。开发效率不是“能用一个正则搞定”的炫技，而是选择最不容易出错的方案。
我在代码评审里反复强调一个原则：正则是“规则描述”，不是“状态机”。 凡是需要对内容进行计数、叠加、嵌套分析的场景，拆分到普通代码里做，每个判断都清清楚楚，测试也更好写。
6.3 测试与调优：像调参数一样调正则
写完一个正则，不要觉得“看起来对”就收工。对待正则应该像对待业务逻辑一样有测试用例。
我自己有一个固定套路：先写 3 条应该通过的、3 条应该拒绝的用例，还有 2 条边界用例。比如手机号正则的用例：
javascript复制expect(phoneReg.test('13812345678')).toBe(true); // 常见手机号
expect(phoneReg.test('19812345678')).toBe(true); // 新号段
expect(phoneReg.test('10012345678')).toBe(false); // 第二位是 0
expect(phoneReg.test('23812345678')).toBe(false); // 不是 1 开头
expect(phoneReg.test('1381234567')).toBe(false); // 只有 10 位
expect(phoneReg.test('138123456789')).toBe(false); // 12 位
调试时，我用得最多的是 regex101 这类在线工具。它能把每个字符的匹配过程高亮出来，还能显示贪婪回溯的步数。肉眼看到匹配路径，比在脑子里空想快得多。生产环境还要注意控制输入长度，避免用户粘贴超长文本导致回溯激增。
正则调优的另一个维度是“少写”。能用 /\d+/ 就不要用 /[0-9]+/，能用 /(?:ab)+/ 就不要用 /(ab)+/ 去制造无意义的捕获组。捕获组太多，不仅匹配时多消耗内存，后续处理里编号也容易错乱。每次写完正则回头扫一眼，把所有用不到的捕获组都改成非捕获形式，是一个性价比很高的习惯。
最后分享一个实践中的小技巧：正则表达式在前端代码里是典型的“可读性洼地”，再熟练的老手，三个月后回看自己写的一段复杂正则也要重新推演。所以只要正则超过一定长度，我都会留下一行注释，写清楚这段正则到底在匹配什么、覆盖了哪些边界。这个习惯经常在项目交接和排障时帮我节约大量时间。你也可以从今天开始，把手头项目里那些“天书正则”加上注释，你会发现不仅是别人，包括你自己的维护体验都会上一个台阶。