.**? 是非贪婪匹配，遇结束符即停；.** 默认贪婪，会匹配到末尾。需根据需求选择模式，并优先用精确字符类替代 .*，避免回溯灾难和结构误解析。
为什么 .* 总是匹配到末尾而不是最近的结束符
因为 .* 默认贪婪，它会尽可能多地吞掉字符，直到整个字符串末尾或无法继续匹配为止。比如想从 "start<a>text1</a>middle<a>text2</a>end" 中提取第一个 <a>...</a>，用 r'<a>.*</a>' 实际会匹配到 <a>text1</a>middle<a>text2</a> —— 它没停在第一个 </a>，而是跑到了最后一个。
解决方法很简单：在量词后加 ?，改成非贪婪模式。
-
.*?匹配任意字符（除换行），但尽可能少 -
.*（无问号）是贪婪的，.*?才是你真正想要的“遇到就停”行为 - 注意：
.默认不匹配换行符，跨行需加re.DOTALL标志，否则.*?也会被换行卡住
re.findall 返回空列表？检查是否用了贪婪量词吃掉了分隔结构
常见于解析日志、HTML 片段或自定义标记时，比如用 re.findall(r'<div>(.*?)</div>', text) 却返回空——很可能是因为 text 中有嵌套 <div> 或中间混入了未转义的 </div>，导致非贪婪也提前终止。
更可靠的做法不是靠正则硬啃结构，而是明确边界条件：
立即学习“Python免费学习笔记（深入）”；
- 如果目标内容不含
<，可用r'<div>([^<]*)</div>'替代.*?，避免误判 - 若含标签但层级简单，优先用
re.search配合group(1)取单个结果，比findall更可控 -
re.findall对非贪婪匹配敏感：多个重叠匹配不会被返回，它只按从左到右、不重叠的方式切片
性能差异：贪婪 vs 非贪婪在长文本中可能差出一个数量级
表面上只是多打个 ?，但底层回溯机制完全不同。贪婪模式先“冲到底”，再一步步往回退；非贪婪则是“走一步看一步”。当文本很长、模式又模糊（比如 .* 前后都宽松）时，贪婪容易触发灾难性回溯。
例如匹配 "a" * 10000 + "b" 中的 a*b，用 r'a*b' 很快，但用 r'a*?b' 在某些引擎下反而更慢——因为非贪婪要反复试探每个位置是否能“刚好够用”。
- 真实场景中，优先写精确字符类，比如
[^"]*比.*?快且安全 - 避免在嵌套结构里用
.*?套.*?，比如r'<tag attr="(.*?)">(.*?)</tag>'，一旦属性值里出现引号就崩 - 用
re.compile缓存正则对象，尤其在循环中多次调用时，能省下编译开销
Python 3.11+ 的 re 引擎对非贪婪支持更稳，但别依赖它绕过设计缺陷
旧版 Python（如 3.7）在极端回溯场景下可能抛 re.error: bad escape 或直接卡死，新版做了优化，但本质没变：正则仍是线性扫描+有限回溯。
真正该警惕的是把正则当解析器用：
- HTML/XML 请用
BeautifulSoup或xml.etree.ElementTree，别用re.findall(r'<p>(.*?)</p>') - JSON、YAML、配置文件等结构化数据，一律走专用解析器，正则只处理原子字段（比如提取某一行里的 IP 地址）
- 非贪婪不是万能补丁，它是权衡——换来的简洁性，常以可读性、可维护性和边界鲁棒性为代价
最常被忽略的一点：非贪婪只作用于它紧邻的量词，.*? 不会“传染”给前面的字符或后面的分组。写复杂表达式时，建议用 re.DEBUG 看实际编译结构，比猜靠谱得多。
