正则表达式由re模块通过C实现的FSM驱动，不编译为字节码；re.match()强制锚定开头且不受MULTILINE影响；findall返回空字符串源于零次匹配、空断言或末尾匹配；非贪婪仅控制回溯长度，不解决语义模糊。

正则表达式在 Python 中不是独立模块，而是通过 re 模块提供的一套解释型匹配引擎——它不编译成字节码，也不生成 AST，所有匹配逻辑都由 C 实现的有限状态机（FSM）驱动。这意味着写法稍有不慎，就容易触发回溯爆炸、空匹配死循环或 Unicode 边界误判。

为什么 re.match() 总是只从开头匹配？

re.match() 的行为由底层实现硬编码决定：它强制将模式锚定在字符串起始位置（等价于在 pattern 前自动加 ^），且不支持 re.MULTILINE 对其起效。这不是设计缺陷，而是为快速判断“是否以某模式开头”而做的性能取舍。

• 想跨行匹配开头？用 re.search(r'^pattern', text, re.MULTILINE)
• 想确保整串匹配？直接用 re.fullmatch()，它比 ^...$ 更安全（自动处理末尾换行符）
• re.match() 返回 None 不代表没找到，可能只是没在开头——别拿它当通用查找函数

re.findall() 返回空字符串时的三种常见原因

当 re.findall(r'(a*)', 'b') 返回 ['', '']，不是 bug，是 NFA 引擎对“零宽断言 + 量词”的标准响应。本质是：只要当前位置能成功匹配零次，就记录一个空字符串。

• 模式含 * 或 ? 且能匹配零次（如 r'a*'、r'(ab)?'）
• 使用了空字符类或断言（如 r'(?=x)'、r'[]'）
• 目标字符串为空，或匹配发生在末尾（如 r'o*$' 在 'foo' 中会捕获末尾空串）

避免意外空结果：显式排除零宽，例如把 a* 改成 a+，或用 re.finditer() 手动过滤 .group() 为空的情况。

贪婪 vs 非贪婪：不只是加个 ? 那么简单

非贪婪修饰符（*?、+?、??）改变的是回溯策略：它让引擎优先尝试最短匹配，失败后再逐步延长。但若整个模式存在多个可变长度子模式，非贪婪未必能“如你所愿”地截断。

import re
text = "start a1 b2 c3 end"
# 你以为会匹配到 'a1 b2'？实际是 'a1 b2 c3'
print(re.search(r'start (.*?) end', text).group(1))  # → 'a1 b2 c3'
正确做法：用否定字符类替代非贪婪
print(re.search(r'start ([^e]*) end', text).group(1))  # → 'a1 b2 c3'（仍不对）
更可靠：明确终止边界
print(re.search(r'start (a\d b\d) ', text).group(1))  # → 'a1 b2'

• 非贪婪无法解决语义模糊问题；它只控制匹配长度，不理解业务边界
• 遇到嵌套结构（如 HTML 标签、括号配对），正则根本不可靠，该上 html.parser 或递归下降解析器
• 性能上，非贪婪在长文本中可能比贪婪更慢——因为要反复试探、回溯

真正难的从来不是写出能跑的正则，而是预判它在边界输入、Unicode 组合字符、不同 Python 版本下的行为差异。比如 \w 在 3.7+ 默认启用 Unicode 模式，但在 bytes 模式下退化为 ASCII；又比如 re.sub() 中的 \1 引用，在 pattern 含命名组时必须改用 \g，否则静默失效。