finally中写return会强制使方法返回其值并吞掉异常。例如try返回1、finally返回2则实际返回2；try抛异常、finally返回42则异常消失，仅返回42。这是JVM控制流机制决定的，非覆盖行为，但严重破坏可读性与异常传播，不推荐使用。
在Java中，finally块里写return会导致try或catch中的return被忽略，方法会直接返回finally中的值。这不是“覆盖”，而是控制流的强制转移——JVM会确保finally执行完毕，并以其中的return为最终出口。
finally里的return会屏蔽try/catch的return
只要finally中有return语句，无论try或catch是否已执行了return，JVM都会丢弃之前准备好的返回值，转而执行finally中的return，并将其作为方法的最终返回结果。
- try中return 1；finally中return 2 → 实际返回2
- catch中return -1；finally中return 0 → 实际返回0
- 即使try/catch抛出异常，只要finally有return，异常也会被“吞掉”，方法正常返回
异常会被finally中的return压制
如果try或catch抛出了未捕获的异常，但finally中执行了return，该异常将不会向上传播，调用方收不到异常，只会得到finally的返回值。这极易掩盖问题。
- try中throw new RuntimeException("oops")
- finally中return 42
- 结果：方法返回42，异常消失，调用方完全不知发生了错误
不推荐在finally中写return
这是Java编程规范明确反对的做法。它破坏了方法的可读性、可预测性和异常传播逻辑，容易引发隐蔽bug。
立即学习“Java免费学习笔记（深入）”；
- 清理资源（如close流、释放锁）应放在finally中，但不要加return
- 需要统一返回值，应在try/catch外定义变量，在finally中只做清理，最后return该变量
- 若真需在finally中干预返回逻辑，应使用try-with-resources或显式状态标记，而非return
字节码层面的真相
编译后，javac会把try/catch/finally合并为一个结构化异常表，并为每个可能出口插入“finally代码副本”。当遇到return时，JVM先暂存返回值，再跳入finally执行；若finally内有return，则直接用其操作数栈顶值作为最终返回，原暂存值被丢弃。
- 也就是说，finally中的return不是“后来者居上”，而是JVM控制流机制的必然行为
- 这也是为什么即便在finally中修改了局部变量，也不影响已暂存的返回值（除非你又写了return）
