预编译正则可提升40%以上性能；match()仅匹配开头，search()扫描全文；避免.*回溯，优先用否定字符集。
re.compile() 必须在循环外预编译
每次调用 re.search() 或 re.match() 时传入字符串模式，Python 都会重新解析、编译正则——这不是“缓存失效”，而是根本没缓存。在日志清洗、爬虫响应体遍历等高频场景下，这一步开销能占匹配总耗时的 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}'); for line in lines: m = ip_pattern.search(line) - 若 pattern 来自用户输入或拼接（如
r'ERROR:' + keyword + r':END'），必须加@lru_cache(maxsize=128)缓存编译结果，否则缓存形同虚设
match() 和 search() 别混用，边界意识决定性能底线
re.match() 只检查开头，re.search() 扫全串——二者不是“快慢之分”，而是“是否做对事”。用错不仅逻辑出错，还会掩盖真实瓶颈。
- 验证 URL 是否以
https://开头：用pattern.match(text)，比pattern.search(text)快 3–5 倍（前者直接跳过非首字符） - 从 HTML 片段中找任意位置的
<a href="...">：必须用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'，把“任意字符”收缩为“非冒号字符” - 所有正则字面量必须用
r''，哪怕只含\.或\d - 不需要提取子串时，用非捕获组
(?:...)替代(...)，避免生成Match.group()对象 - 测试阶段用
timeit.timeit()对比：带捕获组的r'(\d{4})-(\d{2})'比r'(?:\d{4})-(?:\d{2})'在百万次匹配中多耗 0.8 秒
捕获组和原生字符串不是可选项，是必须项
不加 r'' 的正则，反斜杠会被 Python 字符串先吃掉一层，'\d+' 实际变成 '\x00+'；而无意义的 () 不仅拖慢速度，还让 .group(1) 调用变成内存负担。
立即学习“Python免费学习笔记（深入）”；
真正卡住性能的，往往不是正则多复杂，而是编译动作被塞进循环、锚点被忽略、或者一个 .* 被当成万能胶水用了。这些点不改，换再快的 CPU 也没用。
