async def接口未加await调用异步操作即非真异步，因同步代码（如requests、time.sleep）会阻塞事件循环，导致并发失效；须用httpx.AsyncClient、asyncpg等异步库并确保每步await，CPU密集任务需asyncio.to_thread。
async def 接口没加 await 就算不上真异步
FastAPI 里写 async def 只是声明函数类型，不代表它自动异步执行。如果函数体里全是同步代码（比如直接调用 requests.get()、读文件、计算密集型逻辑），事件循环会被阻塞，后续请求排队等待，表现和同步接口无异，甚至更慢——因为多了协程调度开销。
常见错误现象：time.sleep(2) 或 json.loads(big_string) 在 async def 里跑；用 requests 而非 httpx.AsyncClient；数据库操作用了同步驱动（如 psycopg2 而非 asyncpg 或 psycopg 的 async 模式）。
- IO 密集型操作必须用真正支持 asyncio 的库：HTTP 用
httpx.AsyncClient，DB 用asyncpg/aiomysql/ SQLAlchemy 2.0+ 的create_async_engine - 阻塞式调用必须显式移交线程池：
await asyncio.to_thread(time.sleep, 2)（Python 3.9+）或用loop.run_in_executor - 别在异步路由里做 JSON 序列化大对象、正则全文匹配、PIL 图片处理等 CPU 密集事——这些该进
to_thread，或拆到后台任务
数据库连接池没配对，async 也白搭
即使用了 asyncpg，如果连接池大小远小于并发请求数，所有协程会卡在 acquire 等连接，看起来就是“越压越慢”。默认 asyncpg.create_pool 的 min_size=10、max_size=10，但 FastAPI 默认 Uvicorn 启动 4 个 worker、每个 worker 默认 100 个连接上限，实际并发压力下很容易挤占完。
使用场景：压测时 QPS 上不去，asyncpg.exceptions.TooManyConnectionsError 频出，或日志里大量 waiting for connection from pool。
立即学习“Python免费学习笔记（深入）”；
- 查当前连接数：
SELECT count(*) FROM pg_stat_activity WHERE state = 'active'; - 调大池子：
create_pool(..., min_size=20, max_size=50)，但别超过 DB 允许的最大连接数 - 确保每个请求只用一次
acquire+release，避免在中间件或依赖中重复获取连接
Uvicorn 启动参数误配导致协程调度失衡
Uvicorn 是 FastAPI 的 ASGI 服务器，默认单 worker 多协程模型。但如果启动时加了 --workers 4，就变成多进程 + 每进程单线程协程，此时全局变量、内存缓存（如 lru_cache）、连接池都不共享，反而增加资源开销和一致性负担。
错误配置示例：uvicorn main:app --workers 4 --loop auto —— 这会让 4 个独立事件循环竞争端口，还可能因负载不均导致部分 worker 过载。
- 纯 async 场景推荐单进程：
uvicorn main:app --workers 1 --loop auto（默认就是） - 混合 sync/async 且有 CPU 密集任务，才考虑
--workers N，但需配合--threads M和进程内线程池隔离 - 务必禁用
--reload上生产；开发时若用--reload，注意它会 fork 新进程，导致 async 初始化重复执行（比如多次建连接池）
中间件或依赖注入偷偷同步阻塞
FastAPI 的 Depends 和中间件默认在主协程中执行。如果某个依赖里调用了 os.path.exists()、open().read()、jwt.decode()（PyJWT 同步版）、或自定义的 verify_token() 用了同步 Redis 客户端，整个请求就被拖住。
容易被忽略的点：日志中间件里用了 logging.info(f"req: {request.json()}") —— request.json() 是同步方法，会读取 body 并解析，阻塞协程。
- 检查所有
Depends函数是否为async def，且内部调用都 async 化 - Redis 用
aioredis或redis-py4.0+ 的Redis.from_url(..., decode_responses=True)+await redis.get(...) - JWT 验证换
python-jose的jwt.decode（它是同步的，但快；若需异步密钥获取，再包一层to_thread）
最常被忽略的是：以为加了 async 就万事大吉，其实关键在「每一步 IO 是否真正让出控制权」。一个 await 后面跟的是同步函数？那只是假等待。压测前，先用 asyncio.current_task().get_coro() 或 trio.lowlevel.current_task()（配合 trio）看实际挂起点，比猜靠谱得多。
