CPU密集任务勿用asyncio，因GIL限制且事件循环反增开销；应改用multiprocessing或run_in_executor；I/O密集任务才适合asyncio，可显著提升并发吞吐。
CPU 密集任务别用 asyncio，会白忙活
Python 的 asyncio 本质是单线程协程调度，靠让出控制权实现并发，但无法绕过 GIL。一旦任务进入纯计算（比如矩阵乘法、加密哈希、递归斐波那契），asyncio 不仅不加速，反而因事件循环开销拖慢整体速度。
常见错误现象：async def cpu_bound(): 里调用 sum(range(10**8))，耗时比同步还长；监控显示 CPU 占用率没上去，但线程卡死不动。
- 正确做法：用
multiprocessing或concurrent.futures.ProcessPoolExecutor - 若必须从异步上下文调用 CPU 密集逻辑，用
loop.run_in_executor(None, cpu_func, *args)（None表示使用默认进程池） - 注意：进程间数据传递有序列化成本，别传大对象（如未压缩的
numpy.ndarray）
I/O 密集任务优先选 asyncio + aiohttp/aiomysql
网络请求、数据库查询、文件读写（尤其带网络存储如 S3）这类操作大部分时间在等响应，asyncio 能在等待期间切走执行其他协程，显著提升吞吐。
典型场景：并发拉取 100 个 API 接口，同步写法要 100×平均延迟，asyncio.gather() 可压缩到接近单次延迟。
立即学习“Python免费学习笔记（深入）”；
- 关键参数：设好
timeout和连接池大小（如aiohttp.TCPConnector(limit=100)），否则默认限制太紧反成瓶颈 - 避免混用阻塞调用：不要在
async函数里直接调requests.get()或time.sleep()，改用aiohttp.ClientSession.get()和asyncio.sleep() - 文件 I/O 需注意：
open()是阻塞的，要用aiofiles库或把os.read()扔进run_in_executor
怎么快速判断一个任务属于哪一类？看它“卡在哪”
不是看代码行数或函数名，而是观察运行时行为：
- CPU 密集：
top或任务管理器里 Python 进程持续占满 100% 单核，且无明显系统调用（strace -e trace=network,io几乎不输出） - I/O 密集：Python 进程 CPU 占用低（strace 显示大量
epoll_wait、recvfrom、read等系统调用阻塞 - 混合型（最常见）：比如解析 JSON 响应体——网络等待是 I/O，
json.loads()是 CPU。这时应拆开：异步拿响应，再用run_in_executor解析
threading 和 asyncio 别乱混，GIL 下线程对 CPU 密集无效
有人以为“开线程就能并行”，但在 CPython 中，threading 对纯计算毫无帮助，因为所有线程共用 GIL。唯一价值是释放 GIL 的操作（如 time.sleep()、requests.get()、sqlite3 查询），此时线程和 asyncio 效果接近，但线程更重、难调试。
- 简单 I/O 并发（≤20 个请求）：用
ThreadPoolExecutor也够用，代码更直白 - 高并发（≥100）、低延迟要求、需精细控制生命周期（如长连接保活）：必须上
asyncio - 绝对不要在
async函数里thread.start()后直接join()，这等于变相同步阻塞
真正容易被忽略的是混合场景下的资源错配：比如用 asyncio 并发拉取 1000 个网页，结果在内存里用 pandas.DataFrame 逐个解析，解析阶段锁死整个事件循环。这时候，I/O 层面的并发优势全被 CPU 阻塞吃掉了。
