re.match仅从字符串开头匹配，re.search才全文搜索；未转义特殊字符会导致误匹配；应预编译正则以提升性能；调用group前必须检查匹配结果是否为none。
re.match 和 re.search 混用导致匹配失败
很多人以为 re.match 是“找匹配”，其实它只从字符串开头匹配；re.search 才是真正意义上的“全文搜索”。写日志解析或用户输入校验时，一不留神就漏掉非开头的匹配项。
- 常见错误现象：
re.match(r'\d+', 'abc123')返回None，但直觉以为应该抓到123 - 使用场景：校验手机号（必须开头是 1）、提取 URL 中的协议（
https?://必须在开头）→ 用re.match；其他多数情况，比如从一段文本里找邮箱、IP、日期 → 无条件换re.search - 性能影响：两者底层都是 NFA 引擎，单次调用差异可忽略，但误用会导致逻辑 bug，比性能问题更致命
未转义正则特殊字符却当成字面量用
把 .、+、*、?、[、^、$ 这些字符直接塞进 pattern，没加反斜杠，结果匹配行为完全失控。最典型的是想匹配文件扩展名 .py，写了 r'.py' —— 实际上匹配任意字符 + py。
- 常见错误现象：
re.search(r'.py', 'script.py')在'a.py'或'xpy'里也返回 True - 正确做法：字面量点号必须写成
r'\.py'；更稳妥的方式是用re.escape()处理动态字符串，比如re.escape(user_input) - 注意
re.sub的替换串里\1、\g<name></name>是引用捕获组，不是普通反斜杠，别和 pattern 里的转义混淆
忽略 re.compile 编译开销与复用价值
在循环里反复调用 re.search(r'\d{3}-\d{4}', text)，每次都在内部重新编译正则——对短 pattern 影响小，但一旦 pattern 变复杂（带嵌套、前瞻断言），或循环次数多（如处理几千行日志），性能会明显下滑。
- 使用场景：配置项、函数参数、模块级常量中定义的 pattern → 一律提前
re.compile()并赋给变量，比如PHONE_PATTERN = re.compile(r'\d{3}-\d{4}') - 参数差异：
re.compile(..., flags=re.I)比每次传flags更清晰；编译后对象支持.finditer()、.subn()等方法，比函数式调用更灵活 - 兼容性注意：Python 3.7+ 对重复调用做了缓存优化，但不保证跨版本行为一致，显式编译仍是稳定写法
group() 调用时机不当引发 AttributeError
re.search 返回 None 时直接调 .group()，报 AttributeError: 'NoneType' object has no attribute 'group'。这是新手最常撞的墙，尤其在 if 判断前忘了检查匹配结果。
立即学习“Python免费学习笔记（深入）”；
- 常见错误写法：
match = re.search(...); print(match.group(1))—— 没判断match是否为None - 安全做法：先判空，或用
if match:；更简洁的是用海象运算符（Python 3.8+）：if (m := re.search(...)):再用m.group(1) - 容易被忽略的点：即使 pattern 有捕获组，
.group(0)是整个匹配，.group(1)才是第一个括号内容；编号错位或用了命名组但还用数字索引，也会报IndexError
