async def 不等于高并发，关键在IO真异步、连接复用、阻塞点剥离；须用httpx/asyncpg等异步库，配连接池，长任务交Celery，Uvicorn需调workers/uvloop等参数。
直接结论：只用 async def 不等于高并发，关键在「IO操作是否真异步」+「连接是否复用」+「阻塞点是否剥离」。
async def 路由里混了 requests.get() 就白写了
很多开发者以为把路由函数改成 async def 就自动并发了，结果压测发现 QPS 上不去。根本原因是：同步库（如 requests、time.sleep()、psycopg2.connect()）会直接阻塞整个事件循环。
- 必须替换为真正异步的库：
httpx.AsyncClient替代requests，asyncpg或aiomysql替代同步数据库驱动 - 不能在
async函数里调用os.listdir()、json.load()等同步文件/序列化操作；大文件读写要用await aiofiles.open() - 万一必须用同步函数（比如调某个 legacy C 扩展），得用
loop.run_in_executor()托管到线程池，否则就是单点阻塞
数据库连接池没配对，async 也救不了
即使用了 asyncpg，如果每次请求都新建连接，连接建立开销（TCP握手 + 认证）会吃掉大部分性能提升。连接池不是可选项，是必选项。
- 在 FastAPI
@app.on_event("startup")里初始化池，别在路由里临时建：app.state.pool = await asyncpg.create_pool(...) -
minsize建议设为 UVicorn worker 数 × 2，maxsize根据 DB 最大连接数留余量（比如 MySQL 默认 151，设maxsize=100） - 务必用
async with pool.acquire()获取连接，而不是手动pool.acquire()+pool.release()，漏释放会导致池耗尽
BackgroundTasks 不适合长任务，该上 Celery 就别硬扛
BackgroundTasks 是轻量级的“请求返回后继续跑”，但它仍运行在同一个事件循环里。CPU 密集型或超长 IO（如视频转码、批量导出 Excel）会拖慢所有新请求。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
-
BackgroundTasks仅适用于秒级完成的清理类操作（如发通知、更新缓存） - 真正耗时任务必须交给独立 Worker 进程：用
Celery+Redis或RQ，FastAPI 只负责发任务 ID 并立即返回 - 别为了省事在
BackgroundTasks里塞subprocess.run()或numpy-heavy-calc()，这等于把协程当线程用
Uvicorn 参数不调，8核机器可能只跑出1核性能
默认 uvicorn.run() 是单进程单线程，完全浪费多核资源。生产部署必须显式配置并发模型。
-
--workers N：设为 CPU 核心数 × 1.5～2（非 CPU 密集型服务可更高），例如 8 核机器用--workers 12 -
--loop uvloop：比默认asyncio循环快 20%～40%，需pip install uvloop -
--limit-concurrency 1000：防止单实例被突发流量打爆内存，配合 Nginx 的limit_conn更稳 - 别用
--reload上生产，它会禁用uvloop和多 worker
最容易被忽略的点：所有异步优化的前提是「下游服务也异步」。如果你的 API 大量调第三方 HTTP 接口，而对方响应慢且不支持连接复用，那再好的 asyncpg 池也没用——瓶颈早卡在出站连接上了。
