finally 中的 return 会覆盖 try/catch 的返回值并丢弃暂存结果；若 finally 抛异常，则吞掉 try/catch 的返回或异常；finally 应仅用于清理资源，禁止 return 或 throw。
finally 里写 return 会覆盖 try/catch 中的 return
这是最常被误解的一点：只要 finally 块中执行了 return，它就会直接结束方法，且忽略 try 或 catch 中已经准备好的返回值。JVM 会在执行 finally 前暂存 try/catch 的返回值，但一旦 finally 自己 return，这个暂存值就被丢弃。
示例：
public static String test() {
try {
return "from try";
} finally {
return "from finally"; // ✅ 实际返回这个
}
}
调用 test() 得到的是 "from finally"，不是 "from try"。
finally 中 return 会让 catch 里的异常“消失”
如果 try 抛出异常、catch 捕获并做了处理（比如记录日志），但 finally 中又写了 return，那整个方法就正常返回了——原异常彻底丢失，连栈跟踪都不可见。
立即学习“Java免费学习笔记（深入）”；
常见错误场景：
-
try中打开文件流，发生IOException -
catch打印了错误日志 -
finally调用了close()并return true
结果：调用方收不到任何异常，以为操作成功，但实际文件读取早已失败。
finally 中抛异常会吞掉 try/catch 的返回或异常
finally 块里如果抛出异常（哪怕只是 throw new RuntimeException()），它会立即中断当前流程，并把该异常向上抛出——无论 try 是否已返回值，也无论 catch 是否已处理完原异常。
这意味着：
-
try中的return 42→ 被丢弃 -
catch中的return "fallback"→ 被丢弃 -
finally中的throw new NullPointerException()→ 成为最终抛出的异常
这种行为极易导致调试困难：你以为是业务逻辑出错，实际是资源清理代码出了问题。
正确做法：finally 只做清理，别碰 return 和 throw
finally 的唯一职责是释放资源、恢复状态。所有业务逻辑、返回决策、异常传播，都该留在 try 和 catch 中。
推荐写法：
- 用
try-with-resources替代手写finally关流（Java 7+） - 若必须手动关资源，在
finally中只调用close()等无副作用方法 - 如需在
finally中处理可能异常（如close()抛IOException），应捕获并记录，绝不能throw或return
最容易被忽略的细节是：finally 的“确定性”是假象——它看似最后执行，却拥有最高优先级的控制权。一旦掺入 return 或 throw，整个异常流语义就坍塌了。
