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% 且长时间无响应

真正卡住人的从来不是语法符号，而是回溯机制与引擎执行顺序的隐含约束；写正则前先问自己：这个模式是否存在多个合法匹配路径？如果有，哪条是引擎实际选的？