异步编程无法加速CPU密集型任务，因asyncio受GIL限制；必须用ProcessPoolExecutor配合await run_in_executor，并加timeout、异常处理及复用进程池。
异步编程本身不能加速 CPU 密集型任务，asyncio 的事件循环仍在单线程里跑，GIL 没被绕过。真要提速，得靠 multiprocessing；但直接扔进子进程又会阻塞整个协程调度——所以关键不是“用不用多进程”，而是“怎么把多进程安全、非阻塞地接入 async 流程”。
为什么不能直接 await cpu_bound_func()
你写一个纯计算函数，比如 sum(range(10**8))，然后在 async def 里直接 await 它——这根本跑不通。await 只接受 Awaitable 对象（如协程、Future），普通函数不是。更糟的是，就算你强行用 loop.run_in_executor 包了一层，如果忘了设超时或没处理异常，整个 event loop 可能被卡住。
-
cpu_bound_func()是同步阻塞的，它会独占当前线程，event loop 暂停调度 -
asyncio.to_thread()（Python 3.9+）内部其实也是调用run_in_executor，本质相同 - 不加
timeout的asyncio.wait_for()包裹，一旦某个计算卡死（比如死循环），整个协程就 hang 住
用 ThreadPoolExecutor 还是 ProcessPoolExecutor？
CPU 密集型任务必须选 ProcessPoolExecutor。用 ThreadPoolExecutor 是白忙活——线程仍受 GIL 锁限，4 核 CPU 上 4 个线程跑斐波那契，耗时几乎和单线程一样。
-
ThreadPoolExecutor：适合 IO 密集型（如调 API、读文件），开销小，启动快 -
ProcessPoolExecutor：适合 CPU 密集型，真正并行，但进程创建/序列化参数有开销 - 别混用：
concurrent.futures.ProcessPoolExecutor不能传 lambda 或嵌套函数，必须是模块顶层可导入的函数
如何安全获取结果并处理错误
直接 await loop.run_in_executor(pool, func, *args) 是常见写法，但它只返回结果，不暴露 Future 状态。一旦子进程崩溃（比如 MemoryError、SIGKILL），异常会被吞掉或变成模糊的 BrokenProcessPool。
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
立即学习“Python免费学习笔记（深入）”；
- 务必用
asyncio.wait_for(..., timeout=...)包裹，避免无限等待 - 捕获
asyncio.TimeoutError和concurrent.futures.ProcessPoolExecutor抛出的底层异常（如BrokenProcessPool、PickleError） - 参数必须可序列化：不能传
lambda、闭包、未绑定方法、含不可 pickle 属性的对象 - 示例片段：
import asyncio from concurrent.futures import ProcessPoolExecutor <p>def cpu_task(n): return sum(i * i for i in range(n))</p><p>async def run_cpu_async(n): loop = asyncio.get_running_loop() with ProcessPoolExecutor() as pool: try: result = await asyncio.wait_for( loop.run_in_executor(pool, cpu_task, n), timeout=10.0 ) return result except asyncio.TimeoutError: print(f"Task with {n} timed out") raise except Exception as e: print(f"Process error: {type(e).<strong>name</strong>}") raise
别忽略进程池生命周期和资源泄漏
每次 with ProcessPoolExecutor() as pool: 都会新建进程池，频繁创建销毁代价大。长期运行的服务应复用池，但要注意：池对象不是线程安全的，也不能跨 event loop 使用。
- 全局单例池比每次
with更高效，但需手动shutdown(wait=True)清理 - 若在异步 Web 框架（如 FastAPI）中使用，别在每个请求里 new 一个池——改用依赖注入或 startup hook 初始化
- Windows 下子进程无法继承父进程的 event loop，所以
asyncio.run()内部启动的池，在子进程里再调asyncio会报错
最易被忽略的一点：CPU 密集型任务 + 异步框架 ≠ 自动变快。你得亲手把计算卸载到独立进程，并确保异常不穿透、超时不遗漏、池不泄漏——async 只是调度胶水，真正的力气活，还在 multiprocessing 那边。
