finally 中的 return 会覆盖 try/catch 的返回值并吞掉异常；正确做法是用局部变量记录结果，清理逻辑放在 finally 中，最终在方法末尾统一 return。
finally 里写 return 会覆盖 try/catch 中的 return
这是最直接、最常被忽视的问题：只要 finally 块中存在 return，它就会强行终止当前方法执行，并把它的返回值作为整个方法的最终结果——不管 try 或 catch 里已经计算好、甚至已经压入栈的返回值。
典型表现是：你明明在 try 里 return "success"，但方法实际返回了 finally 里的 "cleanup"，连异常都被吞掉。
-
try抛出异常 →catch捕获并return "handled"→ 进入finally→return "done"→ 调用方只收到"done"，且原异常彻底丢失 - 即使
try中已执行return，JVM 仍会等finally执行完再真正退出方法；而finally的return会直接跳过之前所有返回逻辑 - 这种覆盖对基本类型、引用类型都生效；对
void方法虽无返回值冲突，但提前退出仍可能破坏清理逻辑预期（比如部分资源未释放）
finally 中 return 导致异常被静默吞掉
当 try 或 catch 抛出异常，而 finally 中有 return，该异常将永远不会向上传播。JVM 选择“以 finally 的 return 为准”，而不是“先抛异常再执行 finally”。
这会让调试变得极其困难：日志没报错、调用方没收到异常、程序行为诡异，却找不到源头。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 错误写法：
public String risky() { try { throw new RuntimeException("boom"); } catch (Exception e) { System.err.println("caught: " + e.getMessage()); return "recovered"; } finally { return "ignored"; // ← 这行让 RuntimeException 彻底消失 } } - 正确做法：
finally只做清理，不写return；异常处理交给try/catch显式控制 - 如果真需在
finally后返回统一状态，应改用局部变量记录，最后在方法末尾return
替代方案：用局部变量 + 方法末尾 return
想实现“无论是否异常都返回某个默认值”或“统一收口返回”，应该避免在 finally 中 return，而是用一个变量承载结果，在方法结尾统一返回。
- 声明一个
String result = null在方法开头 -
try块中赋值result = "ok"，并正常执行逻辑 -
catch中赋值result = "error"，可选打印日志或重抛 -
finally中只做close()、unlock()等清理，不碰result - 方法最后一行写
return result
这样既保留了异常传播能力，又保证了清理必然执行，还让返回逻辑清晰可读。
为什么 Java 设计成这样？不是 bug 是规范
Java 语言规范（JLS §14.20.2）明确要求：如果 finally 包含 return、throw 或跳出语句，则它会“抑制”任何由 try 或 catch 引发的异常或返回。这不是 JVM 实现缺陷，而是设计使然。
这意味着：一旦你写了 finally { return; }，你就主动放弃了对控制流的分层管理能力。它适合极少数场景（如强制终止监控线程），但绝不该用于常规业务方法的“兜底返回”。
最容易被忽略的是：哪怕 finally 里的 return 看似无害（比如 return null），它依然会切断异常链、掩盖问题根源。写之前，先问自己一句：这个 return 是真的必须在这里发生，还是只是图省事？
