Flask中多线程发邮件需注意四点：①子线程无法访问request/session，须提前提取数据；②推荐用ThreadPoolExecutor替代裸threading；③复用SMTP连接并加锁或使用连接池；④必须捕获异常、记录日志并重试关键邮件。
Flask里直接用threading.Thread发邮件会丢请求上下文
Flask的request、session、g这些对象绑定在当前请求线程上，新开线程后它们默认不可访问。如果在子线程里调用url_for()或读取session，会报RuntimeError: Working outside of application context或Working outside of request context。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 不要在子线程里直接使用
request或session，提前把需要的数据（如用户邮箱、模板参数）提取出来传入线程 - 若必须复用Flask上下文，用
app.app_context()和app.request_context()手动推入，但要注意request_context需模拟原始请求环境（比如传environ），实际中极少需要 - 更稳妥的做法是：把邮件内容完全序列化（如
dict或json.dumps），由主线程准备完毕再交给子线程
用concurrent.futures.ThreadPoolExecutor比裸threading更可控
裸用threading.Thread容易失控——没限制并发数、没异常捕获、没法等任务完成。而ThreadPoolExecutor自带线程池管理、超时控制和结果收集能力。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 全局初始化一个
ThreadPoolExecutor实例（如executor = ThreadPoolExecutor(max_workers=4)），避免每次发邮件都新建线程池 - 用
executor.submit(send_mail, to, subject, body)提交任务，不阻塞主线程；若需确认发送结果，再调用future.result(timeout=10) - 务必在应用关闭时调用
executor.shutdown(wait=True)，否则可能丢失未完成的邮件 - 注意：
max_workers别设太大（如>10），SMTP服务器通常有连接数限制，本地测试可设3~5
SMTP连接复用能显著提升多线程发信性能
每次发邮件都新建smtplib.SMTP()连接，既慢又容易触发SMTP服务端限流（如Gmail每分钟100封）。多线程下重复建连还会加剧资源竞争。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
smtplib.SMTP_SSL()或smtplib.SMTP().starttls()建立连接后，复用同一个smtp实例发多封邮件（注意加锁，因为SMTP对象不是线程安全的） - 更推荐方案：每个线程独占一个连接（从连接池获取），或改用支持连接池的库如
aiosmtplib（异步）+asyncio.to_thread（Python 3.9+） - 示例中避免写
smtp = smtplib.SMTP(...); smtp.send_message(...); smtp.quit()这种模式——quit()会断连，下次还得重连
生产环境别跳过错误处理和日志记录
邮件发送失败不会抛出异常到Web请求线程，而是静默消失在子线程里。用户点了“发送验证码”，页面显示成功，其实邮件根本没发出去。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 子线程内必须包住
try/except，捕获smtplib.SMTPException、ConnectionRefusedError等，并写入日志（如app.logger.error(f"Mail failed to {to}: {e}")） - 关键业务邮件（如密码重置）建议加失败重试机制（最多2次，间隔1秒），但要避免无限重试拖垮线程池
- 记录
message-id和收件人，方便后续排查是否重复发送或漏发
线程池、上下文隔离、SMTP复用、错误可见性——这四点漏掉任何一环，多线程发邮件就容易变成“看似正常，实则失联”的玄学问题。
