finally中的return会覆盖try/catch的返回值并抑制异常，导致方法实际返回finally的值；正确做法是用局部变量存储返回值，finally仅用于资源清理。
finally里写return会直接覆盖try/catch的返回值
Java中，finally块里的return语句具有最高优先级——它会强行中断当前执行流，把finally里的返回值当作整个方法的最终结果。哪怕try里已经计算好并准备返回一个值，只要finally里有return，那个值就彻底丢弃。
常见错误现象：getCount()方法本该返回10，但finally里写了return -1;，调用方永远拿到-1，且不报错、无警告。
-
finally中的return会抑制try或catch中已抛出的异常（异常直接被吞掉） - 如果
try里有return new Object();，而finally里修改了该对象的字段，那返回值仍有效；但一旦finally自己return，就完全接管返回逻辑 - 这种覆盖对基本类型和引用类型都生效，不是“只影响包装类”之类的误解
finally里该做的事：资源清理，不是控制返回逻辑
finally唯一可靠用途是确保资源释放，比如关闭InputStream、提交/回滚Connection、释放锁。它不该参与业务逻辑判断，更不该决定返回什么。
使用场景举例：数据库查询后必须关闭ResultSet，无论是否查到数据、是否抛异常，这个动作必须发生——但关闭操作本身不能return。
立即学习“Java免费学习笔记（深入）”；
- 所有资源清理代码放在
finally里，但不要加return、不要加throw - 若清理过程可能抛异常（如
close()失败），应捕获并记录（log.warn），而非向上抛或return - JDK 7+ 推荐用
try-with-resources替代手动finally关闭，天然规避这类风险
return覆盖的真实案例：包装类与原始类型的混淆
下面这段代码看似无害，实则危险：
public static Integer getValue() {
try {
return 5;
} finally {
return 8; // 这行让上面的5彻底失效
}
}
更隐蔽的是自动拆箱场景：
public static int getValue() {
try {
return 5;
} finally {
return 0; // 编译通过，但5永远不返回
}
}
参数差异不在此处体现，但行为差异极大：原始类型和包装类型在finally覆盖下表现一致，都以finally为准；区别只在于NPE风险（如Integer为null时拆箱抛异常），但这和覆盖逻辑无关。
- IDE（如IntelliJ）通常会对
finally中的return标黄警告，别忽略它 - 静态检查工具（如SonarQube）规则
S1142专门检测此问题 - 单元测试很难覆盖到——因为逻辑被覆盖后，表面行为“稳定”，但实际破坏了调用方预期
替代方案：用局部变量承载返回值
真需要在finally前后做状态判断？把返回值存到局部变量里，统一在方法末尾return。
性能影响几乎为零，兼容性无任何问题，且逻辑清晰可测。
- 声明
int result = 0;或String result = null;在try外 -
try里赋值result = compute();，catch里可设默认值，finally里只清理不碰result - 方法结尾单点
return result;，所有路径收束于此，一目了然 - 注意：局部变量需是方法作用域内可访问的，不能是
final（否则无法在try里赋值）
finally里写return当成“兜底逻辑”，其实是在给调用方埋静默陷阱——它不报错，却让上层所有判断失效。最麻烦的是，这种bug往往在线上压测或特定分支才暴露，调试时还容易误判成业务逻辑问题。 
