Python 正则表达式的执行原理

python的re模块使用回溯NFA引擎，会尝试所有可能路径并回溯，导致某些正则（如r'(a+)+b’）在长串’a’上指数级回溯而卡顿；贪婪量词先吞后吐，懒惰量词相反。

正则引擎到底在“匹配”什么

Python 的 re 模块用的是回溯（backtracking）NFA 引擎，不是一次性扫描的 DFA。这意味着它会尝试各种可能的路径去匹配，一旦某条路径失败，就退回上一个选择点重试——这解释了为什么某些正则会“卡住”或超时。

比如 r'(a+)+b' 在面对一长串 'a' 时，引擎要枚举所有分组方式（a|aa|aaa...），指数级增长回溯次数。这不是 Python 实现差，而是 NFA 本身的特性。

• 所有 re.match、re.search、re.findall 都走同一套引擎逻辑
• re.compile() 只是预编译为字节码（类似 AST），不改变匹配行为，但能避免重复解析开销
• 贪婪量词（+、*、{m,n}）默认尽可能吞掉字符，再逐步“吐出”试探；懒惰量词（+?、*?）则相反

为什么 re.finditer 比 re.findall 更省内存

re.findall 返回的是全部匹配结果构成的列表，每个匹配都存下整个字符串切片；而 re.finditer 返回迭代器，每次只生成一个 Match 对象，含起始/结束位置和分组信息，不缓存原始文本。

尤其在处理大文本（如日志文件）时，re.findall 可能瞬间吃光内存，re.finditer 却可以边读边处理：

立即学习“Python免费学习笔记（深入）”；

for m in re.finditer(r'd{3}-d{2}-d{4}', text):     print(m.group(), m.start(), m.end())

• Match 对象本身不持有文本副本，只记录 offset 和引用的 String
• 如果后续需要多次访问 m.group()，它才按需切片——这是延迟计算
• 若正则含捕获组，findall 行为会变化：只返回组内容（元组），而非完整匹配，这点容易误判结果结构

编译后的 Pattern 对象为什么不能跨线程安全使用

re.compile() 返回的 Pattern 对象内部有可变状态：比如用于缓存最近一次匹配的 _last_index 和 _last_match。虽然文档没明说，但在 CPython 实现中，这些字段在多线程并发调用 pattern.search() 时可能被覆盖或错乱。

• 实际风险取决于是否用到 pos/endpos 参数和缓存机制，但稳妥起见应视为非线程安全
• 推荐做法：每个线程独立 re.compile()，或用模块级预编译 + 全局只读 Pattern（无状态操作下基本安全）
• 若用 Threading.local() 缓存 per-thread Pattern，反而增加复杂度，通常没必要

为什么 re.sub 中的替换字符串里不能直接写 1 而要写 r'1' 或 '\1'

因为反斜杠在 Python 字符串字面量中是转义符：'1' 实际传给 re.sub 的是 ASCII 字符 SOH（0x01），不是“第一个捕获组”。必须让反斜杠原样到达正则引擎，才有意义。

• 用 raw string：r'1 2' → 正确传递 1 和 2
• 用双反斜杠：'\1 \2' → Python 解析为 1 2，效果等价
• 若替换逻辑复杂，优先用函数作为 re.sub 的 repl 参数，避免字符串转义陷阱：Lambda m: m.group(1).upper()

真正难缠的不是语法，而是当正则本身含嵌套括号、又在替换里混用 g 和 1 时，稍不留神就索引错位或命名冲突——这种细节在 debug 时几乎无法靠 print 看出来，得靠 re.DEBUG 标志或手动拆解测试。