BackgroundTasks最稳用于轻量短时任务，但生产环境高可靠场景应选Celery；它内存级无持久化重试，仅适合秒级完成、允许丢失的非关键操作。
FastAPI里用什么跑后台任务最稳
Python 3.11中，BackgroundTasks 是 FastAPI 官方推荐的轻量级后台任务机制，适合 IO 密集型、短时（request.state 或已关闭的数据库连接。
- 别用
threading.Thread手动启线程：FastAPI 运行在异步框架（Starlette + Uvicorn）上，混用同步线程易导致上下文丢失或资源竞争 - 别指望
BackgroundTasks.add_task()等待任务完成：它立即返回，任务失败也不会报错到客户端 - 若需长时、可取消、带状态的任务，得换
celery或arq，BackgroundTasks不是它们的替代品
BackgroundTasks.add_task() 的参数陷阱
调用 add_task() 时，函数参数会被深拷贝（仅限支持 pickle 的对象），但闭包变量、lambda、未绑定方法、带线程局部存储的对象都会出问题。
- ✅ 正确：传入普通函数 + 基础类型参数：
background_tasks.add_task(send_email, user_id=123, subject="welcome") - ❌ 错误：传 lambda：
background_tasks.add_task(lambda: print("hi"))→ 报PicklingError - ❌ 错误：传实例方法：
background_tasks.add_task(user.send_notification)→ 实例可能已被销毁 - ⚠️ 注意：如果函数内部用了
async def，add_task()会静默同步执行（不 await），导致阻塞事件循环 —— 必须用asyncio.create_task()或改用celery
怎么安全地在后台任务里访问数据库
Uvicorn 默认用单线程多协程模型，BackgroundTasks 中不能复用请求期间创建的异步数据库连接（如 AsyncSession），因为响应一发完连接就 close 了。
- 必须新建独立连接：在后台函数内重新初始化
AsyncSession，比如从engine.begin()或专用 session 工厂获取 - 别共享
session对象：即使你把它作为参数传进去，运行时大概率遇到StatementError: This Session's transaction has been rolled back due to a previous exception - 建议封装一个后台专用的 DB 工具函数：
async def run_in_background_db(query: str, *args): ...，内部管理自己的AsyncConnection
日志和错误怎么捕获才不丢
BackgroundTasks 中抛出的异常默认被吞掉，既不打印，也不通知监控系统，非常隐蔽。
立即学习“Python免费学习笔记（深入）”；
- 必须手动包一层 try/except：
def safe_send_email(...): try: ... except Exception as e: logger.error("send_email failed", exc_info=e) - 别依赖全局异常处理器：FastAPI 的
@app.exception_handler对后台任务无效 - 如果任务失败需要重试，
BackgroundTasks不提供重试逻辑 —— 得自己实现指数退避，或直接上arq的retry=True
真正要处理复杂后台任务时，BackgroundTasks 只是个“发个通知就跑”的快捷键；一旦涉及状态追踪、失败重试、资源隔离、跨服务调度，就得跳出它，选更重的方案。这点很容易在原型阶段被忽略。
