PHP finally 怎样保证临时文件在 return 前关闭

PHP 里临时文件需要在函数返回前关闭时，把 fclose() 放进 finally，并让 return 留在 try 或 catch 中。这样函数准备返回的值会先确定，finally 负责清理句柄，清理结束后才把原值交给调用方。关键边界只有一个：不要在 finally 里再次 return，否则可能覆盖原返回值，甚至让异常消失。

本文只讨论文件资源和控制流，不把 finally 当作所有进程终止场景的保证。PHP 官方说明：脚本被 exit() 或致命错误突然终止时，不能按普通离开路径假定 finally 一定完成。

先把 return 和 finally 的边界画清楚

函数遇到 return $value 时，返回表达式会先被求值，但函数不会立即跳过 finally。因此，临时文件的读取结果可以在 try 中准备好，finally 再关闭句柄，调用方最后仍收到同一个结果。

这和“返回前执行一段清理”是两件事：清理应该改变资源状态，不应该重新决定业务返回值。若 finally 自己写了 return，它会成为最终返回值；若清理块抛出新的异常，也可能改变原先异常的传播结果。

临时文件句柄要先初始化，再由 finally 统一关闭

句柄在打开前应保持可判断的空值。这样即使 fopen() 失败，也能安全离开；打开成功后，finally 再用 is_resource() 判断是否需要释放。下面的示例把读取、错误转换和关闭职责分开，清理块没有返回值。

这个结构同时覆盖正常读取、读取失败和打开后抛错三种路径。打开失败时句柄仍是 null；打开成功后，不管 stream_get_contents() 返回还是抛出异常，finally 都会尝试关闭它。fclose() 返回的布尔值不应拿来替换业务返回值，若关闭失败需要记录或抛出，也要先明确它是否会掩盖更重要的原始异常。

清理代码不要覆盖原结果和原异常

最容易埋 bug 的写法是把“关闭成功”当成函数结果，或者为了复用一行代码在 finally 里直接 return true。前者改变了函数契约，后者会覆盖 try 中已经准备好的文件内容。PHP 官方迁移文档还指出，在 finally 中使用 return 会造成异常被静默丢弃或返回值被覆盖，并在新版本中被弃用。

如果关闭动作本身出现异常，生产代码应按资源的重要性决定策略：普通临时文件可记录关闭失败并保留原始业务异常；不可丢失的写入资源则应让清理失败进入明确的错误路径。不要用一个宽泛的 catch (Throwable) 把两类故障都改成成功。

上线前按四个边界检查资源释放

还要留意两种边界。第一，exit() 或致命错误导致脚本突然终止时，不能把 finally 当成进程级清理器；关键临时文件应设计明确的生命周期和后续回收策略。第二，若句柄并非普通 PHP 流资源，关闭方法可能由对象或扩展负责，不能机械套用 fclose()，应按具体类型的官方接口释放。

相关问题

return 写在 try 里，finally 还会执行吗？

会。正常的 return 会先确定结果，随后执行 finally，清理完成后才返回。

可以在 finally 里 return “关闭成功”吗？

不建议。它会覆盖 try 或 catch 的返回值；如果前面有异常，还可能让异常不再被调用方看到。

finally 能保证任何情况下都关闭文件吗？

不能把它理解为进程级保证。正常控制流和异常展开会进入 finally，但 exit() 或致命错误等突然终止场景需要额外的生命周期设计。