finally中return会覆盖try/catch的返回值并吞掉异常，是jvm明确规定的行为；应仅用finally做资源清理，避免return或throw，推荐使用try-with-resources替代。
在 finally 块中写 return 会直接终止方法执行，丢弃 try 或 catch 中已准备好的返回值或异常——这不是 bug，而是 JVM 明确规定的语义。要避免静默吞掉异常或覆盖返回值，关键不是“怎么绕过”，而是严格遵守 finally 的设计本意：只做清理，不干预控制流。
只让 finally 做资源清理，不参与返回决策
finally 的唯一职责是确保资源释放、状态重置等善后操作一定执行。它不该决定方法返回什么，也不该改变异常传播路径。
- 把需要返回的值提前存入局部变量，在 try 或 catch 末尾统一
return - finally 中只调用
close()、unlock()等操作，并用独立的try-catch捕获其可能抛出的异常 - 若清理失败，记录警告日志或调用监控上报，但绝不
throw新异常，也绝不return
优先使用 try-with-resources 替代手写 finally
对实现了 AutoCloseable 的资源（如 InputStream、Connection），应直接用 try-with-resources 语法。
- 资源自动关闭，无需手动写
finally，从根本上杜绝 return 和异常覆盖问题 - 如果
close()抛异常，它会被自动添加为suppressed exception，主异常仍可被正常捕获和分析 - 代码更简洁，且编译器强制检查资源是否正确关闭
清理失败时，别用 return “兜底”或“降级”
有人在 finally 里加 return 是想“保证有返回值”，这是对方法契约的误解。返回值语义由业务逻辑定义，不是靠 finally 强行补救。
- 需要降级返回（如查缓存失败则返回默认值），应放在
catch块中处理 - 若清理失败需影响业务结果（极少数场景），应通过外部状态（如设置标志位、发告警）反映，而非篡改当前方法的返回值
- 对返回的对象引用，若担心 finally 中修改其状态影响调用方，可在 try 中做防御性拷贝
借助工具提前拦截这类错误
这类问题在运行时难以察觉，但静态检查能有效预防。
- IntelliJ IDEA 默认启用规则 “Finally block should not contain return statement”，会标红并提示严重问题
- SonarQube 规则
S1142同样检测 finally 中的 return/throw，并归类为阻断级缺陷 - CI 流程中集成 Checkstyle 或 ErrorProne，可将该问题纳入门禁检查
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
