django 的 send_mail 不适合验证码场景，因其同步阻塞易导致前端卡顿，不校验收件人格式、无重试机制、不支持 ttl 控制与备用通道降级，且无法隔离验证码生命周期。
Django 自带的 send_mail 和 EmailMessage 能发邮件，但直接用它发验证码容易被拦截、超时或丢件；真正可用的方案必须绕过默认 SMTP 队列、控制重试逻辑、并隔离验证码生命周期。
为什么 Django 的 send_mail 不适合验证码场景
Django 默认调用 send_mail 是同步阻塞的，网络抖动或邮箱服务器响应慢（比如腾讯企业邮箱偶发 10s+ 延迟）会导致用户前端卡住；更关键的是，它不校验收件人格式合法性，也不自动 fallback 到备用通道（如短信），而验证码恰恰要求“尽力送达 + 快速失败”。
常见错误现象：SMTPServerDisconnected: Connection unexpectedly closed 或前端等待 30 秒后报“发送超时”，其实邮件早已在后台静默失败。
- 别把
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'直接用于生产环境的验证码链路 - 验证码邮件必须带 TTL（比如 5 分钟过期），而
send_mail本身不处理时效性，得靠业务层额外建表或 Redis 缓存配合 - 测试时用
console后端能看到日志，但上线后若没配好 TLS/STARTTLS，Gmail、Outlook 会直接拒收
用 Celery + Redis 实现异步、可追溯的验证码邮件
核心思路：用户点击“获取验证码”后，立即生成随机码写入 redis.setex('verify:email:abc@x.com', 300, 'a1b2c3')，再触发 Celery 任务异步发信；任务内封装重试（最多 2 次）、超时（socket_timeout=5）、错误分类记录（如 ConnectionRefusedError 记为网络问题，smtplib.SMTPRecipientsRefused 记为邮箱格式错误）。
实操建议：
- Celery 任务函数名必须带明确前缀，例如
send_verification_email_task，避免和普通通知邮件混用 - SMTP 连接参数不要硬编码，从
settings.py提取：EMAIL_HOST_USER、EMAIL_HOST_PASSWORD、EMAIL_PORT（注意：QQ 邮箱用 587，网易用 465，别填错） - 邮件正文禁用
render_to_string动态模板——模板渲染失败会导致整个任务崩溃；改用预编译字符串或 jinja2 的Template类安全渲染
验证码校验必须严格比对时间 + 使用次数
只校验 Redis 里是否存在 key 并匹配值是不够的。攻击者可能截获旧验证码重放，或者用脚本高频请求耗尽邮箱配额。
正确做法：
- 每次校验成功后，立刻
redis.delete('verify:email:abc@x.com')，防止重复使用 - 记录单个邮箱每小时请求次数，超过 5 次就临时封禁（
redis.incr('rate:email:abc@x.com')+expire） - 前端提交的验证码需转小写比对（用户可能输入 A1B2C3，但生成的是 a1b2c3），后端统一用
code.lower() == stored_code.lower()
漏掉这点，等于把登录入口直接敞开。
本地开发时如何绕过真实 SMTP
开发阶段不该依赖真实邮箱服务，否则调试一次就要等 10 秒，还可能触发服务商风控。
推荐组合：
- 用
django.core.mail.backends.locmem.EmailBackend把邮件存进内存列表，然后在视图里打印django.core.mail.outbox查看内容 - 配合
maildump（一个轻量 SMTP 测试服务）：运行docker run -d -p 1080:1080 -p 1025:1025 maildump/maildump，再把EMAIL_HOST = 'localhost'、EMAIL_PORT = 1025，就能在 http://localhost:1080 实时查收 - 绝对不要在
settings.py里写死生产 SMTP 密码；用环境变量os.getenv('EMAIL_PASSWORD')，本地跑.env文件隔离
真正麻烦的从来不是发邮件这件事本身，而是怎么让“发”这个动作在各种异常下依然可观察、可回溯、可降级——验证码尤其如此。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
