finally 在 try 或 catch 发生控制流转移（如 return、break、continue 或异常抛出）后仍会执行，但 exit()、die() 或 kill -9 会阻止其运行；它在 return 表达式求值后、实际返回前执行，可修改返回值；嵌套时内层 finally 先于外层执行；资源清理应放 finally 而非 try/catch 结尾，避免遗漏；finally 中 throw 或 return 会掩盖原异常，应绝对避免；php 5.5+ 支持，需确保版本兼容。
finally 什么时候才真正执行
只要 try 或 catch 块里发生了控制流转移（比如 return、break、continue，甚至 exit() 之外的异常抛出），finally 依然会运行——这是它和普通清理代码最根本的区别。
但要注意：如果在 try 或 catch 中调用了 exit()、die()，或者 PHP 进程被信号强制终止（如 kill -9），finally 就不会执行。这不是 bug，是机制限制。
-
finally在return表达式求值之后、实际返回之前执行（所以能修改返回值，但不推荐） - 即使
catch里又抛出新异常，finally仍会先跑完，再把新异常往上冒泡 - 嵌套
try-finally时，内层finally先于外层执行
资源清理必须放 finally 吗
不是“必须”，但绝大多数需要确定性释放的场景，finally 是唯一靠谱的选择。比如打开文件、获取数据库连接、加锁、启动计时器等。
常见错误是把 fclose($fp) 放在 try 结尾或 catch 里：一旦 try 中间抛异常，fclose 就跳过了；放在 catch 里又漏掉正常流程的清理。
立即学习“PHP免费学习笔记（深入）”；
- 文件操作：
fopen()成功后，立刻进try，fclose()必须进finally - PDO 事务：
$pdo->beginTransaction()后，commit()或rollback()都不该只靠catch分支覆盖 - 自定义锁：
acquireLock()成功后，解锁逻辑必须进finally，否则死锁风险极高
finally 里 throw 或 return 会掩盖原异常吗
会。这是最容易踩的坑：如果 finally 块里有 throw 或 return，它会直接中断原有异常传播或函数返回，导致原始错误丢失。
PHP 7.0+ 会报 Uncaught Exception 并中止脚本，但你看到的已经是 finally 里的异常，不是原来那个。
- 绝对避免在
finally里写throw new Exception(...) - 不要在
finally里写return，哪怕只是return null - 清理失败（比如
fclose()返回false）应该记录日志或触发告警，而不是抛异常 - 真要处理清理失败，用
if (!fclose($fp)) { error_log("fclose failed"); }
PHP 5.5+ 的 finally 兼容性注意点
finally 是 PHP 5.5 引入的，老项目升级前务必确认版本。PHP 5.4 及更早不支持，直接解析失败，报 Parse error: syntax error。
另外，finally 不能单独存在，必须跟 try 配对，且不能和 catch 同时缺失——即 try ... finally 合法，try ... catch 合法，但 try ... finally ... catch 是语法错误。
- 检查版本：
php -v或运行echo PHP_VERSION; - CI/CD 流水线里要显式指定 PHP 版本，避免本地开发用 8.1、测试环境跑在 5.4 上
- 框架或 Composer 包若声明了
"php": "^5.6"，不代表它没用finally，得翻源码确认
真正难的不是写 finally，而是判断哪些资源必须靠它兜底、哪些可以靠析构函数或 RAII 式封装。手写清理逻辑时，别信“这段代码看起来总能走到”，信 finally 的执行契约。
