finally中return会终止异常传播，使catch抛出的异常彻底丢失；应仅用于资源清理，避免return、throw或System.exit()。
Java中finally块里写return，会直接中断异常传播链，让catch里抛出的异常彻底消失——调用方收不到任何异常，日志里也看不到堆栈，程序“看似正常”却跳过了错误处理逻辑。
异常在进入finally前就被丢弃
当catch块执行throw e;时，异常对象已经构造完成、准备向上抛出。但JVM强制要求先执行finally块。一旦finally中出现return，JVM就放弃原异常，不再继续抛出，而是立即以return结束方法。
这和“catch没执行”完全不同：catch里的代码（包括throw）确实运行了，只是它的结果被finally的return覆盖了。
典型表现：什么都没报错，但逻辑断了
- 日志里本该打印的
log.error("处理失败", e)根本没触发 - 调试时在catch的
throw e行设断点能停住，但在finally的return处也会停——接着方法就返回了，异常没传出去 - 上层调用方收到一个“意外”的返回值（比如"done"或0），而不是预期的异常
- 用IDE的“Exception Breakpoint”捕获未处理异常，结果这个断点一次都不触发
一个极简复现例子
这段代码运行后不会报错，也不会输出"caught!"，只安静地返回字符串：
立即学习“Java免费学习笔记（深入）”；
static String test() {
try {
throw new RuntimeException("original");
} catch (Exception e) {
System.out.println("caught!");
throw e;
} finally {
return "from finally"; // ← 这行让整个异常消失
}
}
去掉return "from finally"，异常立刻正常抛出，“caught!”也会被打印。
真正安全的做法
- finally只做资源清理：close()、unlock()、reset()等，不写return、不throw、不调用System.exit()
- 把返回值存在局部变量里，比如
String result = null;，在try或catch中赋值，最后在方法末尾统一return - 如果清理过程可能出错（如close()抛IOException），让它自然抛出——不要用return去“兜底”，否则会掩盖更关键的原始业务异常
