python 3.11 的 exceptiontable 是编译期生成的只读元数据表（co_exceptiontable），取代了 3.10 及以前依赖 setup_finally/pop_block 的动态块栈机制，使无异常时 try/except 几乎零开销。

Python 3.11 的 try/except 在无异常时几乎不耗性能，这不是优化宣传，而是字节码层的结构性替换：ExceptionTable 取代了旧版依赖 SETUP_FINALLY 和 POP_BLOCK 的动态块栈。

ExceptionTable 是什么，它怎么替代 SETUP_FINALLY？

在 Python 3.10 及以前，只要进入 try 块，解释器就必须执行 SETUP_FINALLY、SETUP_EXCEPT 等指令；离开时还要 POP_BLOCK。这些指令无论是否抛异常，都得走一遍——属于“静态开销”。

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

python-script-generator

快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。

下载

• ExceptionTable 不是运行时数据结构，不能被修改或重载
• 用 dis.dis() 查看函数字节码，末尾出现的 ExceptionTable: 就是它
• 例如 L1 to L4 -> L5 [2] 表示：从偏移 L1 到 L4 的指令范围内若抛异常，跳转至 L5 处理

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

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

• 实测多数场景下，无异常时 try 块与普通代码块性能差异可忽略
• 触发异常时，回溯信息生成延迟到首次访问 sys.exc_info() 或打印 traceback 时，而非抛出瞬间
• 但进入 except 分支本身的延迟略高于 3.10，因要查表 + 定位目标偏移

哪些代码能明显感知这个轻量优势？

不是所有 try/except 都能体现提升——关键看异常发生频率与代码热点位置。

• 高频调用、低异常率的封装函数（如 json.loads() 内部解析、pathlib.Path.exists() 底层检查）收益最明显
• 用异常做控制流的代码（如协议解析器靠 ValueError 切换状态）现在更可行，但依然不推荐滥用
• IO 密集型任务（如大量 open() + except FileNotFoundError）提升有限，因瓶颈在系统调用，不在解释器
• 若 except 块本身含重逻辑（如日志序列化、网络上报），异常处理总耗时不快，只是“不抛异常时更快”

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

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！