正则表达式测试

校验表单、解析日志、提取接口字段前; 先在工具里验证正则是否正确。

使用正则表达式测试器的典型场景包括：当您需要快速验证一个正则表达式是否匹配预期的文本模式时，直接在这里输入表达式和测试文本即可。例如，开发时检查邮箱格式的正则是否正确，或在处理日志时筛选特定错误信息。

操作流程很简单：1) 在顶部输入正则表达式；2) 在中间框粘贴测试文本；3) 实时查看匹配结果。匹配项会高亮显示，捕获组会单独列出。您还可以测试替换操作，这在批量修改文本时特别有用。

.* 贪婪匹配尽可能多；.*? 惰性匹配尽可能少。解析 HTML 或日志时，贪婪常吞掉过多内容导致捕获组为空。先用小样本验证，再应用到生产 regex。

多行模式 m 使 ^ $ 匹配行首行尾；s 使 . 匹配换行。flags 组合错误是日志解析失败主因。regex-practical-guide 深入讲解边界案例。

嵌套量词 (a+)+ 可能对长输入 catastrophic backtracking。生产环境对用户可控输入做 regex 时，限制输入长度或改用 parser。本工具适合开发验证，非服务端执行 untrusted pattern。

邮箱、URL 的「完美 regex」往往过度复杂；实用中 split validation：url-parser 拆 URL，uuid-generator 样例验证 UUID pattern。

替换预览适合批量脱敏日志：用捕获组保留结构、替换 email 为 [REDACTED]。确认替换结果后再跑 pii-scanner 二次检查。

与 json-formatter 无关但常串联：从 JSON 字符串提取字段值到 regex 测试文本。

流程：脱敏样本 → 单字段 pattern → 组合 → 负例测试 → 写入仓库 fixture。跳过负例是生产漏匹配的主因。与 regex-log-parsing-playbook 中的事故流程对齐，本工具负责交互式试验，git 负责冻结版本。

提取 JSON 后用 json-formatter 确认；URL 用 url-parser。需要讲解 flags 与 ReDoS 时链到 regex-practical-guide。

用替换预览把邮箱、Bearer、JWT 形串换成占位符后，再跑 pii-scanner。只依赖一个「完美」regex 脱敏并不够——模式总会漏。替换完成后再 token-counter，避免把密钥算进 prompt 预算。

大文件请先截取；浏览器卡顿时改用 ripgrep。生产引擎若为 RE2，避免依赖 JS 独有的回溯特性。

先为时间戳、level、service 写三个小 pattern 并分别用正/负例验证，再组合成整行表达式。一大段「万能 .*」难维护且易 ReDoS。提取后的 JSON 片段丢进 json-formatter；IP/URL 再分别用专用工具复核。

把样例日志（脱敏后）与期望捕获组写成表，作为 PR 附件。生产引擎若非 JS，在目标引擎复测同一套样例。

从 Python/PCRE 迁到 JS（或相反）时，重点核对：贪婪默认、行首行尾、命名分组、lookbehind、Unicode 类。在本工具用同一语料切换 flags 观察差异，并在注释中写明「目标引擎 + flags」。

禁止在工单里只丢「最终正则」不附样例。半年后无人能安全修改。配套阅读 regex-practical-guide 与 regex-log-parsing-playbook。

生产解析规则应像代码一样评审：PR 描述动机、附本工具截图或文本对照、列出新增负例。热更新正则要有回滚开关。把「看起来能跑」留在个人实验；仓库才是真相来源。

若正则用于脱敏，替换后必须二次 pii-scanner。再 token-counter，确保密钥未进入模型预算。