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 中的替换字符串里不能直接写 r'' 或 '\1'
因为反斜杠在 Python 字符串字面量中是转义符：'' 实际传给 re.sub 的是 ASCII 字符 SOH（0x01），不是“第一个捕获组”。必须让反斜杠原样到达正则引擎，才有意义。
- 用 raw string：
r' '→ 正确传递和 - 用双反斜杠：
'\1 \2'→ Python 解析为 - 若替换逻辑复杂，优先用函数作为
re.sub的repl参数，避免字符串转义陷阱：lambda m: m.group(1).upper()
真正难缠的不是语法，而是当正则本身含嵌套括号、又在替换里混用 g<name></name> 和 时，稍不留神就索引错位或命名冲突——这种细节在 debug 时几乎无法靠 print 看出来，得靠 re.DEBUG 标志或手动拆解测试。
