为什么Python 3.11异常处理机制比旧版本更加轻量化？

Python 3.11 的 try/except 在无异常时几乎零开销，因其用编译期生成的只读 co_exceptiontable 替代了旧版依赖 SETUP_FINALLY/POP_BLOCK 的动态块栈机制，仅在真正抛异常时查表跳转，正常路径不执行任何异常相关字节码。

try/except 在 Python 3.11 中无异常时几乎不耗性能，这不是宣传话术，而是字节码层的结构性替换：旧版靠 SETUP_FINALLY 和 POP_BLOCK 维护运行时块栈，新版用编译期生成的只读 co_exceptiontable 替代。

ExceptionTable 是什么，怎么替代 SETUP_FINALLY？

Python 3.10 及以前，只要代码进了 try 块，解释器就必须执行 SETUP_FINALLY、SETUP_EXCEPT 等指令；退出时还得 POP_BLOCK。这些指令不管有没有异常都得走一遍——属于“静态开销”。

Python 3.11 把所有异常跳转逻辑抽出来，在编译期生成一张只读元数据表（即 co_exceptiontable），运行时只在真正抛异常时查这张表。正常路径里，连一个异常相关字节码都不执行。

• dis.dis() 输出末尾出现的 ExceptionTable: 就是它
• 例如 L1 to L4 -> L5 [2] 表示：从偏移 L1 到 L4 的指令范围内若抛异常，跳转至 L5 处理
• co_exceptiontable 是编译期产物，不能被运行时修改或重载

为什么说“几乎零成本”，而不是“绝对零成本”？

“几乎”二字很关键：解释器仍需为每条可能抛异常的指令预留查表入口，这部分极轻量的间接寻址开销无法完全消除；但相比旧版每次进/出块都要推/弹栈，已降为常数级微小代价。

实测多数场景下，无异常时 try 块与普通代码块性能差异可忽略。

立即学习“Python免费学习笔记（深入）”；

• 高频调用、低异常率的封装函数（如 json.loads() 内部解析、pathlib.Path.exists() 底层检查）收益最明显
• 用异常做控制流的代码（如协议解析器靠 ValueError 切换状态）现在更可行，但依然不推荐滥用
• IO 密集型任务（如大量 open() + except FileNotFoundError）提升有限，因瓶颈在系统调用，不在解释器

哪些地方容易被忽略？

真正容易被忽略的点是：co_exceptiontable 是编译期产物，它不随运行时条件变化——嵌套 try、finally、else 的组合方式会直接影响表的大小和查表深度，但开发者无法手动干预或优化它。

另外，except 块本身含重逻辑（如日志序列化、网络上报）时，异常处理总耗时不快，只是“不抛异常时更快”；而触发异常时，回溯信息生成延迟到首次访问 sys.exc_info() 或打印 traceback 时，而非抛出瞬间——这点常被误认为“慢了”，其实是延迟加载策略生效。