PHP Fiber 中异常抛出与 finally 清理顺序

PHP Fiber 里的异常处理，关键不在于“Fiber 另有一套 finally 规则”，而在于异常进入 Fiber 的位置不同：外部调用 Fiber::throw() 时，异常会从当前 Fiber::suspend() 表达式处进入；之后仍按 PHP 的 try/catch/finally 规则展开。这样看，清理顺序就很明确：先执行能够接住异常的 catch，再执行当前层的 finally；如果没有接住，异常继续向 Fiber 回调外展开，但沿途的 finally 仍会执行。

官方手册：https://www.php.net/manual/en/fibers.php

把 Fiber::throw() 当成“在 suspend 点抛出一个 Throwable”，不要把它理解成从调用方任意位置打断；资源清理应放在 finally，业务补救放在 catch，并避免 finally 用新异常覆盖原始异常。

先固定异常进入 Fiber 的位置

Fiber::throw(Throwable) 只对 suspended Fiber 有明确的注入点。Fiber 回调执行到 Fiber::suspend() 后，外部的 throw() 会让这个 suspend 调用抛出传入的异常，因此 suspend 前面的代码不会重新执行，suspend 后面接收返回值的代码也不会先拿到值。

下面的示例用注释标出职责，代码只用于说明控制关系，不把输出当作运行截图：

getMessage() . "\n";
    } finally {
        // finally 负责释放 Fiber 内持有的资源
        echo "finally\n";
    }
});

// start 运行到 suspend，并让 Fiber 进入 suspended 状态
$fiber->start();
// throw 会从上面的 suspend 位置注入异常，而不是从这里重新开始
$fiber->throw(new RuntimeException('取消当前任务'));

catch 与 finally 的清理顺序怎样判断

如果 catch 能匹配传入的 Throwable，它会先处理异常；离开 catch 后，当前 finally 仍然执行。若 catch 不匹配，或根本没有 catch，异常会继续展开，但每一层已经经过的 finally 都会获得清理机会。

工程上可以把职责拆成三层：try 只做可中断工作，catch 记录、转换或决定是否继续抛出，finally 只做幂等清理。不要把“是否重试”“是否给用户提示”塞进 finally，否则清理路径会改变业务结果。

start();
    } catch (Throwable $e) {
        // Fiber 回调未捕获的异常会在驱动调用处再次出现
        error_log('fiber failed: ' . $e->getMessage());
        throw $e;
    } finally {
        // 外层清理也必须可重复执行，避免覆盖内层资源状态
        releaseSchedulerSlot();
    }
}

如果 Fiber 在回调中抛出异常且没有被 Fiber 内部捕获，Fiber 会进入 terminated 状态，驱动方需要在自己的 catch 中决定记录、重试或向上抛出。Fiber::isTerminated() 只能说明它已经因返回或异常结束，不能替代异常对象本身。

三个容易误判的边界

第一，Fiber 未 suspended 时不能随意 throw。如果 Fiber 仍在运行、已经返回或已经抛错终止，调用 Fiber::throw() 不再拥有当前 suspend 点，PHP 会抛出 FiberError。驱动器应先根据自己的状态机决定只对 suspended 状态注入。

第二，finally 中再次抛错会改变当前传播结果。PHP 手册规定，如果 try 或 catch 中已有异常，而 finally 又抛出一个异常，finally 的异常成为向外传播的主异常，原异常会挂到 getPrevious() 链上。因此清理代码中的失败要有明确策略；能记录就不要无条件覆盖原故障。

第三，不要把 Fiber 和 Generator 的关闭直觉混用。Fiber 是可暂停的完整调用栈，异常从 suspend 点恢复；是否发生清理仍取决于 Fiber 被恢复、终止或被垃圾回收的生命周期，不应仅凭“已经暂停”就断言所有 finally 已经运行。

迁移时可以直接套用的检查清单

• 驱动器是否只在确认 Fiber suspended 后调用 Fiber::throw()？
• Fiber 内部是否把资源释放放进 finally，而不是依赖调用方记得补清理？
• catch 是否保留原始异常上下文，必要时使用 previous 链进行转换？
• finally 是否可能抛出第二个异常，导致首个异常只剩在 getPrevious() 中？
• 驱动层是否区分 FiberError、业务 Throwable 和正常 terminated 状态？

速记：throw() 决定异常从哪个 suspend 点进入，catch 决定是否消费它，finally 决定资源是否收口；只要清楚这三层职责，Fiber 的异常顺序就不会再靠猜。

常见问题

Fiber::throw() 会在调用方直接抛出异常吗？

当 Fiber 正处于 suspended 状态时，异常先从 Fiber 内当前的 Fiber::suspend() 点进入；如果 Fiber 内没有捕获，它才会从驱动调用 throw() 的位置继续向外传播。

finally 抛错后还能找到最初的异常吗？

通常可以通过最终异常的 getPrevious() 链找到原异常，但清理异常已经成为传播主结果。因此清理逻辑应尽量简单、幂等，并把附加故障记录清楚。

官方参考：https://www.php.net/manual/en/fiber.throw.php、https://www.php.net/manual/en/fiber.suspend.php、https://www.php.net/manual/en/control-structures.finally.php