会，smtplib发邮件会彻底阻塞请求；因其为同步阻塞调用，在Flask单线程模型下导致DNS查询、TCP握手、TLS协商、认证及发送全程卡住当前线程，用户需等待2–5秒才响应。
Flask 中直接用 smtplib 发邮件会阻塞请求吗？
会，而且阻塞得很彻底。Flask 默认运行在单线程同步模型下（哪怕开了多线程，每个请求仍由一个线程独占处理），smtplib.SMTP.sendmail() 是同步阻塞调用，DNS 查询、TCP 握手、TLS 协商、认证、发送数据全程卡住当前线程。用户提交表单后得等 2–5 秒才收到响应，体验极差。
常见错误现象：TimeoutError 或响应延迟明显；日志里看到多个请求串行执行；用 time.time() 打点发现视图函数耗时几乎全花在发信上。
- 不要在路由函数里直接调用
smtp.sendmail() - 避免用
threading.Thread(target=send_mail).start()简单包裹——线程没上下文，无法安全访问current_app或request，且异常无法捕获 - 别依赖
gevent自动 patch——它对 SMTP 底层 socket 的 patch 不稳定，容易导致连接复用错乱或静默失败
推荐方案：用 concurrent.futures.ThreadPoolExecutor 提交任务
这是最轻量、兼容性最好、调试最直观的方式。主线程只负责提交任务，不等待结果；线程池复用底层线程，避免频繁创建销毁开销；支持返回 Future 对象，便于后续查状态或加回调。
关键点在于：邮件逻辑必须抽离成纯函数，不依赖 Flask 上下文；配置（如 SMTP 地址、密码）通过参数传入，而非从 current_app.config 动态读取（因为子线程无上下文）。
立即学习“Python免费学习笔记（深入）”；
from concurrent.futures import ThreadPoolExecutor
import smtplib
from email.mime.text import MIMEText
<p>executor = ThreadPoolExecutor(max_workers=4)</p><p>def send_email_smtp(host, port, user, password, to, subject, body):
msg = MIMEText(body, 'plain', 'utf-8')
msg['Subject'] = subject
msg['From'] = user
msg['To'] = to
try:
with smtplib.SMTP_SSL(host, port) as smtp:
smtp.login(user, password)
smtp.send_message(msg)
return True
except Exception as e:
print(f"Email failed: {e}")
return False</p><h1>在视图中调用</h1><p>@app.route('/notify', methods=['POST'])
def notify():
future = executor.submit(
send_email_smtp,
host=current_app.config['MAIL_SERVER'],
port=current_app.config['MAIL_PORT'],
user=current_app.config['MAIL_USERNAME'],
password=current_app.config['MAIL_PASSWORD'],
to=request.json['to'],
subject=request.json['subject'],
body=request.json['body']
)
return {'status': 'queued'}, 202
为什么不用 asyncio + aioSMTP？
表面上看更“原生异步”，但实际落地坑多。Python 生态中成熟稳定的异步 SMTP 客户端极少，aioSMTP 已归档，aiosmtplib 虽可用，但存在几个硬伤：
- 不支持所有 SMTP 扩展（如
AUTH PLAIN在某些企业邮箱上 fallback 失败） - 与 Flask 的
app.app_context()无法自然融合——你不能在async def视图里 await 异步发信，因为 Flask 2.0+ 之前根本不支持 async 视图；即使升级到 Flask 2.3+，也要求 WSGI 服务器换成Uvicorn或Hypercorn，这已超出“仅发邮件”的改造范围 - 错误堆栈常混杂 asyncio 内部帧，定位真实 SMTP 错误（如认证失败、配额超限）反而更困难
除非整个应用已基于 FastAPI/Starlette 构建，否则为发一封邮件引入 asyncio 运行时和新依赖，性价比极低。
生产环境必须加的防护措施
线程池不是万能解药。漏掉这些，上线后可能引发连接打满、密码泄露、被邮件服务商拉黑等问题。
- 给
ThreadPoolExecutor设置max_workers=3~5：SMTP 服务器通常限制单 IP 并发连接数，设太高反而触发限流 - 所有敏感字段（
password）必须从环境变量读取，绝不能硬编码或写进配置文件 - 对
send_email_smtp加超时控制：future.result(timeout=10)仅用于调试，生产中应完全忽略返回值，改用日志 + 告警监控失败率 - 记录每封邮件的
message-id和目标邮箱，方便后续排查投递状态（SMTP 成功 ≠ 收件箱收到）
真正的难点不在“怎么异步”，而在于如何让发信行为可观察、可重试、可限流。线程池只是起点，后面还得接任务队列（如 Celery + Redis）和结构化日志，但那是另一个问题了。
