python 3.11异步性能提升源于协程构造与await执行的底层优化：async def首次调用快15%～20%，因字节码更紧凑、帧初始化开销降低；await对同类型可等待对象启用地址缓存，跳过属性查找，但混用类型会导致缓存失效。
Python 3.11 的异步性能提升不是靠“换事件循环”或“加线程”实现的，而是解释器在协程对象构造和 await 执行两个关键环节做了不可见但切实有效的底层收窄——你不用改代码，只要用对场景、避开退化条件，就能拿到 15%～20% 的冷启动加速和更稳的高并发吞吐。
async def 函数首次调用为什么变快了
每次执行 async def 函数，CPython 都要分配一个新 frame 对象、初始化状态机、填充局部变量表。这个过程在 3.10 是“重装上阵”，到 3.11 变成“轻装出发”：
- 字节码更紧凑：比如
async def f(): await asyncio.sleep(0)，3.10 编译出 12 条指令，3.11 压缩为 9 条，直接减少帧初始化开销 - 移除了冗余栈操作和泛化
YIELD_FROM路径，转为针对协程的特化路径 - 提速集中在“第一个调用”——也就是 ASGI 请求入口、FastAPI 路由函数冷启动时最明显；后续调用差异收敛，因为 frame 复用机制本身没变
await 表达式内联加速的触发与失效条件
3.11 对 await 后面的对象做运行时地址缓存，跳过 __await__ 属性查找。但它不是无脑缓存，而是有明确约束：
- 必须是同一代码位置（比如同一个
await db.query()行）反复 await 同一类对象（如全是asyncpg.Record或全是asyncio.Future） - 一旦混用类型——比如这行有时
await httpx.get(...)，有时await asyncio.sleep(0)——缓存立即失效，退化为 3.10 的通用查找路径，甚至因额外判断逻辑略慢 - 可通过
dis.dis观察是否出现CALL_INTRINSIC_1指令来确认是否启用内联
为什么本地 timeit 测不出提升
很多人跑 timeit.timeit("await asyncio.sleep(0)", ...) 发现 3.10 和 3.11 差距不到 1%，就认为“没优化”。问题不在解释器，而在测试方式：
-
asyncio.sleep(0)本质是立即 resolve 的Future，耗时瓶颈在事件循环调度层（loop._ready队列操作），而非 Python 帧执行 - 真实受益场景是协程体复杂、含多层嵌套
await、且被高频创建——比如每个 HTTP 请求都新建一个协程，里面调三次数据库 + 一次外部 API - 必须关闭优化模式：
python -O会禁用所有特化机制；调试器（sys.settrace）也会强制关闭内联路径
TaskGroup 不是性能优化，但让异步更可控
asyncio.TaskGroup 本身不提速，但它改变了异常传播模型，间接影响高并发下的稳定性表现：
- 相比
asyncio.gather的“一错全杀”，TaskGroup允许其他任务响应取消并执行async with/finally清理逻辑，避免资源泄漏导致后续请求卡顿或内存缓慢增长 - 它要求所有子任务在
async with TaskGroup()块内通过tg.create_task()启动；在块外await单个任务会报RuntimeError: TaskGroup is closed - 异常捕获必须用
except*（PEP 654），不能用普通except，否则无法解包ExceptionGroup
真正容易被忽略的点是：这些优化都依赖进程内累积的 adaptive_state，容器重启、Lambda 冷启动、Gunicorn prefork 子进程继承不完整——意味着你压测时看到的峰值性能，在生产环境刚上线那几分钟可能根本达不到。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
