finally 块在 Python 中并非“仅当逻辑走通才执行”，而是只要对应 try 块已进入（哪怕后续因异常或递归溢出而中止），其 finally 就会在控制权向上回溯时逐层、确定性地执行——这是 Python 异常传播与栈展开的核心保障机制。
`finally` 块在 python 中并非“仅当逻辑走通才执行”，而是只要对应 `try` 块已进入（哪怕后续因异常或递归溢出而中止），其 `finally` 就会在控制权向上回溯时**逐层、确定性地执行**——这是 python 异常传播与栈展开的核心保障机制。
在你的 divisive_recursion 示例中，看似“无限递归”导致程序崩溃，实则 Python 并非粗暴终止，而是通过受控的异常传播机制处理 RecursionError：每当递归深度超限，解释器抛出 RecursionError 异常，该异常会沿调用栈逐层向上传播。而每层调用中，只要 try 块已被进入（无论是否执行完），其对应的 finally 子句就必然在该帧退出前执行——这正是你看到 "Finally block executed for n=1" 和 "Finally block executed for n=2" 被打印的根本原因。
✅ 正确理解 finally 的触发时机
finally 的执行不依赖于 try 块是否“正常完成”，而取决于：
-
try块是否已开始执行（即控制流已进入该try）； - 该
try所在的栈帧是否即将退出（无论是因return、break、continue，还是因未捕获异常导致的栈展开）。
因此，在递归调用链中：
-
divisive_recursion(5)→ enterstry→ callsdivisive_recursion(4) -
divisive_recursion(4)→ enterstry→ callsdivisive_recursion(3) - ……
-
divisive_recursion(1)→ enterstry→ callsdivisive_recursion(0) -
divisive_recursion(0)→ returns1immediately (notry) - Back to
divisive_recursion(1)→ attempts1 // 1→1 // 1 = 1→ callsdivisive_recursion(1)again → … - 最终触发
RecursionError，此时解释器开始从最深层未完成的try帧开始，逐层执行finally，再向上弹出。
这就是为什么你会看到 n=1 和 n=2 的 finally 输出——它们对应的是尚未完全退出的、处于调用栈中较高位置的活跃帧。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
? 验证机制：一个精简复现示例
def demo_finally_unwind(n):
print(f"→ Entering demo({n})")
try:
if n <= 0:
return "base"
else:
# 故意制造 RecursionError
return demo_finally_unwind(n + 1) # 无终止条件，快速溢出
except ValueError:
print(f"✗ Caught ValueError at n={n}")
finally:
print(f"✓ Finally executed for n={n}") # 这行总会打印！
# 触发
try:
demo_finally_unwind(3)
except RecursionError:
print("? RecursionError finally caught at top level")运行输出（节选）：
→ Entering demo(3) → Entering demo(4) → Entering demo(5) ... ✓ Finally executed for n=5 ✓ Finally executed for n=4 ✓ Finally executed for n=3 ? RecursionError finally caught at top level
可见：finally 按照栈后进先出（LIFO）顺序逆向执行，与函数调用顺序相反，但严格保证每层 try 的清理逻辑不被跳过。
⚠️ 注意事项：哪些情况 finally 真的不会执行？
尽管 finally 在绝大多数控制流中断场景下都可靠执行，但以下系统级强制终止会绕过 Python 运行时，导致 finally 完全失效：
-
os._exit()：直接终止进程，不触发任何 Python 清理逻辑； -
SIGKILL（Linux/macOSkill -9）：操作系统信号，无法被捕获或延迟； - 主线程被强制杀死（如
threading.Thread._stop()已弃用，但仍存在类似风险）； - 解释器致命错误（如 C 扩展引发段错误）。
✅ 这些是例外，而非规则；日常开发中，RecursionError、KeyboardInterrupt、未捕获异常等，均完整支持 finally 栈展开。
✅ 总结
-
finally是 Python 资源安全的基石：它不承诺“业务逻辑成功”，但承诺“控制流离开本作用域前必执行”； - 递归崩溃 ≠ 程序硬终止，而是异常驱动的栈展开过程，
finally正是这一过程的关键参与者； - 若你在
finally中释放文件、关闭连接、解锁互斥量，请放心——只要try已进入，它们就绝不会被遗漏。
掌握这一机制，你将写出更健壮、可预测的异常安全代码。
