Python程序员每天都在写try、except、finally，但真正打开dis模块看过字节码的人并不多。在这些字节码中，END_FINALLY曾是一条非常关键又容易被误解的指令。它承担着异常处理流程的收尾工作，串联起finally块的执行、异常的继续传播以及栈的清理。随着Python版本的迭代，这条指令经历了多次改名、拆分，最终在Python 3.11中被彻底移除，取而代之的是一套全新的零成本异常处理机制。理解它的来龙去脉，是读懂CPython虚拟机异常处理逻辑的一把钥匙。
一、END_FINALLY指令到底是什么
要理解END_FINALLY，先要明白Python的finally块在字节码层面是如何被执行的。CPython是基于栈的虚拟机，异常处理的控制流也是通过操作数栈来完成的。当异常发生时，虚拟机会把异常相关的信息压入栈中，包括异常类型、异常值和回溯信息，这三个对象合称异常状态。
END_FINALLY的职责可以用一句话概括：负责处理finally块结束后的善后工作。它会检查栈顶的内容，然后根据不同的情况做出三种不同的分支决策。第一种情况，栈顶是None，说明finally块是正常执行完毕的，程序直接继续往下走。第二种情况，栈顶是一个整数，这表示finally块是由break或continue等跳转语句触发的，虚拟机会沿着这个整数指定的目标继续跳转。第三种情况，栈顶是异常对象或者特殊的标记对象，说明当前有异常正在传播，END_FINALLY会把异常状态重新压回栈中，让虚拟机继续抛出这个异常。
我们可以用dis模块来观察一段简单代码在Python 3.8中的字节码：
import dis
def demo():
try:
return 1
finally:
print("cleanup")
dis.dis(demo)
在这段字节码中，你会看到BEGIN_FINALLY出现在finally块开始的位置，它会把一个None压入栈中作为标记。而END_FINALLY出现在finally块代码的末尾，负责根据栈顶的实际情况决定后续的执行路径。这种设计把复杂的控制流判断浓缩到了一条指令里，但也带来了理解上的负担，因为同一条指令的行为是上下文相关的。
二、Python 3.9的重大改动：一条指令拆成三条
END_FINALLY这种多态行为在Python 3.9中发生了变化。CPython开发者认为，让一条指令承担多种语义不利于优化，也让字节码的可读性变差。于是在Python 3.9中，END_FINALLY被拆分成三条语义更明确的指令：BEGIN_FINALLY被POP_BLOCK等机制配合的RERAISE取代了一部分职责，而END_FINALLY本身被拆成了END_ASYNC_FOR、POP_FINALLY和RERAISE的组合。
具体来说，POP_FINALLY负责处理finally块正常结束时的栈清理工作，也就是原来栈顶为None或整数标记的那种情况。而RERAISE专门负责重新抛出异常，它只在栈中存在异常状态时才会被执行到。这种职责分离让每条指令的行为都变得确定，不再需要运行时去检查栈顶类型再分支。
我们来对比一下Python 3.9中同样的代码：
import dis
def demo():
try:
return 1
finally:
print("cleanup")
dis.dis(demo)
在Python 3.9的输出中，你会发现RERAISE和POP_FINALLY出现在了原来END_FINALLY的位置。RERAISE会重新抛出当前栈上的异常，并保留原始的回溯信息，这对调试非常重要。而POP_FINALLY则更聪明一些，它接受一个参数，用来指示栈上是否有保留的值需要处理，这让return语句与finally块的交互变得更加清晰。
这次拆分的另一个动机是为后续的优化铺路。字节码指令的语义越单一，做窥孔优化和栈分析就越容易。事实上，Python 3.9的这次改动正是3.11大版本零成本异常处理的前奏。
三、Python 3.11：零成本异常处理与END_FINALLY的终结
Python 3.11对异常处理机制进行了彻底重构，引入了所谓的零成本异常处理。在这套新机制中，END_FINALLY、BEGIN_FINALLY、POP_FINALLY、RERAISE这些指令要么被移除，要么被重新设计，取而代之的是一套基于异常表的结构化处理方式。
零成本异常处理的核心思想是：happy path上不付出任何代价。在旧机制中，进入try块需要执行SETUP_FINALLY之类的指令来设置处理器的元信息，即使异常从未发生，这些指令的执行开销也无法避免。而在新机制中，CPython编译器会生成一张异常表，记录每个字节码区间对应的异常处理器位置。正常执行时，虚拟机完全不碰这些信息，只有当异常真正发生时，才去查异常表找到对应的处理器并跳转过去。
下面这段代码在Python 3.11中的字节码会明显不同：
import dis
def demo():
try:
return 1
finally:
print("cleanup")
dis.dis(demo)
你会看到finally块不再由专门的栈操作指令序列驱动，而是通过异常表中的条目来关联。PUSH_EXC_INFO、CHECK_EXC_MATCH、RERAISE等指令承担了新的角色，而原来的END_FINALLY已经无迹可寻。这种设计让没有异常发生时的代码路径几乎与不写try语句完全一样，这是Python 3.11整体性能提升的重要来源之一。
四、理解这段演变对实际开发的意义
也许有人会觉得，我平时写业务代码，不需要关心字节码层面的细节。但实际上，理解END_FINALLY的演变至少有三个实际价值。
第一，它能帮助你理解finally块的一些微妙行为。比如finally块中的return语句会吞掉异常，这个行为在字节码层面看得一清二楚。当finally里有return时，异常状态会被直接弹出丢弃，这就是为什么有经验的开发者会强烈反对在finally块中写return。
第二，阅读不同版本的字节码时不会感到困惑。如果你在排查性能问题或者研究某个库的实现时打开dis的输出，看到END_FINALLY就知道代码运行在Python 3.8或更早的版本上，看到RERAISE加POP_FINALLY的组合就知道是3.9或3.10，而看到异常表结构的输出则说明是3.11及以后。这种版本敏感度在维护多版本兼容的库时尤其重要。
第三，理解零成本异常处理能影响你的编码决策。在新机制下，try块本身的开销几乎为零，真正有代价的是异常的实际抛出和捕获。这意味着频繁抛出异常作为控制流的使用方式依然昂贵，但大胆地用try来包裹可能出错的代码不再需要担心性能惩罚。这个认知转变能让你写出既清晰又高效的Python代码。
从END_FINALLY的多态设计，到3.9的职责拆分，再到3.11的异常表驱动，这条指令的演变史恰好折射出CPython虚拟机逐步走向现代优化的过程。下次打开dis模块时，不妨多花几分钟看看那些字节码背后的设计权衡，你会发现Python远比表面看起来更有深度。
Python字节码END_FINALLY指令异常处理机制修改时间：2026-09-08 19:20:58