应预编译正则并调用对象方法（如pattern.search），避免在循环中反复re.search；多关键词匹配优先用aho-corasick自动机；固定子串检查直接用in或str.find。
re.compile 编译一次，别在循环里反复调用 re.search
频繁调用 re.search("pattern", text) 会触发内部缓存查找 + 编译逻辑，即使你用了 re.compile 预编译，如果后续又传给 re.search(PATTERN, text)，它仍会绕过对象方法、走缓存路径——而缓存有上限（默认 512 条），且带哈希计算开销。
真正快的做法是直接调用编译后对象的方法：
PATTERN = re.compile(r"error|warning|fatal")- 在循环中写
PATTERN.search(text)，不是re.search(PATTERN, text) - 避免把正则当“配置字符串”传入函数再 compile —— 那等于白预编译
实测：3200 万次匹配，用对象方法比用 re.search 调用快 1.8 倍，_compile 调用次数从 415 万次降到 0。
多关键词同时匹配，别用多个 re.search 串行扫
如果你要查 30 个关键词（比如日志分级字段），逐个 re.search 就是 O(30×n)，实际是线性放大延迟。这时候 re.compile 单条正则也撑不住——r"keyword1|keyword2|keyword3|..." 生成的 NFA 状态爆炸，编译慢、匹配也未必快。
更稳的解法是 Aho-Corasick（AC 自动机）：
- 预构建一次状态机，时间复杂度 O(∑len(pattern))
- 单次扫描文本，同时输出所有匹配位置和模式名，O(n + m + k)，k 是总匹配数
- Python 可用
ahocorasick库（C 扩展，比纯 Python 实现快 10 倍以上）
示例：
import ahocorasick
ac = ahocorasick.Automaton()
for idx, keyword in enumerate(["error", "timeout", "panic"]):
ac.add_word(keyword, (idx, keyword))
ac.make_automaton()
for end_idx, (idx, keyword) in ac.iter("server timeout error occurred"):
print(f"found {keyword} at {end_idx - len(keyword) + 1}")
短文本简单匹配，优先用 str.find 或 in，别硬上正则
正则不是银弹。对固定子串（如判断日志是否含 "404" 或 "SUCCESS"），"404" in line 比 re.search("404", line) 快 3–5 倍——因为前者走的是优化过的 Boyer-Moore 变种，后者要进正则引擎、建状态机、做回溯预备。
适用场景判断：
- 纯子串存在性检查 → 用
in或str.find - 需要位置、多次出现 → 用
str.find循环或str.split（注意内存） - 带边界、大小写、可选字符等 → 再考虑正则，且必须预编译 + 对象调用
陷阱：别在循环里拼接正则 pattern 字符串，比如 re.search(f"{prefix}{suffix}", text) —— 每次都新编译，性能雪崩。
AC 自动机不是万能的，要注意内存和初始化成本
AC 自动机优势在“多模式 + 多次查询”，但如果只查一两次，或模式总数不到 10 个，构建自动机的开销（内存 + CPU）可能反超暴力扫。实测临界点约在 15–20 个关键词、单文本 > 1KB 时才明显占优。
还要注意：
-
ahocorasick的add_word不支持空字符串或重叠 pattern（如"ab"和"abc"可以，但"ab"和"b"在某些版本会丢短匹配，需确认store参数） - 自动机构建后不可变，增删 pattern 得重建——适合规则静态的场景（如日志分类规则）
- 若需大小写不敏感，得自己 lower() 文本或预处理 pattern，AC 本身不内置 flag
真正卡顿的点，往往不在匹配算法本身，而在你没意识到：每次 re.search 都在偷偷编译，每次 "x" in list 都在遍历，每次 str.replace 都在复制整串。优化得先看见这些动作，再砍掉它们。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
