Python 的 try-finally 把我坑惨了，原来在 return 之后它还会"插队"执行

这就好比你跟领导说"我要辞职"（准备 return），领导说"等一下，给你涨薪 50% 留不留？"（finally 里的 return），你果断把"辞职"两个字咽回去，接受了涨薪。后来的决定覆盖了之前的决定。

这种"劫持"在复杂的业务逻辑里极其危险。比如你在 try 里辛苦计算出一个结果准备返回，finally 里为了打日志又写了个 return，直接把业务结果覆盖了。这种 bug 非常难查，因为日志里看到的返回值跟你预期的不一样，而且你根本想不到是 finally 干的。

所以这里有一条硬规矩：永远不要在 finally 块里写 return、break 或 continue。finally 只负责"善后"（关资源、写日志、释放锁），不应该改变函数的返回值或控制流。

5. 另一个坑：finally 里抛异常，会把 try 里的异常"吃掉"

这是一个更隐蔽的坑。

假设你在 try 块里抛出了一个业务异常，然后在 finally 里关资源的时候又抛出了一个新的异常。猜猜调用方会收到哪个？

class BusinessError(Exception):

pass

class CloseError(Exception):

pass

def risky_operation():

try:

print("执行业务逻辑...")

raise BusinessError("业务处理失败了")

finally:

print("清理资源...")

raise CloseError("关闭连接失败了")

try:

risky_operation()

except Exception as e:

print(f"捕获到异常: {type(e).__name__}: {e}")

输出：

执行业务逻辑...

清理资源...

捕获到异常: CloseError: 关闭连接失败了

业务异常 BusinessError 不见了！ 调用方只看到了 CloseError，完全不知道业务层面出了什么问题。

这就是"异常被覆盖"的问题。finally 里抛出的异常会覆盖 try 里抛出的异常，导致真正的错误原因被"吞掉"。你花几个小时排查，最后发现业务逻辑没错，是关连接的时候出了问题，但真正该报错的业务异常却被掩盖了。

解决方案： 在 finally 里如果要关资源，用嵌套的 try-except 把清理逻辑包起来，不要让清理异常往外冒。

def safe_operation():

try:

raise BusinessError("业务处理失败了")

finally:

try:

# 清理资源，可能抛异常

close_connection()

except Exception as e:

# 记录日志，但不往上抛

print(f"清理失败，不影响主流程: {e}")

这样业务异常就能正常传播给调用方了。

6. 不止 return，break 和 continue 也逃不过 finally 的"魔爪"

finally 的"插队"能力不只针对 return，对循环里的 break 和 continue 同样有效。

def test_break():

for i in range(3):

try:

print(f"循环第 {i} 次，准备 break")

break

finally:

print(f"finally 执行了，i={i}")

print("循环结束了")

test_break()

输出：

循环第 0 次，准备 break

finally 执行了，i=0

循环结束了

看到没？break 本来要直接跳出循环，但 finally 硬是在跳出之前执行了一次。

continue 也一样：

def test_continue():

for i in range(3):

try:

if i == 1:

print(f"i={i}，准备 continue")

continue

print(f"i={i}，正常执行")

finally:

print(f"finally 执行了，i={i}")

test_continue()

输出：

i=0，正常执行

finally 执行了，i=0

i=1，准备 continue

finally 执行了，i=1

i=2，正常执行

finally 执行了，i=2

continue 被拦截了，finally 先跑完，continue 才真正生效。

所以规则可以统一成一句话：

finally 是"退出当前作用域"之前的最后一道关卡。不管你是正常退出、return、break、continue 还是抛异常，都得先过 finally 这一关。

7. 你真正该用 try-finally 的地方

虽然我前面一直在讲坑，但 try-finally 本身是个好东西，是 Python 里管理资源的基础设施。关键是要用对地方。

正确的用法场景一：资源释放

def read_file_safely(path):

f = open(path, "r")

try:

return f.read()

finally:

f.close() # 无论 read 成功还是失败，文件都会被关掉

这是 try-finally 最经典的用法。当然，现在用 with open 更优雅，但底层原理是一样的。

正确的用法场景二：锁的释放

import threading

lock = threading.Lock()

def update_shared_data():

lock.acquire()

try:

# 修改共享数据

shared_data["count"] = 1

finally:

lock.release() # 无论如何都释放锁，防止死锁

正确的用法场景三：计时统计

import time

def track_time(func):

def wrapper(*args, kwargs):

start = time.time()

try:

return func(*args, kwargs)

finally:

elapsed = time.time() - start

print(f"{func.__name__} 耗时: {elapsed:.3f}s")

return wrapper

无论函数执行成功还是失败，耗时都会被记录下来。

正确的用法场景四：数据库事务的收尾

def execute_transaction(conn):

cursor = conn.cursor()

try:

cursor.execute("BEGIN")

# 执行多条 SQL

cursor.execute("UPDATE ...")

cursor.execute("INSERT ...")

conn.commit()

finally:

cursor.close() # 无论如何都关游标

8. 永远记住：finally 是"最后的守护者"

经历了凌晨两点的扣费事故之后，我给 try-finally 下了一个定义，分享给你：

finally 是函数里的"最后守护者"。它不是"可能执行"，而是"必定执行"。不管前面的路怎么走，最终都得路过它。

这个"必定执行"的特性，既是它的价值所在（确保资源释放），也是它的危险所在（可能干扰业务逻辑）。

用 try-finally 的时候，心里要时刻装着两个原则：

原则一：finally 只做"善后"，不做"决策"。