应分层验证邮箱：先用宽松正则^[^\s@]+@[^\s@]+\.[^\s@]+$过滤，再用email.utils.parseaddr()校验，最终通过SMTP测试可达性。
匹配邮箱时别直接抄网上“万能正则”
绝大多数公开的邮箱正则（比如 ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$）只覆盖常见情况，但会漏掉合法邮箱如 "test+tag@example.com" 或带引号的 "first last"@domain.com。RFC 5322 定义的完整规则过于复杂，实际项目中没必要硬套。
更务实的做法是分层验证：
- 用宽松正则快速过滤明显非法输入：
^[^\s@]+@[^\s@]+\.[^\s@]+$ - 再交给标准库做二次校验：
import email.utils<br>try:<br> email.utils.parseaddr("test@example.com")<br> # 若不抛异常，基本可认为格式合理<br>except ValueError:<br> pass - 真正发邮件前，始终用 SMTP 连接测试收件人地址是否可达——这才是最终防线
匹配 URL 要先明确你的使用场景
URL 正则没有“唯一正确答案”，关键看你要捕获什么：
- 如果只是从纯文本中提取疑似链接（如日志、聊天记录），用
https?://[^\s]+就够用，简单高效 - 若需区分协议、域名、路径，推荐用 Python 内置的
urllib.parse.urlparse()，而不是自己写复杂正则：from urllib.parse import urlparse<br>url = "https://user:pass@example.com:8080/path?q=1#frag"<br>parsed = urlparse(url)<br>print(parsed.scheme) # 'https'<br>print(parsed.netloc) # 'user:pass@example.com:8080'<br>print(parsed.path) # '/path'
- 避免用所谓“完美 URL 正则”——它往往过度匹配（如把
http://单独当链接）或漏掉现代 URL（如含 emoji 域名、IPV6 地址）
re.findall 和 re.search 的行为差异直接影响结果
很多人写完正则发现匹配不到，其实是没注意函数语义：
立即学习“Python免费学习笔记（深入）”；
-
re.search()返回第一个匹配对象（Match），适合判断存在性或提取单个关键字段 -
re.findall()返回所有**完整匹配字符串**的列表；如果正则含捕获组，它只返回组内容——这点极易踩坑：import re<br>text = "Contact admin@example.com or support@test.co.uk"<br># 错误：只返回邮箱用户名部分<br>print(re.findall(r"([a-zA-Z0-9._%+-]+)@([a-zA-Z0-9.-]+\.[a-zA-Z]{2,})", text))<br># 输出：[('admin', 'example.com'), ('support', 'test.co.uk')]<br><br># 正确：用非捕获组或全匹配<br>print(re.findall(r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}", text))<br># 输出：['admin@example.com', 'support@test.co.uk'] - 需要同时获取位置和内容？用
re.finditer()，它返回Match对象迭代器，可调用.span()和.group()
边界处理比表达式本身更重要
正则跑在真实数据里，最常出问题的不是语法，而是上下文干扰：
- 邮箱前后有标点（如
"email: admin@example.com."）会导致匹配末尾多一个点——加单词边界\b没用，因为 @ 不是单词字符；改用(? 否定环视更可靠 - URL 常被包裹在括号、引号或 HTML 标签里，例如
<a href="https://example.com">。单纯匹配https?://\S+会把引号也吞进去；应限定结尾字符集：https?://[^\s)>"']+ - 大小写敏感默认开启，但邮箱域名部分不区分大小写。别盲目加
re.IGNORECASE——它会让本地部分（@前）也忽略大小写，而某些老系统是区分的
正则只是工具链一环，真正稳的方案永远是：宽松匹配 → 结构化解析 → 外部服务验证。越想靠一条正则解决所有问题，后面 debug 越痛苦。
