BackgroundTasks适用于非关键、可延迟、不阻塞响应的异步操作，如发邮件、写日志、更新缓存、调用无依赖第三方API、触发数据分析等；它基于线程池，不加速单请求，也不支持请求上下文，参数需可序列化，异常默认被忽略。
FastAPI的BackgroundTasks适合什么场景？
它不是用来“加速”单个请求的，而是把非关键、可延迟、不阻塞响应的操作拎出去异步执行。比如发邮件、写日志、更新缓存、调用第三方API（不依赖返回结果）、触发数据分析任务。如果你指望它让return {"status": "ok"}更快——确实会快，但前提是这些后台操作本身不该卡在主请求链路上。
- 主请求返回前，只做必要校验和数据落库（如订单创建）
- 后台任务负责后续动作，比如扣减库存余量、通知风控系统、生成PDF发票
- 任务函数内不能访问
request或response对象，也不该依赖当前请求上下文
为什么加了BackgroundTasks.add_task()后任务没执行？
最常见原因是：你传进去的是一个已调用的函数结果，而不是函数本身。比如写成background_tasks.add_task(send_email(user_id))，括号会让send_email立刻执行并返回None，然后add_task(None)自然什么也不干。
- 正确写法是传函数引用+参数：
background_tasks.add_task(send_email, user_id) - 参数必须能被
pickle序列化（不能传Request、数据库连接、文件句柄等） - 如果任务函数抛出异常，默认会被吞掉，不会报错也不会重试——得自己加
try/except记录日志
BackgroundTasks和async def后台任务的区别在哪？
BackgroundTasks底层是同步线程池（concurrent.futures.ThreadPoolExecutor），哪怕你传进去的是async def函数，它也会被asyncio.to_thread()或loop.run_in_executor()包装成同步调用，不走事件循环。
- 想真正用异步IO（比如
aiohttp发请求），得自己在任务函数里await，但必须确保它运行在支持异步的执行器中——而默认BackgroundTasks不支持 - 更稳妥的做法：用
asyncio.create_task()配合全局asyncio.get_event_loop()，但要注意生命周期管理；或者直接上celery/arq这类带持久化和重试的方案
后台任务里访问数据库容易出什么问题？
FastAPI默认不为后台任务提供数据库会话（Session），如果你在主请求里创建了一个session，然后把它传进add_task()，大概率会遇到AttributeError: 'Session' object has no attribute 'bind'或连接已关闭。
立即学习“Python免费学习笔记（深入）”；
- 不要复用请求生命周期内的
session - 后台任务应新建独立
Session，用完显式close() - 若用SQLModel/SQLAlchemy，推荐封装一个
get_db_session()工厂函数，在任务里调用，避免共享状态
任务执行时机取决于线程调度，不是“立即”，也不是“定时”，更不是“可靠队列”。别拿它当消息队列用。
