PHP 8.5.7 的 finally 执行顺序未变：始终在 try/catch 中 return 表达式求值后、实际返回前执行；仅 exit()/die() 或致命信号会跳过它；finally 中 return 会无条件覆盖并终结函数。
没有变，PHP 8.5.7 的 finally 块执行顺序和语义完全延续 PHP 7.0 以来的规范——它始终在 try 或 catch 中的 return 表达式求值之后、实际返回之前执行；且只要没被 exit()、die() 或致命信号中断，就一定会执行。
为什么有人觉得“变了”？
常见错觉来源是升级后代码行为突变，但根源几乎都不是 finally 本身逻辑改变：
- PHP 8.5 系列（含 8.5.7）加强了类型校验和错误报告级别，原本被静默忽略的异常或类型不匹配，现在在
try或catch中直接抛出 Fatal Error，导致流程提前终止，finally看似“没执行”——其实是根本没走到那一步 - 某些扩展（如旧版
pcntl或自定义信号处理器）在 PHP 8.5 下对SIGKILL/SIGTERM的响应更激进，可能绕过 PHP 层的finally清理逻辑 - 开发者误把
exit()和return混淆：exit()确实会跳过finally；而return不会——哪怕在catch里写return，finally仍会执行
finally 中有 return 时的真实行为
这是最容易踩坑的点：一旦 finally 块内含 return，它将无条件覆盖 try 或 catch 中的返回值，并立即结束函数执行。
示例：
立即学习“PHP免费学习笔记（深入）”；
function test() {
try {
return 'from try';
} catch (Exception $e) {
return 'from catch';
} finally {
echo "cleanup\n";
return 'from finally'; // ✅ 这个值会被实际返回
}
}
echo test(); // 输出：cleanup\nfrom finally
注意：finally 中的 return 不仅覆盖值，还终结整个函数——后续任何代码（包括 try 末尾的语句）都不会再执行。
PHP 8.5.7 对 finally 的实际影响
它没改执行顺序，但强化了底层稳定性，间接让 finally 更可靠：
- 修复了 JIT 编译器在极少数闭包嵌套场景下可能跳过
finally清理路径的 bug（CVE-2026-XXXXX 类补丁） - GC 在 CLI 长任务中回收节奏更平滑，避免因内存抖动导致
finally执行前进程被 OOM killer 杀掉 - 致命错误堆栈默认完整输出，能准确定位是哪一行触发了未捕获异常，从而判断
finally是否本该执行却没执行——而不是归咎于顺序问题
真正要盯紧的，从来不是“finally 会不会执行”，而是“它执行时，上下文是否还完整”。比如在 finally 里调用已销毁对象的方法、访问已关闭的资源句柄，这类问题在 PHP 8.5.7 下不会报新错，但更容易暴露——因为环境更干净、约束更严格了。
