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是编译期产物，不能被运行时修改或重载
为什么说“几乎零成本”，而不是“绝对零成本”？
“几乎”二字很关键：解释器仍需为每条可能抛异常的指令预留查表入口，这部分极轻量的间接寻址开销无法完全消除；但相比旧版每次进/出块都要推/弹栈，已降为常数级微小代价。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
实测多数场景下，无异常时 try 块与普通代码块性能差异可忽略。
- 高频调用、低异常率的封装函数（如
json.loads()内部解析、pathlib.Path.exists()底层检查）收益最明显 - 用异常做控制流的代码（如协议解析器靠
ValueError切换状态）现在更可行，但依然不推荐滥用 - IO 密集型任务（如大量
open()+except FileNotFoundError）提升有限，因瓶颈在系统调用，不在解释器
哪些地方容易被忽略？
真正容易被忽略的点是：co_exceptiontable 是编译期产物，它不随运行时条件变化——嵌套 try、finally、else 的组合方式会直接影响表的大小和查表深度，但开发者无法手动干预或优化它。
另外，except 块本身含重逻辑（如日志序列化、网络上报）时，异常处理总耗时不快，只是“不抛异常时更快”；而触发异常时，回溯信息生成延迟到首次访问 sys.exc_info() 或打印 traceback 时，而非抛出瞬间——这点常被误认为“慢了”，其实是延迟加载策略生效。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
