finally中的return会覆盖try中的return并终结函数，即使try抛出异常也会被吞掉；java禁止finally中return而python允许，移植时易出错。
try-finally里return被覆盖的真实顺序
在 try 块中执行 return，不代表函数立刻返回——finally 一定会运行，且它里面的 return 会直接终结函数，覆盖前面所有返回值。
这不是“异常干扰”，而是明确的控制流规则：只要 finally 中有 return，它就拥有最终决定权。
-
try中的return会先计算表达式（比如return x++的x当前值），但不提交返回，而是挂起 - 接着无条件进入
finally；若其中也有return，则挂起的值被丢弃，新return立即生效 - 即使
try抛出异常，只要finally有return，异常也会被吞掉（这点极容易被忽略）
def example():
try:
return "from try"
finally:
return "from finally" # 实际返回这个
Java和Python在finally-return上的行为差异
Java 和 Python 表面写法相似，但底层语义不同：Java 编译器禁止在 finally 中写 return（编译报错 error: unreachable statement），而 Python 允许且按上述逻辑执行。
这意味着：同一段逻辑在两种语言里移植时，如果没意识到这个差异，Java 版本可能根本编译不过，而 Python 版本看似能跑，实则返回值已静默改变。
- Java：
finally中写return→ 编译失败，必须改用try-catch-finally分离逻辑 - Python：
finally中写return→ 合法，但会压制try和except中的return，包括异常抛出 - JavaScript（
try...finally）不支持return在finally中（语法错误），但try...catch...finally中若catch或finally有return，行为同 Python
常见误用场景：资源清理+提前返回
最典型的问题是想“安全关闭文件再返回结果”，却把 close() 和 return 都塞进 finally，导致业务结果被覆盖。
例如读取配置后立即返回解析结果，但误写成：
def load_config():
f = open("config.txt")
try:
return json.load(f) # 想返回解析结果
finally:
f.close()
return {} # 错！这里让函数永远返回空字典
- 正确做法：清理操作（如
close()）只做副作用，不要在finally里return - 如果真需要统一出口，把返回值存在变量里，在
finally外return - 更推荐用上下文管理器（Python
with）或try-with-resources（Java），彻底解耦清理与返回
调试时如何快速定位return被覆盖
现象通常是：函数行为不符合预期，日志显示“进了try，也该返回A”，结果得到B——尤其当 B 是个默认值、空值或固定字符串时，大概率是 finally 悄悄 return 了。
- 搜索整个函数体：查找所有
return，特别注意是否出现在finally:或} finally {块内 - 检查 IDE 是否对
finally中的return给出警告（PyCharm 默认标为 “Unreachable code”） - 加临时打印：在每个
return前加print("returning X")，观察哪条实际输出 - 注意缩进陷阱：Python 中
finally块末尾多一个空行或缩进错位，可能导致某行意外落入其中
这个机制本身没有错，错的是把它当成“总能执行的收尾代码”来用，而忘了它其实能劫持控制流。一旦有 return、raise 或 os._exit() 出现在 finally 里，它就不再是“收尾”，而是“终局裁决”。
