ExceptionTable是Python 3.11+字节码中存储异常跳转元数据的只读表，它用静态查找替代了3.10及以前依赖SETUP_FINALLY/POP_BLOCK等指令的动态块栈操作，使无异常时几乎零开销——仅保留极轻量的间接寻址，而不再执行任何异常相关字节码。
Python 3.11 的 try/except 在无异常时确实几乎不耗性能，这不是宣传话术，而是字节码层的结构性改变 —— ExceptionTable 替换了旧版的块栈操作。
ExceptionTable 是什么，它怎么替代了 SETUP_FINALLY？
在 Python 3.10 及以前，try 块一进入就要执行 SETUP_FINALLY、SETUP_EXCEPT 这类指令，离开时还要 POP_BLOCK。这些指令无论是否抛异常，都得走一遍，属于“静态开销”。
Python 3.11 把所有异常跳转逻辑抽出来，编译时生成一张静态查找表（即 ExceptionTable），运行时只在真正抛异常时才查这张表。正常路径里，连一个异常相关字节码都不执行。
-
ExceptionTable不是运行时数据结构，而是代码对象（co_exceptiontable）里的只读元数据 - 它记录的是“从哪条指令偏移量到哪条，发生异常时跳去哪”，例如
L1 to L4 -> L5 [2] - 你用
dis.dis()看函数字节码，末尾出现的ExceptionTable:就是它
为什么说“几乎零成本”，而不是“绝对零成本”？
“几乎”二字很关键：解释器仍需为每条可能抛异常的指令预留查表入口，这部分极轻量的间接寻址开销无法完全消除；但相比旧版每次进/出块都要推/弹栈，已降为常数级微小代价。
立即学习“Python免费学习笔记（深入）”；
- 不触发异常时，
try块和普通代码块性能差异可忽略（实测多数场景差距 - 触发异常时，回溯信息生成延迟到首次访问
sys.exc_info()或打印 traceback 时，而非抛出瞬间 - 但异常实际被处理（如进入
except分支）的延迟略高于 3.10，因要查表+定位目标偏移
哪些代码能明显受益于 Zero-cost Exception？
不是所有 try/except 都能感知提升 —— 关键看异常发生频率与代码热点位置。
- 高频调用、低异常率的封装函数（如
json.loads()内部解析、pathlib.Path.exists()的底层检查）收益最明显 - 用异常做控制流的代码（如某些协议解析器里靠
ValueError切换状态）现在更可行，但依然不推荐滥用 - IO 密集型任务（如大量文件
open()+except FileNotFoundError）提升有限，因瓶颈在系统调用，不在解释器 - 注意：若
except块本身含重逻辑（如日志序列化、网络上报），那异常处理总耗时不会变快，只是“不抛异常时更快”
真正容易被忽略的点是：ExceptionTable 是编译期产物，它不随运行时条件变化 —— 也就是说，嵌套 try、finally、else 的组合方式会直接影响表的大小和查表深度，但开发者无法手动干预或优化这张表。你写的结构，就是它最终的样子。
