finally块在return前执行，但不会改变方法的实际返回值——这不是靠“魔法”，而是编译器在字节码层面做的明确安排：返回值被提前备份到独立的局部变量中，finally操作的是原始变量，而非那个备份值。
返回值被提前“快照”存储
当try或catch中遇到return语句时，JVM并非立即跳出去，而是先计算return表达式的值（比如return x + 1），然后把结果存入一个**专用的临时局部变量**（如istore_3），这个动作发生在finally执行之前。后续所有逻辑——包括finally里的赋值、自增、甚至重新赋值给x——都只影响原始变量x，对已存好的返回值副本毫无作用。
- 例如
int x = 5; return x = 2;：2被存进临时变量，x随后在finally里变成4，但返回的仍是2 - 字节码中能看到
dup（复制栈顶）、istore_3（存入临时槽位）、iload_3（最后加载它）这一完整链条 - 这个临时变量与方法参数、其他局部变量并列存在，由编译器自动分配，不暴露给Java源码
finally代码实际被“复制”进多条出口路径
所谓“finally一定执行”，底层不是靠运行时跳转调度，而是javac在编译时就把finally块的字节码**原样插入到每个可能的退出点之后**：正常结束、catch处理完、未捕获异常抛出前、甚至return指令触发后——每条路径末尾都有一份finally逻辑。
- 没有jsr/ret这种老式子程序调用（Java 6+已弃用），现代OpenJDK采用纯代码冗余策略
- 异常表（Exception Table）配合多份finally副本，确保无论控制流从哪走，都会路过清理逻辑
- 这也解释了为什么finally里写return会直接覆盖外层return：它所在路径的最后一条指令就是
ireturn，自然胜出
引用类型变量的“表面例外”
如果return的是对象引用（如StringBuilder sb），finally中调用sb.append("x")确实会改变最终返回对象的状态。但这不违背“返回值不变”原则——因为返回的仍是那个引用地址，而对象内容可变是引用类型的固有特性。
- 返回值备份的是引用值（内存地址），不是对象深拷贝
- 若在finally中让引用指向新对象（
sb = new StringBuilder()），则不影响返回值；但修改对象内部状态（sb.append()），外部拿到的就是被改过的对象 - 本质仍是“副本存的是地址”，和基本类型存的是数值，遵循同一套备份机制
finally里写return会彻底接管返回行为
一旦finally块内包含return语句，它就成为该方法**唯一生效的返回点**。此时try或catch里的return完全失效——不是被“覆盖”，而是根本没机会执行到其对应的ireturn指令，因为控制流在进入finally后就直接从那里跳出了。
- 编译器会为finally中的return生成独立的字节码出口，且优先级最高
- 这种写法虽合法，但极不推荐：破坏调用者对返回逻辑的预期，易引发隐蔽bug
- 若需统一返回逻辑，应提取方法或使用标志位，避免在finally中引入业务返回分支
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
