会,因为Flask-Mail的send()默认同步执行,底层SMTP操作(DNS查询、TCP握手、TLS协商、认证、发送)全程阻塞当前请求线程,用户需等待2–10秒才响应。

为什么直接调用 send() 会阻塞 Flask 请求
Flask-Mail 的 send() 默认是同步执行的,底层调用 SMTP 协议发信时会卡住当前请求线程,直到连接建立、认证通过、邮件发送完成或超时。在 Web 请求中直接调用,用户可能等 3–10 秒才收到响应,尤其当邮箱服务商响应慢(比如腾讯企业邮箱偶发延迟)或网络不稳定时,极易触发 Nginx 504 或 Flask 超时中断。
用 threading 实现轻量异步发送(推荐入门场景)
不引入额外依赖、兼容所有 Flask 版本、适合低频通知(如注册欢迎信、密码重置)。关键不是“多线程万能”,而是避免让 HTTP 请求等 SMTP 结果。
- 不要在新线程里直接调用
mail.send(msg)—— Flask-Mail 内部依赖current_app,子线程无上下文会报RuntimeError: Working outside of application context - 正确做法:把邮件内容序列化后传入线程,再在子线程中手动构建
Message并调用mail.send(),同时显式app.app_context() - 示例片段:
from threading import Thread from flask_mail import Message def send_async_email(app, msg): with app.app_context(): mail.send(msg) def send_email(subject, recipients, body): msg = Message(subject=subject, recipients=recipients, body=body) Thread(target=send_async_email, args=(current_app._get_current_object(), msg)).start() - 注意
current_app._get_current_object()是必须的——current_app是代理对象,线程里不能直接用
用 celery 处理高并发或需重试的邮件任务
当邮件量大(>100 封/天)、需失败重试、定时发送、或要和其它异步任务(如生成 PDF、调用第三方 API)编排时,celery 是更稳的选择。但要注意它不是“开箱即用”:
- Celery worker 必须和 Flask 应用共享同一份配置,尤其是
MAIL_SERVER、MAIL_USERNAME等,否则 worker 启动时读不到配置会静默失败 - 任务函数里不能直接用
current_app或g,需通过参数传入必要数据(如收件人、模板 ID),或在 task 内部重新初始化Mail实例 - SMTP 连接池没被复用:Celery 每次任务都新建 SMTP 连接,频繁发信建议配
MAIL_USE_TLS=True+MAIL_PORT=587,避免长连接耗尽 - 常见错误日志:
ConnectionRefusedError: [Errno 111] Connection refused,大概率是 Celery worker 没加载 Flask 配置,或防火墙拦了出站 587 端口
别忽略的三个实际细节
异步只是把“发邮件”挪出主线程,不代表问题消失:
- HTML 邮件里的相对路径(如
)在邮件客户端里打不开——必须换成绝对 URL,且域名要可公网访问,否则 Outlook/Gmail 会屏蔽图片
- QQ 邮箱、163 邮箱对未认证域名的 HTML 邮件自动折叠为纯文本,甚至进垃圾箱;务必启用 SPF/DKIM,发信域名要和
MAIL_DEFAULT_SENDER一致 - 本地开发时用 Gmail 测试?记得开启“允许不够安全的应用”,但上线必须换 OAuth2 或企业邮箱——Gmail 已全面禁用密码直连 SMTP
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











