finally 中的 return 会丢弃暂存异常并覆盖返回值，导致异常静默吞没、堆栈不生成、调用方收到错误成功信号；java 和 python 均存在该行为，且 python 缺乏编译警告。
因为 finally 中的 return 会强制终止方法执行，丢弃所有暂存的异常对象和返回值，让调用方既收不到错误信号，也看不到堆栈信息。
异常在 finally 前只是“待处理”，不是真抛出了
当 try 块中执行 throw new Exception()，JVM 并不会立刻把异常传给上层。它会先记下这个异常，然后按顺序执行 catch（如果匹配）和 finally。此时异常还卡在当前方法里，处于“暂存”状态，还没真正离开。
一旦 finally 执行了 return，JVM 就直接清空这个暂存异常，跳过所有后续传播步骤——就像按下“取消发送”，邮件根本没发出去。
finally 的 return 具有最高控制权
- 无论 try 是正常 return、还是 throw 异常，也无论 catch 是否捕获并再次 throw，只要 finally 有 return，它就接管整个方法出口
- 字节码层面由
ireturn/areturn指令完成，不可跳过，也不受 try/catch 内容影响 - 结果就是：原异常对象被丢弃，堆栈不生成，调用方拿到的是 finally 的返回值，而不是错误
静默吞没的实际表现
- 日志里本该出现的
log.error(e)根本没执行——因为程序在进入 catch 后还没走到那行，就跳进 finally 返回了 - HTTP 接口返回 200，但业务其实失败了（比如数据库操作出错，finally 却 return true）
- 调试时断点停在 try 的 throw 行，再按 F8 却直接跳到 finally 的 return，异常像消失了一样
不只是 Java，Python 同样如此
Python 表面灵活，行为一致：try: raise ValueError() finally: return "ok"，函数就真的只返回 "ok"，ValueError 完全不出现，连 except 都没机会触发。区别只在于 Python 没有编译期警告，更依赖人工审查和异常路径测试来暴露问题。
