Java中return执行顺序的关键是返回值来源：try有return而finally无return时，返回值在try中暂存，finally仅能影响引用类型内容；若finally也有return，则直接覆盖try的返回值。
掌握 try-finally 中 return 的执行顺序，关键不是死记“先谁后谁”，而是理解 Java 虚拟机对 return 的实际处理机制：它会暂存返回值，再执行 finally，最后才真正返回——但这个“最后”会被 finally 里的 return 打断。
try 有 return、finally 没 return：值定在 try，finally 只能“擦边影响”
这是最常见也最容易误解的情况。程序不是“先 return 再 finally”，而是：
- 遇到 try 中的 return，立刻计算表达式（比如 i++ 或 list.add(1)），把结果暂存起来；
- 然后跳转执行 finally 块中的全部代码；
- finally 执行完，方法才把刚才暂存的值返回出去。
所以：
- 若返回基本类型（如 int、boolean），finally 里修改变量不影响最终返回值；
- 若返回引用类型（如 List、Map、自定义对象），finally 里通过引用修改了对象内容，这些修改会体现在返回结果中。
例如：
- 返回
int i = 2，finally 中做i++→ 方法仍返回 2； - 返回
new ArrayList<>()并已 add(1)，finally 中 add(3) → 方法返回的是 [1, 3]。
try 和 finally 都有 return：finally 的 return 直接“截胡”
一旦 finally 块里出现 return，它就拥有了最终决定权：
- try 中的 return 依然会先执行并暂存值；
- 但紧接着执行 finally，遇到它的 return 后，JVM 就丢弃之前暂存的值，直接用 finally 的返回值退出方法；
- try 中暂存的返回值被彻底忽略，不会回传。
注意：
- 编译器通常会警告“finally block does not complete normally”；
- 这种写法会掩盖 try/catch 中可能抛出的异常，也不利于逻辑追踪，应避免。
别只盯着“执行顺序”，要盯住“返回值从哪来”
很多困惑源于混淆了两个概念：语句执行顺序 vs. 返回值来源。
- 执行顺序上，finally 总在 try 的 return 表达式计算之后、方法真正退出之前运行；
- 但返回值来源只取决于：
✓ 没有 finally return → 来自 try（或 catch）中暂存的值；
✓ 有 finally return → 来自 finally 中的 return 表达式。
调试时，可在 try 的 return 行和 finally 的第一行都加断点，观察变量值和调用栈变化，比背结论更直观。
实际编码建议
为保障可读性和健壮性：
- finally 中只做资源清理（close、unlock、reset 等），不要写 return、throw 或 break；
- 若必须在异常路径外提前退出，把逻辑提到 try 外或封装成独立方法；
- 返回引用类型时，若不希望 finally 修改影响结果，可在 try 中返回不可变副本（如 Collections.unmodifiableList(list)）。
