匹配列表
| # | 匹配内容 | 索引位置 | 捕获组 |
|---|
替换预览
五个开关各自管什么
i 忽略大小写；g 全局匹配（不勾就只找第一处）；m 多行模式，让 ^ 和 $ 匹配每一行的行首行尾；s 让点号也能匹配换行；u 开启 Unicode 模式，处理中文、emoji 和 \p{...} 这类属性转义时基本都要勾。
内部扫描时会强制加上 g 才能逐条枚举，但展示层面仍按你勾选的语义来 —— 没勾 g 就只列第一个匹配，跟代码里的实际行为保持一致，不会出现「页面能匹配到但代码里匹配不到」的错觉。
替换框里能写什么
替换预览支持原生语法：$1、$2 取捕获组，$& 取整个匹配，$<name> 取命名分组。命名分组在正则里写成 (?<year>\d{4})，替换时就能用 $<year> 引用。
替换框为空时点复制，复制出来的是匹配结果的表格（序号、内容、位置区间、捕获组），可以直接贴进表格软件；填了替换内容则复制替换后的结果。
两道保护，避免把浏览器卡死
待匹配文本超过 20 万字符会提示可能卡顿；匹配结果上限 5000 条，超过就停止枚举并告诉你实际数量。这两个阈值是为了接住「.*」这类容易写出灾难性回溯的写法。
三个输入框都有约 120 毫秒防抖，改正则或改文本时不会每敲一个字符就全量重扫一遍。
内置示例只做通用匹配，别当校验器
页面给了 10 个常用正则（手机号、邮箱、IP、身份证等）做起点，它们匹配的是「格式形状」，不是严格校验：IPv4 那条不判断每段是否 ≤255，身份证那条不校验最后一位校验码，日期那条不判断 2 月有没有 30 号。
真要做准入校验，请在后端用权威库再过一遍。前端正则的作用是提前挡掉明显的输入错误，不是做最终裁决。
敏感文本可以就地测试
匹配、高亮、替换预览全部用浏览器原生 RegExp 在本地完成，没有网络请求。日志片段、含手机号或身份证号的样本文本可以直接粘进来调正则，不用先脱敏。
正则写错时不会清空上一次的高亮结果 —— 改的过程中界面始终是可读的，不会闪成一片空白。
语法边界
只支持 JavaScript 的正则语法。其他语言里的专有写法（Python 的 (?P<name>)、PCRE 的一些扩展）在这里不一定认，命名分组请用 JS 的 (?<name>)。
嵌套捕获组重叠时，高亮只标出先命中的那个 —— 这是实现上的取舍，不影响匹配结果本身。极老的浏览器对后行断言 (?<=...) 支持不全，遇到报错先查浏览器版本。
常见问题
为什么没勾 g 只显示一个匹配？
这就是原生语义：不带 g 的正则只匹配第一处。内部扫描虽强制加 g 以枚举，但展示按你勾选的语义来，避免和代码里的实际行为不一致。
内置的身份正则能直接用来校验吗？
不能当最终校验。它只匹配格式形状，不校验校验位；手机号、邮箱同理。正式校验请在后端用权威库完成。
文本很长时会卡吗？
超过 20 万字符会给出提示，匹配结果上限 5000 条。若明显无响应，多半是正则本身存在灾难性回溯，先简化写法。