· 全部指南
什么时候该用正则
正则表达式适合「模式匹配」：邮箱格式校验、日志字段提取、URL 参数解析、批量替换文本。它不适合解析 HTML、JSON 或嵌套结构——这类场景应使用专用解析器。在 Towalles 的 regex-tester 中，你可以实时看到匹配高亮与捕获组，全部在浏览器本地完成，适合开发调试与面试复习。
一个实用原则：如果正则超过三行或需要递归，考虑换方案。简单校验（手机号、IP、日期）用正则很高效；复杂业务规则（订单状态机、权限树）应写在代码里，正则只做最后一道格式守门。
捕获组与替换
括号 () 创建捕获组，\1 或 $1 在替换时引用第一组。非捕获组 (?:...) 只分组不计数，适合 (?:https?://) 这类前缀。命名组 (?<name>...) 在 JavaScript 中可读性更好。测试时建议准备三组样例：应匹配、不应匹配、边界情况（空串、超长输入、Unicode 字符）。
贪婪 .* 与惰性 .*? 是初学者最常踩的坑：<div>.*</div> 会跨过多个标签匹配到最远的 </div>。日志清洗、HTML 片段提取时优先试惰性量词，或改用更精确的模式如 [^<]+。regex-memo 提供常用语法速查，配合 tester 边查边试效率最高。
性能与安全
灾难性回溯（ReDoS）发生在嵌套量词上，如 (a+)+$ 对超长输入 aaaa...X 会导致指数级回溯。生产服务应对用户输入的正则设超时或长度上限。JavaScript 引擎对多数日常模式足够快，但不要在热路径上对百万行日志逐行跑复杂正则。
永远不要把正则当作安全边界：「匹配了邮箱格式」不等于「邮箱属于该用户」。认证、授权、防注入应在服务端用成熟库完成。正则只负责格式；text-analyzer 可辅助统计匹配前后的文本变化量，用于评估替换规则的影响范围。
把正则当生产代码写
正则要评审、要有 fixture、要有性能测试。保持短小可组合。在旁注释引擎（JS/PCRE/RE2）与 flags。用 regex-tester 试验，再用 git 冻结样例。
警惕 ReDoS
嵌套量词叠在重叠字符类上，可能被恶意输入拖死线程。可用占有量词/原子组，或对不信任输入改用线性时间引擎，并在入口限制长度。
脱敏闭环
- 在 regex-tester 用脱敏日志起草。
- 替换预览 → 占位符。
- 二次扫描残留（或按 pii 思路）。
- 若文本进 LLM，只在去秘后做 token 计数。
优先写无聊的 pattern
可读的字符类胜过巧妙回溯。在边界限制输入大小。从日志抽字段时分层写，而不是一条巨型表达式。
测试负例
提交「绝不能匹配」的 fixture。多数生产正则缺陷是安静污染数据的误报。
关注 ReDoS
避免在用户可控文本上嵌套量词。若引擎提供线性时间模式，对不信任输入优先使用。
归属
每条生产正则在 PR 描述里都要有负责人与测试文件路径。无主 pattern 会腐烂成故障。
生产正则归属
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。