python的finally块由字节码指令setup_finally和end_finally硬性保障执行，只要控制流进入try块，无论return、break、异常或sys.exit()均触发；仅os._exit()、sigkill、解释器崩溃等底层中断可跳过。
Python 中的 finally 块“几乎总执行”，不是靠程序员写对逻辑，而是解释器在字节码层面硬性保障的——只要控制流进入了 try 块，对应的 finally 就已被注册为栈帧退出时必须触发的清理钩子。
SETUP_FINALLY 和 END_FINALLY 是强制执行的底层指令
CPython 编译 try...finally 时，会插入 SETUP_FINALLY 指令，在进入 try 块前就将 finally 的地址压入异常处理栈；当栈帧即将销毁（无论因 return、break、未捕获异常，还是 sys.exit() 抛出 SystemExit），解释器都会执行 END_FINALLY，强制跳转到 finally 代码段。
这意味着：
-
sys.exit(0)会触发finally，因为它是通过抛SystemExit异常实现的，仍走正常异常传播路径 -
return在try中写完后，返回值已计算完毕，但函数真正退出前，finally必然运行一次 - 递归调用中发生
RecursionError，所有已进入未退出的try对应的finally会按调用栈逆序逐层执行
哪些情况真的会跳过 finally
跳过 finally 不是语言设计疏漏，而是 Python 运行时被彻底中断的结果：
-
os._exit()：绕过所有 Python 级清理，包括finally、__del__、atexit回调 -
kill -9（SIGKILL）：操作系统直接终止进程，不给解释器任何调度机会 - 解释器崩溃（如 C 扩展引发 segfault）、断电、内核 panic
-
try块根本没开始执行：比如import失败、语法错误、函数调用前参数求值报错（如f(x/0)中除零发生在进入f前）
finally 中 return 会覆盖主流程返回值
这是最容易踩坑的地方：一旦 finally 里有 return，它就会劫持整个函数的返回结果，不管 try 或 except 里写了什么。
示例：
def f():
try:
return "from try"
finally:
return "from finally"
调用 f() 输出 "from finally"。更隐蔽的是没有 return 但修改了可变对象：
def g():
a = [1]
try:
return a
finally:
a.append(2) # 返回的 list 实际是 [1, 2]
这种副作用不会报错，但可能让调试变得困难。
finally 不是资源管理的终点，只是基础保障
finally 可靠，但不等于万能：
- 文件操作优先用
with open(...)，它底层就是try/finally，但更不易出错（不用手动记变量名、不怕忘记写.close()） - 如果
finally自己抛出新异常（比如f.close()时磁盘满），原始异常会被压制，只看到新异常 - 真正关键的持久化操作（如数据库 commit），不能只依赖
finally—— 因为os._exit()或 SIGKILL 下它完全失效
最常被忽略的一点是：你写的 finally 逻辑本身是否经得起中断？比如在 finally 里又开了个网络请求，那它自己也可能失败或卡住，反而拖慢退出过程。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
