预编译 re.compile() 必须移至循环外，否则每次调用都会重新解析正则、构建nfa状态机，导致40%以上性能损耗；match() 与 search() 功能不同，应按匹配位置需求选用；避免滥用 .* 引发指数级回溯。
预编译 re.compile() 是提升大规模文本匹配速度最直接、收益最高的操作，不做它，其他优化基本白搭。
为什么必须把 re.compile() 移到循环外
每次调用 re.search() 或 re.match() 传入字符串模式时，Python 都会重新解析、构建 NFA 状态机——这不是缓存失效，是压根没缓存。在日志清洗、爬虫响应体遍历等场景下，这一步开销常占总耗时的 40% 以上。
- ❌ 错误写法：
for line in lines: m = re.search(r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}', line) - ✅ 正确写法：
ip_pattern = re.compile(r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}')，再在循环里用ip_pattern.search(line) - 若 pattern 来自用户输入拼接（如
r'ERROR:' + keyword + r':END'），必须加@lru_cache(maxsize=128)，否则缓存无效
match() 和 search() 别混用，边界意识决定性能底线
二者不是“快慢之分”，而是“是否做对事”。选错不仅逻辑出错，还会掩盖真实瓶颈。
- 验证 URL 是否以
https://开头：用pattern.match(text)，比pattern.search(text)快 3–5 倍（前者跳过非首字符） - 从 HTML 片段中找任意位置的
<a href="..."></a>：必须用search()或finditer()，match()永远失败 - 处理多行日志且时间戳总在行首时，配合
re.MULTILINE用pattern.finditer(log_text)，比逐行search()少建 10 万次字符串对象
别让 .* 拖垮整个匹配过程
.* 是回溯重灾区，不是“慢一点”，是可能卡死。它会让引擎先吞光全部文本再倒着吐，遇到嵌套标签或长字段极易触发指数级回溯。
- 反例：
r'<div>(.*)</div>'匹配'<div>a</div> <div>b</div>'会捕获整个字符串，回溯爆炸 - 正解：
r'<div>([^' —— 明确排除 <code>，无回溯、语义准、速度快 <li>非贪婪 <code>.*?是妥协方案，仍需线性扫描；仅当分隔符不固定（如自由文本中的引号包裹内容）才考虑它 - 固定分隔符场景（如日志中的
ERROR:.*?END）应改为r'ERROR:[^:]*:END'，把“任意字符”收缩为“非冒号字符”
真正影响性能的，从来不是正则写得多炫，而是有没有锚定边界、有没有控制回溯、有没有复用编译结果——尤其在 GB 级文本里，少一次重复编译，就少一次状态机重建；少一个 .*，就少一次潜在 hang 住的风险。
