finally 中的 return 会覆盖 try/except 的返回值和异常，因其在函数退出前强制终止流程并替换暂存结果；应分离清理与返回逻辑，仅在函数末尾统一 return。
因为 finally 中的 return 会接管函数退出流程，直接丢弃已暂存的返回值或异常。这不是 bug，是 Python 明确定义的行为——但极易引发逻辑错误，尤其在资源清理与业务返回混写时。
finally 里的 return 为什么能覆盖 try 的返回值？
Python 函数返回不是“一步到位”，而是分两步：先求值暂存，再跳转执行 finally。只要 finally 里有 return，它就强制终止当前函数出口，用新值替换暂存结果。
-
try中执行return "ok"→ 值"ok"被暂存，但不立即返回 - 控制流转向
finally块 -
finally执行return "cleanup"→ 暂存值被丢弃，函数直接返回"cleanup"
常见误用场景：文件读取 + finally return
想确保文件关闭又返回数据，却把两者都塞进 finally，结果业务逻辑永远失效：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
def read_config():
f = None
try:
f = open("config.json")
return json.load(f) # ← 这个 return 永远不会生效
except FileNotFoundError:
return {"default": True} # ← 这个也不会生效
finally:
if f:
f.close()
return "closed" # ← 所有上面的 return 都被覆盖- 即使
json.load(f)成功，调用方拿到的也是字符串"closed" - 如果
f.close()失败（如磁盘只读），还会抛出新异常，掩盖原始问题 - 这种写法让错误路径和正常路径全部不可观测
安全写法：分离清理与返回逻辑
资源释放和返回决策必须解耦。所有 return 统一收口到函数末尾，finally 只做无副作用清理：
立即学习“Python免费学习笔记（深入）”；
def read_config():
f = None
result = None
try:
f = open("config.json")
result = json.load(f)
except FileNotFoundError:
result = {"default": True}
finally:
if f:
f.close() # ← 不 return，不 raise
return result # ← 唯一的 return 位置- 用局部变量
result缓存业务结果 -
finally只负责f.close()、lock.release()等确定性操作 - 配合
pylint的W0717规则可自动检测finally中的return
真正难防的是嵌套多层、带日志或状态更新的 finally —— 它可能藏在几十行外，且不报错、不警告，只悄悄改掉你的返回值和异常传播路径。
