预编译正则表达式必须在循环外进行，使用re.compile()可节省30%–60%匹配开销；动态pattern需配合@lru_cache；match()仅匹配开头，search()扫描全文；避免贪婪匹配.*，优先用[^]等否定字符集。
预编译必须做，且不能放在循环或高频函数里——这是最直接有效的提速手段，能省掉 30%–60% 的匹配开销。
re.compile() 必须在循环外预编译
每次调用 re.search() 或 re.match() 时，如果传入的是字符串而非已编译的 re.Pattern 对象，Python 就会重新解析、编译正则——哪怕模式完全一样。日志清洗、爬虫响应体批量处理这类场景下，性能差距肉眼可见。
- ❌ 错误写法：
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}')；for line in lines: m = ip_pattern.search(line) - 动态 pattern（如用户输入拼接）必须加
@lru_cache，否则缓存失效等于白优化
match() 和 search() 选错会拖慢又逻辑错
re.match() 只检查开头，re.search() 扫全串。二者语义不同，强行混用不仅匹配失败，还会掩盖真实性能问题。
- 验证 URL 是否以
https://开头 → 用match()，快且语义准 - 从 HTML 片段中找任意位置的
href=→ 必须用search()或finditer() - 行首时间戳（如
^\d{4}-\d{2}-\d{2}）配合re.MULTILINE用finditer()，比逐行search()更简洁高效
贪婪匹配 .* 是回溯陷阱重灾区
.* 看似省事，实际是多数正则 hang 死的根源：引擎先吞光所有字符，再逐个吐出尝试后续匹配，长文本+嵌套结构极易触发指数级回溯。
- 反例：
r'<div>(.*)</div>'遇到<div>a</div> <div>b</div>会错误捕获整个字符串 - 优先用否定字符集：
r'<div>([^' 或更稳的 <code>r'<div>([^'<li>固定分隔符场景（如 <code>ERROR:.*?END）→ 改用r'ERROR:[^:]*:END'，避免模糊扫描
真正卡顿往往不出现在正则写法本身，而出现在“以为编译了一次，其实每次都在重编”或者“用 search() 去干 match() 的活”这种隐性错误上——这些地方不报错，但数据量一上来就暴露。
