finally块总执行，由CPython字节码SETUP_FINALLY强制保障；唯一不执行的情况是try未开始或进程被系统级强杀；finally中return会覆盖返回值，应仅做无副作用清理。
Python 中 try-finally 的 finally 块一定会执行，不是靠“程序员写了就运行”，而是解释器在字节码层面强制保障的——只要控制流进入了 try 块，对应的 finally 就被注册为退出钩子，不管后面是 return、break、未捕获异常，还是 sys.exit()，只要 Python 还能调度，就一定走一遍。
SETUP_FINALLY 指令才是真正的执行保证
CPython 编译时，遇到 try-finally 会生成 SETUP_FINALLY 指令，把 finally 块地址压入当前栈帧的 finally 链表。当栈帧准备销毁（无论因 return、异常、还是正常结束），解释器必须触发 END_FINALLY，跳转执行 finally 里的代码。
这意味着：
-
finally不依赖逻辑判断，不看上层有没有except，也不管try里有没有return - 你用
dis.dis()看字节码，一定能找到SETUP_FINALLY和它指向的POP_BLOCK/END_FINALLY区域 - 哪怕
try里第一行就return "done"，finally也照跑不误——因为 return 不是“立刻退出”，而是暂存返回值、标记退出状态，再强制跳进finally
finally 里写 return 会覆盖函数返回值
这是最容易踩坑的地方：finally 中的 return 不是“顺便执行清理”，而是直接接管整个函数退出流程。
立即学习“Python免费学习笔记（深入）”；
常见错误现象：
- 调用方收到
"closed"，但业务其实失败了——因为finally的return吞掉了try中本该抛出的异常或返回的错误码 - 调试器单步看到
try返回了42，最终结果却是None，只因finally末尾有return且没写值 -
result = []在try中append(1)后return result，finally又append(2)，调用方拿到的是[1, 2]——可变对象引用被修改了
真正跳过 finally 的只有两种情况
不是“有时不执行”，而是有明确边界：要么 try 根本没开始，要么进程被系统级强杀。
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
不会触发 finally 的典型场景：
-
try前就出错：比如函数参数解析失败、模块导入时报ImportError、甚至语法错误导致根本无法编译 -
os._exit()或os.kill(os.getpid(), 9)：绕过 Python 解释器，直接终止进程 - 断电、内核 panic、容器被
kill -9：字节码执行链被硬中断
而这些情况，with 语句、contextlib.closing 等基于 try-finally 的资源管理机制同样失效——这不是设计缺陷，是运行时环境的客观限制。
finally 应该只做无副作用的清理
安全写法的核心是解耦：返回值归业务逻辑管，清理归 finally 管，二者不能混在同一块里。
推荐结构：
- 声明
result = None或占位值 - 所有分支（
try/except/else）只赋值给result，不return -
finally里只调file.close()、lock.release()、cursor.close()，绝不读写result，更不return - 函数末尾统一
return result
主流 IDE（PyCharm、VSCode + Pylance）对 finally 中的 return 会标黄警告 “Finally block cannot complete normally”，这不是建议，是明确提示控制流已被劫持——看到这个警告，就得停下来重审逻辑。
真正难的不是记住“finally 总执行”，而是习惯性把清理和返回拆开；一旦在 finally 里动了返回值或可变对象，问题往往静默发生，日志不报错、HTTP 返回 200、监控看不出异样，直到数据不一致暴露出来。
