为什么Python 3.12中的异步性能比3.10版本有显著提升？

Python 3.12 的异步性能相比 3.10 有了肉眼可见的提升——这并非简单的版本号翻新，而是对 asyncio 底层机制动了一次真正的手术。任务取消更轻量了，事件循环调度更聪明了，异常处理也更干脆了。如果你还在用旧版本写异步服务，下面这几个核心变化值得仔细看看。

asyncio.TaskGroup 替代 gather 后任务取消更轻量

先聊最直观的改变：任务管理方式。Python 3.10 的 asyncio.gather() 有个老毛病——只要有一个子任务出错，其他任务并不会立刻停手，而是继续跑完，最后才把所有异常打包丢给你。3.12 默认推荐的 asyncio.TaskGroup 则完全不同：一旦有任务失败，立刻取消其余所有任务，并且原样抛出异常（除非真的同时出现多个并发异常，否则不会包装成 ExceptionGroup）。这直接省掉了大量无效调度和资源占用。

• 协程启动开销降低约 15%，因为去掉了 gather 那套中间状态管理
• 错误堆栈干净多了：不再有一层又一层的 CancelledError 或 BaseExceptionGroup 嵌套
• 手动调用 task.cancel() 后再 await task 仍会触发 CancelledError——这是设计行为，不是 bug

事件循环默认启用自适应调度，I/O 等待响应更快

事件循环层面也有大动作。3.12 的 DefaultEventLoopPolicy 内置了 GIL 自适应让出支持，对 I/O 等待做了更细粒度的 yield 判断：当前任务阻塞在 select/epoll 时，事件循环能更快地响应新任务插入；长时间运行的协程（比如那些含大量计算的 await asyncio.sleep(0) 循环）不再容易“饿死”其他任务。

• loop.slow_callback_duration 参数在 3.12 中已废弃，无需手动调优
• CPython 原生事件循环与 uvloop 的性能差距缩小到 5%–10%，除非重度依赖 UDP 或高并发 TLS 握手，否则不必强切
• 必须在 asyncio.run() 之前调用 asyncio.set_event_loop_policy()，否则设置无效

协程对象初始化加速，高频 spawn 场景收益明显

Python 3.12 对 async def 函数返回的协程对象做了内存布局压缩和创建路径内联：协程对象大小从 88 bytes 降到 77 bytes，create_task() 调用耗时下降 18%–22%。

• 该优化对 Web 服务、异步任务队列等频繁 spawn 协程的场景影响最直接
• 但若协程体中混用 exec、eval 或动态属性访问（如 obj.__dict__[key]），会强制退出 specialize 模式，反而比 3.10 更慢
• asyncio.run() 内部仍会创建顶层事件循环，短生命周期脚本（如 CLI 工具）感知较弱

异常传播路径精简，错误处理开销变小

自动化任务常依赖 try/except 处理网络超时、文件缺失等预期异常。3.12 中 asyncio 的异常传播路径被重写，取消了冗余包装和中间帧，同时错误提示更准——比如能定位到具体哪一行 await 抛错，而不是笼统指向 run_until_complete。

• 实测某异步爬虫服务在高并发下异常处理耗时下降约 25%
• 但若使用旧写法如 await asyncio.wait_for(coro, timeout=1) + 手动捕获 TimeoutError，效果不如直接用 asyncio.timeout() 上下文管理器（3.11+ 引入，3.12 进一步优化）
• asyncio.CancelledError 不再被隐式吞掉，需显式处理或重新 raise，否则可能掩盖真实问题

实际提速幅度取决于你的代码是否踩中这些点：纯 I/O 密集型服务（如 HTTP 客户端、Redis 访问）吞吐量提升 10%–30%，但 CPU 密集型协程（比如在 async 函数里做大量数学运算）几乎不受益——它压根不该在协程里干这事。