finally 中的 return 会强制覆盖 try/catch 的返回值，JVM 以 finally 的退出指令为准；若 finally 抛异常，则压制原异常；因此 finally 中不应含 return，仅用于资源清理。
finally 中写 return 会覆盖 try/catch 的返回值
Java 规定：只要 finally 块中存在 return，无论 try 或 catch 是否已执行过 return，最终方法返回的都是 finally 中的值。这不是“覆盖”语义上的覆盖，而是 JVM 字节码层面强制以 finally 的退出指令为准。
-
try中return 1;→ 表达式求值并暂存返回值，但不立即退出 - 接着执行
finally块 -
finally中若有return 2;→ 直接返回2，丢弃之前暂存的1 - 若
finally没有return，才真正返回try或catch中暂存的值
try/catch/finally 的执行顺序与异常传播关系
关键在于：异常是否被 catch，以及 finally 是否抛出新异常或 return。JVM 执行流程是确定的：
- 正常流程（无异常）：
try→finally→ 方法返回 - 异常未被捕获：
try抛异常 →finally执行 → 异常继续向上抛 - 异常被
catch处理：try→catch→finally→ 返回或继续抛 -
finally中抛出异常：会压制try或catch中的异常（即原异常丢失），仅传播finally的异常
return 在 finally 中的典型陷阱示例
下面这段代码返回结果是 2，不是 1，也不是抛出 NullPointerException：
public static int getValue() {
int x = 0;
try {
return x = 1;
} finally {
return x = 2;
}
}
更危险的是这个情况：
立即学习“Java免费学习笔记（深入）”；
public static String getStr() {
try {
throw new RuntimeException("from try");
} finally {
return "from finally"; // 原异常被彻底吞掉
}
}
- 调用
getStr()得到"from finally"，RuntimeException消失无踪 - 如果
finally中写的是throw new RuntimeException("from finally");，则原异常永远不可见 - 这种行为在资源清理逻辑中极易掩盖真实错误，调试时非常难定位
为什么不应该在 finally 中写 return
这不是风格问题，而是破坏控制流的硬性缺陷：
- 违反方法语义：调用者无法预期返回值来自哪里
- 破坏异常链：
try或catch中的异常可能被静默丢弃 - 干扰调试：断点在
try的return行看似会返回，实际不会生效 - 静态检查工具（如 SonarQube、ErrorProne）默认报错：
Finally block should not contain a return statement
真正需要在 finally 中做的，只有资源释放（如 close()）、状态重置等副作用操作；所有返回逻辑必须严格保留在 try 或 catch 块末尾，且确保 finally 绝不中断它。
