finally块中的return会覆盖try或catch中的返回值，这是jvm明确规定的执行逻辑，旨在确保清理逻辑一定执行；因此应避免在finally中使用return或throw，推荐仅做资源清理。
在Java中，finally块中执行return会覆盖try或catch中的return值，这是异常处理机制中一个容易被误解但非常关键的行为。理解这一点，对写出可预测、可维护的代码至关重要。
finally中的return会“劫持”返回值
当try或catch块中有return语句，而finally块中也有return，JVM会忽略try/catch中已准备好的返回值，直接以finally中的return为准。这不是语法错误，而是明确规定的执行逻辑。
- try里return 1；finally里return 2 → 方法最终返回2
- catch里抛出异常；finally里return 0 → 异常被吞掉，方法返回0
- try里return new Object()；finally里修改该对象字段 → 对象引用未变，但状态可能已变（注意：不是覆盖返回值，而是修改了原对象）
为什么设计成这样？
finally的核心职责是**确保清理逻辑一定执行**，包括释放资源、关闭连接、重置状态等。如果允许try/catch的return“优先”，就可能出现清理未完成就退出的情况。JVM强制将finally视为“最后裁决者”，保证其逻辑不被绕过。
- 它不关心业务逻辑是否想返回什么，只保证清理动作完成
- return语句在finally中本质上是“提前结束方法执行”的指令，和位置无关
- 这种设计牺牲了部分灵活性，换来了确定性——finally一定跑完，且它的return一定生效
哪些情况要特别小心？
实际开发中，以下场景容易踩坑：
- 在finally里关闭流的同时return false：可能掩盖原本的业务返回值或异常
- 日志记录后return null：调用方收到null却不知原始结果是什么
- 在finally中抛出新异常：会吞掉try/catch中已捕获或待抛出的异常（比return更隐蔽）
更安全的写法建议
除非有明确理由，否则避免在finally中使用return或throw。推荐方式：
- finally只做清理：close()、unlock()、reset()等，不改变控制流
- 需要统一返回逻辑时，把return提到方法末尾，在try/catch/finally之后
- 若必须在finally中干预返回值，先保存try/catch的结果到局部变量，再在finally中决定是否覆盖
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
