re.compile() 默认使用大小为512的内置缓存，仅对字面量字符串和标志组合生效，动态拼接、变量传入或标志差异均导致缓存未命中；应手动缓存关键pattern对象以确保行为稳定。
re.compile() 为什么不是每次调用都重新编译
Python 的 re.compile() 确实会编译正则字符串，但默认情况下，它背后有内置缓存——不是每次调用都真去编译。这个缓存大小固定为 512（CPython 3.12），存的是 pattern 字符串到 re.Pattern 对象的映射。
缓存只认字符串字面量和标志位组合：比如 r"\d+" 和 r"\d+" + "" 虽然值一样，但后者是运行时拼接，不会命中缓存；re.compile(r"\d+", re.I) 和 re.compile(r"\d+", re.IGNORECASE) 是同一个缓存键，但 re.compile(r"\d+", flags=re.I | re.M) 就算多一个 re.M，也是独立缓存项。
- 缓存不跟踪变量内容：哪怕你反复用同一个变量
pat_str调用re.compile(pat_str)，只要它不是字面量，就几乎从不命中 - 缓存键区分 Unicode 模式：
re.compile(r"a", re.A)和re.compile(r"a")是两个不同缓存项 - 一旦缓存满，LRU 会踢掉最久未用的条目——但不会主动清理已编译对象，它们仍被引用时不会被 GC
什么时候该手动缓存 re.Pattern 对象
手动缓存不是为了“优化性能”，而是为了规避缓存不可控带来的行为差异。典型场景是：正则来自配置、用户输入、或拼接生成，根本进不了内置缓存；或者你在热循环里高频调用，想确保零编译开销。
直接把 re.compile() 结果赋给模块级变量是最简单可靠的做法：
立即学习“Python免费学习笔记（深入）”；
import re
# ✅ 推荐：显式、稳定、可读
EMAIL_PATTERN = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")
<p>def validate_email(text):
return bool(EMAIL_PATTERN.match(text))
- 避免在函数内反复调用
re.compile()，尤其在 for 循环或频繁调用的 API 中 - 不要用
functools.lru_cache包裹re.compile——它缓存的是函数调用结果，但re.Pattern对象本身不可哈希（除非你自定义 key，得不偿失） - 如果正则动态生成且无法预知，缓存意义不大；不如接受一次编译成本，别强行套 cache
缓存失效或冲突的常见表现
你以为缓存生效了，其实没 hit；或者以为安全复用，结果标志位被意外覆盖——这类问题往往表现为匹配行为突变，且难以复现。
典型错误现象：
- 同一行代码，在模块导入时跑通，放到单元测试里就 fail：可能因为测试重载模块，而
re.compile()缓存是全局的，旧 pattern 还活着，但新模块里的字符串对象 id 不同 → 缓存 miss → 新编译 → 标志位/unicode 处理逻辑微差 - 用
re.search(pattern, text)直接传字符串，本地开发没问题，上线后偶尔匹配失败：线上环境可能开了re.DEBUG或修改了re模块（极少见），更可能是缓存里混进了带re.X的同字符串但不同 flag 的旧 pattern - 调试时 print(
re.compile(r"\w+")) 显示地址一直在变：说明没走缓存，每次都是新对象——这时候你该检查是不是用了 f-string 或str.replace()动态构造 pattern
查看和控制缓存状态的方法
CPython 暴露了 re._cache（注意下划线前缀，属内部 API），可用于诊断，但不建议生产使用。
临时观察缓存大小和内容：
import re print(len(re._cache)) # 当前缓存条目数 # 注意：_cache 是 dict，key 是 (pattern_str, flags)，value 是 Pattern 实例
- 清空缓存：
re._cache.clear()—— 仅用于测试或极端调试，会强制后续所有re.compile()重建，可能引发短暂性能抖动 - 增大缓存：不能直接改
_cache大小，但可通过设置环境变量PYTHONRECACHE（CPython 3.11+）来调整，例如PYTHONRECACHE=1024 python script.py - 真正需要控制缓存行为时，唯一靠谱路径是绕过
re.compile()默认逻辑，自己维护dict或lru_cache，key 显式包含 pattern + flags 元组
缓存机制本身很轻量，但它的“隐形”才是最大复杂点：你看不见它何时生效、何时失效，也很难在多线程或 reload 场景下推理其状态。所以，对关键正则，宁可显式编译一次，也不要赌缓存。
