finally中变量覆写对调用者的影响分三类：①改局部变量（含包装类）无影响，返回值已锁定；②改可变对象状态会影响调用者，因返回的是同一实例；③finally中return或throw会覆盖原返回值或异常，导致逻辑错乱与异常丢失。
finally块里的变量覆写，对方法调用者是否产生实质影响，取决于“覆写”的具体形式：是修改局部变量、修改可变对象状态，还是直接在finally中return。这三类行为在JVM层面效果截然不同，调用者感知也完全不同。
修改基本类型或包装类局部变量 → 调用者完全无感
在try中执行return x;后，JVM已将x当时的值（如int x = 5）快照并压栈；finally中写x = 10;只是改了栈帧里另一个副本，不影响已确定的返回值。调用方拿到的仍是5。
- 这是语言机制决定的，不是bug，也不是“失效”，而是返回值早已锁定
- Integer、Boolean等包装类同理：赋新值（
result = new Integer(99)）不改变已返回的引用 - IDE通常不会警告，但容易让人误以为“改了就生效”，需特别注意
修改可变对象内部状态 → 调用者看到的是“被改过的结果”
若try中return list;，而finally中list.clear();或list.add("done");，调用方收到的是同一个List实例——但内容已被清空或追加。这不是返回值被覆盖，而是对象状态被副作用修改。
- 常见于List、Map、StringBuilder、自定义POJO等可变类型
- 调用方可能因数据异常（如空集合）而报错，但堆栈里找不到源头
- 规避方式：返回前克隆，例如
return new ArrayList(list);
finally中直接return → 调用者收到的永远是finally的值，且原有异常消失
这是最危险的情况。无论try返回什么、catch处理了什么异常，只要finally有return，整个方法就立刻以该值结束，原返回值和异常全部丢弃。
- 调用方拿到的值与业务逻辑完全脱节（比如本该返回用户ID，却固定返回-1）
- 异常被静默吞掉：日志没记录、监控无告警、接口返回200但数据错乱
- 字节码层面插入的是独立
ireturn/areturn指令，彻底接管控制流
finally中抛出异常 → 调用者只看到这个新异常，原逻辑中断
如果try中已准备返回一个值，或catch刚处理完异常，finally里却执行throw new RuntimeException("cleanup failed");，那么调用方捕获到的只有这个新异常，之前所有状态和返回意图都被覆盖。
- 资源清理失败本应记录warn，而不是中断业务流程
- 正确做法：捕获close()等可能抛异常的操作，仅log.warn，不throw也不return
- 使用try-with-resources可天然避免此类问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
