asyncio无法解决CPU密集型任务的GIL瓶颈，因其仅在I/O时释放GIL；纯Python计算会阻塞事件循环，导致协程卡死、吞吐下降，应改用ProcessPoolExecutor在独立进程中执行。
asyncio 本身不解决 CPU 密集型任务的 GIL 瓶颈——它只在 I/O 等待时释放 GIL，而纯 Python 计算会一直持有 GIL。所以问题不在“异步写法错”，而在“把 CPU 任务塞进了异步协程”。
为什么 async def 函数里做计算反而更慢？
当你在 async def 中写 sum(range(10**7)) 或矩阵运算这类纯 Python 循环时：
- 事件循环无法切走，整个协程阻塞在 GIL 上；
- 其他协程全卡住，吞吐暴跌；
- 还不如同步单线程，因为多了协程调度开销。
CPU 密集型操作必须离开事件循环
FastAPI、Starlette 等框架底层已提供标准出口：run_in_threadpool 是第一道防线，但注意它只是线程池——对 CPU 任务效果有限，仅适合短时、可并行的轻量计算。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 真正有效的做法是：用
concurrent.futures.ProcessPoolExecutor替代ThreadPoolExecutor - 所有耗 CPU 的函数（如
numpy.linalg.svd、自定义数值积分）必须在独立进程中运行 - 避免在进程间传递大对象；优先传参数+序列化结果，或用
mmap/shared_memory（Python 3.8+）
run_in_executor 怎么选 executor？
FastAPI 的 run_in_executor 默认用线程池，但你可以显式指定进程池：
from concurrent.futures import ProcessPoolExecutor
import asyncio
<p>def cpu_heavy(x):
return x *<em> 2 + x </em> 3 # 纯 Python 计算</p><p>@app.get("/calc")
async def calc():
loop = asyncio.get_event_loop()
with ProcessPoolExecutor(max_workers=4) as pool:
result = await loop.run_in_executor(pool, cpu_heavy, 12345)
return {"result": result}
关键点：
- 不要用全局 ProcessPoolExecutor 实例（进程池不能被 pickle，跨协程复用易出 PicklingError）；
- 每次调用都新建 with 块更安全；
- 若需高频复用，改用 multiprocessing.Pool + apply_async + 回调，但要自己处理结果同步。
容易被忽略的陷阱
很多人以为用了 async 就自动“并发”，其实：
- numpy 多数函数在底层 C 实现中会主动释放 GIL，所以它们本身就能多线程并行——但前提是别用 Python 循环包装它；
- numba.jit 或 cython 编译后的函数，若声明了 nogil=True，也能绕过 GIL；
- asyncio.to_thread（Python 3.9+）只是 run_in_executor 的语法糖，仍走线程池，对 CPU 任务无效。
