finally块中使用return会覆盖try/catch的返回值并吞掉异常，应仅用于资源清理；推荐用局部变量统一返回、try-with-resources自动管理资源。
在 finally 块中使用 return 语句会覆盖 try 或 catch 中的返回值，导致逻辑异常且难以排查。
会静默吞掉异常和原有返回值
finally 中的 return 具有最高优先级：无论 try 是否正常执行、catch 是否捕获异常，只要 finally 执行了 return，整个方法就立刻结束，并以 finally 的返回值为准。
- 如果
try中抛出异常，catch捕获并处理后准备返回，但finally又return，异常信息就丢失了 - 如果
try中已计算好返回值（比如return result;），finally的return会让这个值完全失效 - 调试时容易误以为逻辑走到了
try/catch，实际却停在finally的返回上
资源清理应与控制流分离
finally 的核心职责是确保资源释放（如关闭文件、连接、解锁），不是参与业务返回逻辑。
- 把释放操作写在
finally里，但不要在里面做return、throw或修改返回变量 - 若需根据清理结果改变行为（如重试、标记失败），应在
try/catch中统一处理，再由主流程决定返回 - 例如：数据库连接关闭失败，不应在
finally中return false，而应记录日志，让上层根据业务规则判断是否重试或降级
替代写法更清晰可控
用明确的变量承载返回结果，所有 return 集中在方法末尾，finally 只做清理。
- 声明一个局部变量（如 result），在
try中赋值，在catch中修正，在方法最后return result - 若必须提前退出，用
if-else控制分支，避免分散的return - JDK 7+ 推荐使用 try-with-resources，自动管理可关闭资源，彻底省去手工
finally关闭逻辑
不复杂但容易忽略，养成习惯：finally 只干活，不决策，不返回。
