finally 中的 return 会覆盖 try 或 catch 的返回值，这是 JVM 字节码层面的明确行为，而非 bug；其原理是先暂存 try/catch 的返回值，再执行 finally，若 finally 有 return 则丢弃原值并直接返回新值。
finally 里的 return 确实会覆盖 try 或 catch 中的 return
只要 finally 块里有 return，不管 try 或 catch 里先 return 了什么，最终方法返回的都是 finally 里的值。这不是“覆盖”语义上的 bug，而是 JVM 字节码层面的明确行为：finally 中的 return 会直接跳过之前已准备好的返回值。
常见错误现象：
— 写了个 try { return x; } finally { return y; }，结果总拿到 y，以为是逻辑没走进 try；
— 在 finally 里做资源清理时顺手加了 return，导致业务结果被静默替换。
- 只在
finally中写清理逻辑（如close()、unlock()），绝对不要放return - 如果真需要根据清理结果改变返回值，说明设计有问题——把清理和业务逻辑拆开，别塞进同一个方法
-
finally中抛出异常也会中断原有返回流程，效果等同于return
try 和 finally 都有 return 时，执行顺序不是“先 try 后 finally”那么简单
JVM 实际执行时，并不会等 try 的 return 真的把值交出去，而是先记录下这个待返回值，然后强制跳入 finally 块；一旦 finally 自己也 return，就丢弃之前记下的值，用新的值退出方法。
使用场景：
— 调试时看到 try 里的变量明明赋了值，但断点进 finally 后发现返回值变了；
— 反编译字节码能看到 astore_1（存返回值）后紧跟 jsr（跳去 finally）。
立即学习“Java免费学习笔记（深入）”；
- 示例：
static int f() { try { return 1; } finally { return 2; } }调用结果永远是2 - 哪怕
try中 return 的是对象引用，finally中修改该对象字段也不会影响返回值（因为引用本身没变），但若finally中return新对象，就彻底替换了
finally 中没有 return，但修改了 try 中 return 的对象字段，会影响返回值吗
会，但仅限于引用类型。因为 try 中 return obj; 返回的是引用的副本，JVM 并不阻止你在 finally 中通过这个引用去改对象内部状态。
性能 / 兼容性影响：
— 这种写法在所有 Java 版本中行为一致，但可读性极差，维护者很难意识到 finally 还在动返回值的内容；
— 对基本类型或不可变对象（如 String、Integer）完全无效。
- 示例：
static List<Integer> f() { List<Integer> list = new ArrayList<>(); try { list.add(1); return list; } finally { list.add(2); } }返回的list包含[1, 2] - 别依赖这个行为。想让返回值带额外数据，就在
try里做完再return，别留尾巴给finally - 如果用了 Lombok 的
@Cleanup或 try-with-resources，它们底层不走finally块的return，所以不存在这个问题
Java 7+ 的 try-with-resources 不会触发 finally 覆盖问题
因为 try-with-resources 的资源关闭逻辑是在隐式生成的 finally 块里调用 close()，而不是在其中写 return。只要你的 close() 方法不抛异常、也不自己 return，就不会干扰主逻辑的返回值。
容易踩的坑：
— 自定义 AutoCloseable 实现时，在 close() 里写了 return（虽然语法允许，但毫无意义）；
— close() 抛异常且未被处理，会压制 try 块原有的异常或返回值。
- 示例：
try (Resource r = new Resource()) { return "ok"; } // close() 被调用，但不影响返回 "ok" - 如果
close()抛IOException，而 try 块里没异常，则它会被包装成java.lang.SuppressedException附在主异常上；但如果 try 块本来就要 return，这个异常会被吞掉（除非你显式捕获）
finally 中的异常抛出，都可能让一个看似正常的 return 消失不见。 
