PHP Fiber 在阻塞 I/O 封装中的调度边界

我第一次把 PHP Fiber 用在 I/O 封装时，最容易误判的一点是：调用了 Fiber::suspend()，并不等于当前的网络或文件操作已经异步。Fiber 只负责暂停一段 PHP 调用栈，真正决定“什么时候继续”的，是外层调度器和非阻塞 I/O。如果底层仍是阻塞调用，它会把整个进程卡住；只有把等待交给事件循环，再用 resume() 或 throw() 把结果送回 Fiber，才形成可用的等待边界。

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

先把 suspend、resume 和 throw 对成一条契约

Fiber 的调用关系可以先压缩成一句话：start() 首次进入回调，Fiber::suspend($value) 暂停当前调用栈并把值交给调用方；之后 resume($value) 会让这次 suspend() 返回值，throw($exception) 则会让异常从这条 suspend() 语句处抛出。

getMessage()}\n";
    }
});

// start 返回第一次 suspend 交出的标记
$signal = $fiber->start();
if ($signal === 'wait-for-io' && $fiber->isSuspended()) {
    // 真实程序应在事件循环回调中执行，而不是立即同步读取
    $fiber->resume('响应数据');
}
?>

阻塞 I/O 为什么仍会卡住整个进程

Fiber 能保存自己的 PHP 调用栈，但不能把内置阻塞函数凭空改造成非阻塞函数。PHP Fiber RFC 明确把事件循环和异步 I/O 留给用户态库：如果在 Fiber 里直接调用 file_get_contents()、阻塞式 fread() 或同步 DNS，当前线程仍会停在那个调用上，其他 Fiber 没有机会被调度。

把可读事件接回 Fiber，而不是在 Fiber 里轮询

一个最小适配器应把“检查流是否可读”交给事件循环。Fiber 只表达业务代码正在等待；事件循环观察非阻塞流，准备好后调用 resume()，失败则调用 throw()。下面用接口表达边界，watchReadable 代表事件循环提供的注册能力。

throw($error);
            return;
        }

        // 回调只交回“已就绪”信号，实际读取仍由 Fiber 完成
        $fiber->resume('readable');
    });

    // 调度器接管等待；这里不会阻塞当前线程
    return Fiber::suspend();
}
?>

完成、超时和资源释放要放在同一个边界里

调度器恢复 Fiber 前要确认它仍处于 suspended 状态，否则重复 resume() 或 throw() 会触发 FiberError。业务侧则要把关闭流、取消监听和取消定时器放进 finally，因为异常可能从 Fiber::suspend() 直接进入。

用边界表判断 Fiber 是否适合当前 I/O

我通常会先回答三个问题：底层调用能否以非阻塞方式报告就绪？有没有事件循环负责恢复和超时？异常和资源是否有明确的回收位置？三个问题只要有一个答不上来，就不要因为“用了 Fiber”而宣称已经获得并发收益。

常见问题

Fiber 能让同步 HTTP 客户端自动并发吗？

不能。客户端必须提供非阻塞传输和事件循环适配；直接把同步请求包进 Fiber 仍会阻塞当前进程。

Fiber 和线程有什么区别？

Fiber 在同一线程里协作式切换，一次只有一个 Fiber 执行；线程可以由操作系统调度，是否并行取决于运行时和硬件。

什么时候应该调用 throw 而不是 resume？

当等待结果是超时、连接关闭或底层 I/O 错误时，用 throw() 把失败交给 Fiber 内的异常处理；正常就绪才用 resume()。