finally中的return会强制覆盖try/catch的返回值并立即终止方法；若无return，则暂存try/catch的返回值，待finally执行完再返回；finally中抛异常会丢弃原有返回或异常。

在 finally 块中使用 return 会**完全接管方法的返回行为**，无论 try 或 catch 中是否已有返回值、是否抛出异常，最终结果都以 finally 的 return 为准——它不是“补充”或“修正”，而是**强制覆盖并立即终止方法执行**。

覆盖机制：JVM 层面的确定性行为

Java 规范明确要求：finally 块必须执行；若其中包含 return，JVM 会在 try/catch 的返回值压栈后、真正退出方法前，用 finally 的返回值替换操作数栈顶部的值，并直接跳转到方法出口。

• try 中 return 10; → JVM 暂存 10，准备返回
• 进入 finally → 执行 return 20; → 丢弃 10，改用 20 返回
• 方法立刻结束，不再执行后续任何语句（包括 try/catch 后的代码）

异常会被静默吞掉

如果 try 抛出异常、catch 捕获并处理（甚至已准备返回），只要 finally 中有 return，异常就**不会向上抛出，也不会出现在调用栈中**。

• try 中 int a = 1 / 0; → 抛出 ArithmeticException
• catch 捕获并 return 20; → 异常被处理，准备返回
• finally 中 return 30; → 异常信息丢失，调用方只收到 30，且无任何报错提示

基本类型和引用类型都适用，但效果不同

覆盖对所有返回类型生效，但表现有差异：

• 基本类型（int、boolean 等）：原值被彻底替换，例如从 10 变成 20
• 引用类型（如 List、自定义对象）：返回的是同一个对象引用，但若 finally 中修改了该对象内部状态（如 list.add("x")），调用方看到的是修改后的对象；而若 finally 直接 return new ArrayList();，则返回全新对象，原对象被丢弃

为什么编译通过却强烈不推荐

语法上允许，是因为 Java 设计时保留了控制流灵活性；但实际开发中，它破坏了方法契约的可预测性：

• 返回逻辑分散在 try/catch/finally 多处，阅读和调试困难
• 单元测试容易漏掉 finally 路径，导致线上返回值与预期不符
• 静态检查工具（如 Checkstyle、SonarQube）默认标记为高危问题
• 团队协作中极易引发“我以为返回的是 A，其实是 B”的认知偏差