PHP try-finally块include文件触发致命错误仍执行的原理与使用咨询

现象复现 #

index.php #

<?php
function bar()
{
    try {
        $res = 'loading foo:';
        include 'foo.php';
    } finally {
        return $res . 'finally.';
    }
}
$res = bar() . " Why it's working???";

// PHP 7.1.33、7.4.21、8.0.8 均正常输出
echo $res; // "loading foo:foo is load.finally. Why it's working???"

foo.php #

<?php
$res .= 'foo is load.';
$smth = '';
$smth->getBar(); // 此处为调用非对象方法的致命错误

测试现象：被include的foo.php中即使存在调用非对象方法的致命错误、语法错误，程序也不会终止，会正常执行finally块的return语句输出结果。

1. 底层实现原理 #

PHP引擎的执行栈回收逻辑中，finally块的执行优先级极高：只要try块已经进入执行阶段，除非遇到引擎核心级崩溃（比如内存耗尽、核心段错误、SIGKILL信号终止进程），否则无论是抛出异常、触发E_ERROR级致命错误，还是主动调用return/exit，引擎都会在退出当前作用域前优先执行完finally块内的代码。
你观察到的现象本质是流程截断：当include的文件触发致命错误时，引擎原本准备终止进程、输出报错信息，但在执行栈回收阶段发现当前作用域存在待执行的finally块，就先执行finally逻辑；一旦finally块中存在显式return语句，引擎就会直接按照return值返回给上层调用，跳过原本的致命错误终止流程，表现为程序“正常运行”。
这个行为是PHP7.0版本重构执行栈后的既定实现逻辑，你测试的三个版本均保留该逻辑，不属于版本兼容bug。

2. 直接使用该特性的安全风险 #

• 错误静默风险：被finally中return吞掉的致命错误不会触发PHP默认的错误日志记录，也不会走set_error_handler()、set_exception_handler()注册的全局错误处理逻辑，如果没有手动埋点记录日志，开发和运维无法感知代码故障，很容易出现业务逻辑执行一半被截断、事务未提交/回滚、数据写入不完整等脏数据问题。
• 作用域污染风险：include文件中报错前已经执行的代码不会回滚，已经定义的常量、赋值的变量、声明的函数/类、修改的全局状态都会残留在当前作用域，后续逻辑基于这些半初始化的状态运行，会产生大量难以复现的诡异bug。
• 资源泄漏风险：如果报错前include的文件已经打开了文件句柄、数据库连接、分布式锁，且finally块中没有显式释放资源，这些资源会被长期占用，严重时会导致服务连接池打满、资源死锁。
• 安全校验绕过风险：如果include的是权限校验、输入过滤类逻辑，执行到一半触发错误被finally吞掉返回，相当于校验流程未完成就直接放行请求，会直接导致未授权访问、恶意输入绕过防护等严重安全漏洞。

3. 自定义模块加载捕获方案说明 #

你当前实现的捕获逻辑无法获取错误回溯栈，核心原因是catch块只捕获了Exception类型：PHP7之后致命错误是以Error类实例抛出的，Error和Exception共同实现了Throwable接口，只捕获Exception无法接收到致命错误实例，自然拿不到trace信息。

优化后的可获取完整错误信息的实现 #

function loadModule(string $path): string
{
    $res = '';
    ob_start();
    try {
        include $path;
        $res = ob_get_clean();
    } catch (\Throwable $e) {
        // 捕获所有异常、致命错误，可直接获取完整回溯栈
        ob_clean();
        $res = sprintf(
            'Module load error (%s): file %s, line %d, message: %s, trace: %s',
            $path,
            $e->getFile(),
            $e->getLine(),
            $e->getMessage(),
            $e->getTraceAsString()
        );
    } finally {
        // 兜底清空输出缓冲区，避免报错前输出的内容意外泄露
        if (ob_get_length() > 0) {
            ob_end_clean();
        }
        return $res ?: sprintf('Unknown fatal error when loading module (%s)', $path);
    }
}

echo loadModule('module.php');

官方行为说明与使用注意事项 #

• PHP官方手册对finally的核心约定是：只要try块进入执行阶段，无论后续是正常返回、抛出异常还是触发错误，finally块代码一定会执行，但手册未明确标注finally中return会阻断致命错误终止流程的行为，该逻辑属于引擎层面的既定实现，没有官方的兼容性承诺。
• 该方案仅能捕获include执行阶段触发的错误：被include文件的语法错误会在include执行时触发编译，因此可以被捕获；但当前执行文件本身的语法错误会在脚本编译阶段直接失败，根本进入不了try块，无法被捕获。
• 禁止依赖该特性做生产环境的全局错误兜底：全局错误处理必须使用register_shutdown_function()配合error_get_last()实现，该方案仅适合用在插件加载、动态模板渲染这类需要沙箱隔离的非核心场景。
• 加载动态模块前必须做严格的路径校验，限制文件只能在指定的模块目录下，防止目录遍历漏洞读取敏感文件。
• 每次加载模块无论成功失败，都要显式检查并释放已打开的资源、重置临时变量，避免作用域污染影响后续逻辑。
• 所有捕获到的错误必须手动写入错误日志，绝对不能静默丢弃，否则故障出现后无法排查。

内容的提问来源于stack exchange，提问作者Ivan Kurziukov