FastAPI中async def接口无异步效果的根本原因是混用同步阻塞操作，如requests、time.sleep或未await的数据库调用；需改用httpx/aiohttp、asyncio.to_thread、异步数据库驱动并确保await调用。

FastAPI里写async def接口，但实际没异步效果？

根本原因通常是用了同步阻塞操作，比如requests.get()、time.sleep()或没加await的数据库调用。FastAPI只负责把函数声明为协程，不自动帮你把同步代码变异步。

实操建议：

• HTTP请求必须换用httpx.AsyncClient或aiohttp.ClientSession，不能用requests
• 文件读写要用asyncio.to_thread()（Python 3.9+）包装open()，或用支持异步的库如aiopath
• 数据库务必用异步驱动：SQLAlchemy 2.0+配async_engine，或asyncpg、motor（MongoDB）
• 别忘了在调用处加await——常见错误是写了async def，但里面全是同步调用，还漏了await

为什么用FastAPI而不是纯asyncio + HTTP服务器？

因为FastAPI自带路由、序列化、文档、依赖注入和校验，而裸写asyncio.start_server()得自己解析HTTP报文、处理路径、转JSON、写OpenAPI文档——这些不是业务逻辑，但出错率高、调试难。

关键差异点：

立即学习“Python免费学习笔记（深入）”；

Secure Python Code Sandbox

安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。

下载

• FastAPI的BackgroundTasks适合发邮件、写日志等“不等结果”的事；纯asyncio.create_task()更适合需要协调多个协程的内部逻辑
• 依赖注入（Depends）能自动管理异步数据库连接生命周期，手动用asyncio.Queue或全局连接池容易泄露或复用错误
• Pydantic v2模型在request.body()解析时默认支持异步，但自定义__init__里做同步IO会卡住事件循环

async/await嵌套太深，怎么避免callback hell式写法？

不是所有I/O都值得拆成独立async def函数。过度分层会让调用链变长、上下文丢失、错误堆栈难读。

推荐做法：

• 把真正耗时且可并发的操作拆出来：比如并行查3个微服务，用asyncio.gather(api_a(), api_b(), api_c())
• 同一函数内连续await两个DB查询，不如合并成一个SQL（如果业务允许），减少调度开销
• 别为了“看起来异步”而给单行await redis.get("key")单独包一层函数——这反而增加call stack深度
• 调试时用asyncio.current_task().get_name()打日志，比层层传trace_id更轻量

本地开发时async接口响应慢，甚至超时？

大概率是Event Loop被阻塞了，不是代码写得不对，而是环境配置或依赖没对齐。

检查清单：

• 确认启动命令是uvicorn main:app --reload --workers 1：多进程（--workers > 1）下每个worker有独立event loop，但--reload和多worker共存可能引发热重载冲突
• 检查sys.platform：Windows上默认用ProactorEventLoop，某些旧版aiofiles或watchfiles不兼容，可显式设asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())
• 禁用IDE的“Python Debug Server”类插件——它们常偷偷注入同步断点逻辑，让await卡住
• 用uvloop前先验证：装uvloop后启动报RuntimeError: This event loop is already running，说明已有loop在跑了（比如Jupyter或某些测试框架）

最常被忽略的是：以为加了async就万事大吉，其实数据库连接池大小、Redis连接数、HTTP客户端超时设置这些同步层参数，照样能让整个异步链路堵死。