finally 中的 return 会覆盖 try/catch 的返回值，包括正常值、异常和对象引用；IDE 警告但编译通过；应将 return 移至 finally 外，用 try-with-resources 或手动关闭资源确保不干扰返回。
finally 里写 return 会直接覆盖 try/catch 的返回值
Java 的 finally 块不是“收尾执行”，而是“强制执行后返回”。只要它自己有 return，不管 try 或 catch 里已经算出什么结果，都会被丢弃——连对象引用、基本类型值、甚至异常吞没都算数。
-
try返回new String("a")，finally返回"b"→ 实际返回"b"，且"a"可能因无引用被 GC -
catch抛出IOException，finally里return 42→ 异常彻底消失，调用方只拿到42 - 哪怕
finally是空的（仅含日志），只要加了return，就等价于“强行改写返回路径”
为什么编译器不报错，但 IDE 会警告
Java 语法上允许 finally 含 return，所以编译通过；但它的行为违背直觉，容易掩盖逻辑错误，因此主流 IDE（IntelliJ、Eclipse）默认开启 FinallyBlockCannotCompleteNormally 类警告。
- 不是所有团队开 IDE 检查，线上问题往往在返回值校验失败或异常丢失时才暴露
- JDK 8+ 的
javac不提示，但javac -Xlint:all会输出warning: [finally] finally clause cannot complete normally - Spring Boot 等框架中，若在 AOP 切面或过滤器的
finally加return，可能让 Controller 返回值失效
想清理资源又不想破坏返回值？用标准姿势
资源释放和值返回是两件事，必须拆开。JDK 7+ 的 try-with-resources 是首选，它在字节码层面保证资源关闭不干扰返回值；手动关资源则必须把 return 移到 finally 外。
- ✅ 正确：
InputStream is = new FileInputStream("x"); try { return is.read(); // return 在 try 内，finally 只关流 } finally { if (is != null) is.close(); // 无 return } - ❌ 错误：
try { return 1; } finally { return 2; }→ 永远返回 2 - ⚠️ 例外：只有当方法声明为
void且你明确要中断流程（比如强制退出线程），才可能用finally { return; }，但这种场景极少，且应加注释说明
面试/Code Review 中高频踩坑点
这个陷阱常出现在对“确保执行”的误解上——以为 finally 是安全的兜底区，其实它是高优先级出口。一旦涉及返回值、异常传播、对象生命周期，它的权重就压过 try/catch。
立即学习“Java免费学习笔记（深入）”；
- 多层嵌套 try-finally 时，最内层
finally的return会直接跳出整个结构 - 使用 Lombok 的
@Cleanup或自定义AutoCloseable包装类时，若其close()方法内部有return，同样会污染外层方法返回值 - 单元测试容易漏掉：只测正常路径返回值，没覆盖异常路径下
finally是否静默吞掉异常
真正难的不是记住“别写 return”，而是每次写 finally 时下意识问一句：这里有没有可能正在悄悄改掉上面辛辛苦苦算出来的结果？
