正则表达式总匹配不对？按这套流程拆开排查
不是再给一堆正则模板，而是讲怎么调正则：从样例、锚点、贪婪匹配、分组、替换到上线前测试，适合经常处理文本的人。
相关工具
先准备样例，不要直接写表达式
正则调不好，很多时候不是语法不会，而是样例太少。你应该先准备三类文本：一定要匹配的、一定不能匹配的、边界情况。比如提取订单号，就要准备正常订单号、带空格的订单号、中文说明里的订单号、错误位数、多个订单号同一行。样例越接近真实数据，正则越不容易上线后翻车。
把样例放进正则工具里，一边写一边看高亮结果。不要在代码里反复运行才知道错在哪。工具里的实时匹配、分组展示、替换预览，比肉眼看控制台输出省时间。
锚点和边界决定匹配范围
^ 和 $ 经常被忽略。^ 表示开头，$ 表示结尾。如果你要校验整个输入，就应该加锚点；如果你只是从一段文章里提取内容，就不应该强行加锚点。比如校验 6 位验证码：
^\d{6}$如果写成 \d{6}，文本 abc123456xyz 里也能匹配到 123456。校验和提取是两个不同场景，表达式也应该不同。\b 这种单词边界也要谨慎，中文和英文的边界规则并不完全一样。
贪婪匹配是很多问题的根源
点号加星号 .* 会尽可能多地吃掉内容，所以很容易匹配过头。比如你想提取两个引号之间的内容，直接写 ".*"，在一行里有多个引号时可能从第一个引号匹配到最后一个引号。更稳的是用非贪婪匹配：
".*?"但非贪婪也不是万能。遇到嵌套结构、转义字符、跨行文本时，正则会变复杂。能用 JSON、HTML、CSV 解析器解决的问题，不要硬用正则解析。正则适合处理规则明确的文本片段，不适合完整解析复杂格式。
替换前先预览，批量处理要留日志
正则替换很强，也很危险。批量清理文章、日志、表格字段时，先用工具预览匹配结果，再执行替换。特别是删除内容时，要确认匹配范围没有跨过段落或把正常内容一起吃掉。替换完成后，用文本对比工具看差异，能快速发现误删。
如果你用脚本批量处理文件，建议先输出 dry run 结果，也就是只打印将要替换的内容，不真正写入文件。确认后再执行。这个习惯能避免很多不可逆的内容事故。
常见问题
正则匹配太多怎么办？
先检查是否缺少 ^、$、边界条件，或者用了过于宽泛的 .*。
什么时候不适合用正则？
解析 JSON、HTML、CSV、XML 这类有正式结构的内容时，优先用专门解析器。
批量替换前要做什么？
先预览匹配结果，保留原文或差异记录，再执行真正替换。