正则表达式由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() 为空的情况。
立即学习“Python免费学习笔记（深入）”；
贪婪 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' <h1>正确做法：用否定字符类替代非贪婪</h1><p>print(re.search(r'start ([^e]*) end', text).group(1)) # → 'a1 b2 c3'（仍不对）</p><h1>更可靠：明确终止边界</h1><p>print(re.search(r'start (a\d b\d) ', text).group(1)) # → 'a1 b2'</p>
- 非贪婪无法解决语义模糊问题；它只控制匹配长度，不理解业务边界
- 遇到嵌套结构（如 HTML 标签、括号配对），正则根本不可靠，该上
html.parser或递归下降解析器 - 性能上，非贪婪在长文本中可能比贪婪更慢——因为要反复试探、回溯
真正难的从来不是写出能跑的正则，而是预判它在边界输入、Unicode 组合字符、不同 Python 版本下的行为差异。比如 \w 在 3.7+ 默认启用 Unicode 模式，但在 bytes 模式下退化为 ASCII；又比如 re.sub() 中的 \1 引用，在 pattern 含命名组时必须改用 \g<name>，否则静默失效。
