Python finally一定执行，因解释器在字节码层用SETUP_FINALLY和END_FINALLY强制注册为栈帧退出钩子，只要try块开始执行，无论return、sys.exit()、未捕获异常或递归退栈，均会执行；仅try未启动或被kill-9等强杀时例外。
因为 Python 解释器在字节码层面强制插入 SETUP_FINALLY 和 END_FINALLY 指令，只要程序进入 try 块，对应的 finally 就被注册为栈帧退出时的 cleanup 钩子——这不是靠逻辑判断，而是运行时强制保障。
finally 不是“大概率执行”，而是解释器级硬性语义
你写的 finally 块，在 CPython 中会被编译成专用字节码指令。只要 try 块开始执行（哪怕只执行了第一行），解释器就已把它标记为“必须清理”。后续无论发生什么：
-
return、break、continue从try或except中跳出 → 先跑finally再跳 -
sys.exit(0)被调用 → 进程退出前仍会执行finally - 未捕获的
RecursionError向上冒泡 → 所有已进入未退出的try对应的finally按调用栈逆序依次执行 - 甚至
try里抛出MemoryError，只要解释器还能调度，finally就会尝试运行
真正会跳过 finally 的两种情况
不是“写法不对导致跳过”，而是根本没机会让解释器启动 cleanup 流程：
-
try块压根没开始执行：比如模块导入阶段就ImportError，或进程启动失败 -
finally自己执行到一半被外部强杀：如kill -9、断电、内核 panic
注意：os._exit() 会绕过 Python 解释器的清理机制，它不触发 finally；而 sys.exit() 是抛出 SystemExit 异常，会被 finally 捕获并执行。
立即学习“Python免费学习笔记（深入）”；
finally 里写 return 或 raise 会改变主流程
这是设计使然，不是 bug，但极易被忽略：
- 如果
try里有return "ok"，finally里也有return "cleanup"→ 实际返回的是"cleanup" - 如果
finally中抛出新异常（比如raise ValueError("close failed")）→ 原异常被吞掉，新异常向上冒泡 - 资源清理逻辑若本身可能失败（如文件句柄已失效还调
f.close()），建议在finally内加try/except包裹，避免掩盖主异常
最常被低估的点是：finally 的可靠性来自字节码层，不是程序员写的逻辑；但它的副作用（覆盖返回值、吞异常）也一样不可回避——用之前得想清楚，清理动作是否允许中断原本的控制流。
