python 3.11 异常处理更轻量是因为用编译期生成的只读 co_exceptiontable 替代了旧版依赖 setup_finally/pop_block 的动态块栈，使无异常时 try/except 几乎零开销。
BaseException 本身没被“优化”，真正降低异常开销的是 Python 3.11 彻底重构了异常处理的底层机制——用编译期生成的 co_exceptiontable 替代运行时块栈，而 BaseException 作为所有异常的根类，只是新机制的统一入口点。你感知到的“对 BaseException 的优化”，其实是整个异常体系在无异常路径上甩掉了旧版强制执行的 SETUP_FINALLY 和 POP_BLOCK。
为什么旧版 try/except 一写就慢？
Python 3.10 及以前，只要代码里出现 try，解释器就必须在进入时执行 SETUP_FINALLY、在退出时执行 POP_BLOCK。这些指令不管有没有异常都会跑——比如一个高频调用的解析函数，99.9% 的路径都走正常逻辑，却始终为那 0.1% 的异常预留栈操作开销。
co_exceptiontable 怎么让无异常路径变轻？
它是一张只读元数据表，编译时静态生成，运行时只在真正抛异常时才查。正常执行完全绕过所有异常相关字节码：
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
-
RESUME、LOAD_GLOBAL、CALL等指令照常执行，不带任何异常管理副作用 - 没有块栈 push/pop，没有帧状态切换，没有额外栈帧分配
- 哪怕你在
for循环里套 5 层try/except，只要不抛异常，性能几乎等同于裸循环
但 BaseException 子类真的没区别吗？
有区别，但不是性能层面的“优化”：
-
Exception继承自BaseException，但SystemExit、KeyboardInterrupt等也直接继承自BaseException；它们在co_exceptiontable中的跳转规则完全一致 - 真正影响查表效率的是异常发生位置（指令偏移）和
except块覆盖范围，不是异常类型本身 - 用
except BaseException:捕获一切，只会让co_exceptiontable多一条记录，不会拖慢正常路径——但会掩盖SystemExit等信号，这是语义风险，不是性能问题
co_exceptiontable 是编译期固定结构，嵌套越深、except 分支越多，表越大，异常发生时的查表延迟反而略高于旧版——但这个代价只在抛异常时支付，且无法通过改写 BaseException 或子类来规避。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
