re.match()仅从字符串起始位置匹配，开头不满足即返回None；应依需求选match、search或fullmatch；compile缓存语法树和字节码；贪婪匹配会回溯，非贪婪可限定优先级。
正则表达式在 Python 中不是独立语言，而是 re 模块对底层 C 实现的封装；真正决定匹配行为的是「引擎类型」和「编译时标志」，不是写法多酷炫。
为什么 re.match() 总是返回 None，哪怕字符串开头明显匹配？
根本原因：它只从字符串**起始位置**（pos=0）开始尝试匹配，不扫描整个字符串。一旦开头不满足，立刻失败，不会后移重试。
- 误用场景：
re.match(r'\d+', 'abc123')→ 返回None（因为'a'不是数字） - 正确替代：
re.search(r'\d+', 'abc123')→ 匹配到'123' - 真需要锚定开头？改用
re.fullmatch(r'^\d+', '123abc')或显式加^：re.search(r'^\d+', '123abc') - 性能提示：如果确定只需检查开头，
re.match()比re.search()略快，但差异微乎其微，别为这点速度牺牲可读性
re.compile() 编译后的 pattern 对象到底缓存了什么？
它缓存的是「已解析的正则语法树 + 编译后的字节码指令」，不是结果。每次调用 .search() 或 .findall() 仍需执行匹配运算，但跳过了词法分析和语法树构建阶段。
- 必须缓存的场景：循环中反复使用同一正则，比如日志行解析：
pattern = re.compile(r'(\d{4}-\d{2}-\d{2}) (\d{2}:\d{2}:\d{2}) - (\w+): (.*)') for line in log_lines: m = pattern.search(line) if m: ... - 不用缓存也无妨：一次性匹配、或正则极简单（如
r'a'），Python 内部有小型缓存（默认缓存 512 个 pattern），重复用会自动命中 - 注意副作用：编译时传入的
flags（如re.IGNORECASE）会固化进对象，后续调用不能再改
贪婪匹配失效的典型表现与调试方法
所谓「贪婪」，是指量词（*、+、{n,}）默认尽可能多地匹配字符，但前提是**整个正则能最终匹配成功**。一旦全局匹配失败，引擎会回溯并收缩匹配长度——这不是 bug，是 NFA 引擎的必然行为。
- 常见假象：
re.search(r'a.*b', '匹配到
aXbYb')'aXbYb'（不是'aXb'），因为.*吞掉所有，直到最后一个b才满足结尾条件 - 想停在第一个
b？用非贪婪：r'a.*?b'→ 匹配'aXb' - 调试技巧：用
re.DEBUG标志看编译过程：re.compile(r'a.*b', re.DEBUG)
输出指令流，能看清匹配路径和回溯点 - 性能陷阱：嵌套量词（如
(a+)+）在恶意输入下可能引发「灾难性回溯」，CPU 占用 100% 且长时间无响应
aXbYb')真正卡住人的从来不是语法符号，而是回溯机制与引擎执行顺序的隐含约束；写正则前先问自己：这个模式是否存在多个合法匹配路径？如果有，哪条是引擎实际选的？
