# Fiber 与 PHP 8.6  Polling API 异步初探

几周前的一篇文章曾介绍 Polling API RFC，并将其定位为被低估的提案，原因主要在于：报道往往漏掉了真正的动机——那是内部 php_poll.h API，而非用户态的 Io\Poll 类。这一判断至今仍然成立。不过随后收到了不少类似"好吧，可它到底能用来做什么？"的反馈。这是个合理的问题，也正是本文要回答的问题。

时机也恰到好处。该 RFC 以 33 票赞成、1 票反对、4 票弃权通过，并于 6 月 3 日投票截止，实现已经合入 master 分支。Alpha 1 预定 7 月 2 日发布，功能冻结与 Beta 1 在 8 月中旬落地，GA 初步定于 11 月 19 日。这意味着 Polling API 已经从一个 RFC 文本，变成可以从 master 编译并立即上手试用、先于正式 alpha 标签就能动手的东西。接下来就做这件事。

与此同时，PHP 社区此刻正围绕"生产环境到底该用哪种异步方案"展开一场活跃的争论：基于用户态事件循环的 Fiber、ReactPHP、Swoole，还是跑在 Revolt 之上的 Amp v3。尚未有人把这场争论与 Polling API 带来的变化清晰挂钩。本文要做的正是这件事，用真实代码，而不只是感觉。

## Fiber 是并发模型，Polling API 是那块缺失的原语

这两者常常被混为一谈，在动手构建任何东西之前，先把它们彻底分开。

Fiber 是 PHP 的协作式并发原语，自 8.1 起进入核心。它提供一个可以自行暂停的函数：通过 Fiber::suspend() 暂停，之后由 $fiber->resume() 恢复，暂停期间自己的栈与局部状态都原封不动。这就是它的全部。它不知道任何关于 socket、定时器或 I/O 的事，只是一个控制流原语，仅此而已。

事件循环负责决定何时恢复一个被挂起的 Fiber。在 PHP 的历史上，这要么依赖底层的 stream_select()，要么借助 PECL 扩展（如 ext-uv 或 ext-event）以获得原生 epoll 或 kqueue。ReactPHP 一口气提供了四种独立的循环实现——StreamSelectLoop、ExtUvLoop、ExtEventLoop、ExtEvLoop——恰恰是因为没有一个可靠的原生原语可以依托。AMPHP 也通过 Revolt 构建了对应的一套方案。

Polling API 正是那块缺失的原语。它不取代 Fiber，本身也不是事件循环。它是事件循环之下 PHP 一直不曾原生拥有的那一层：一种快速向操作系统询问"这些文件描述符中哪些已就绪"的方式，而无需为此维护四套后端实现。

合在一起，Fiber 提供了可暂停的函数，Polling API 提供了高效判断何时恢复它们的途径。这就是全部。其余一切——定时器、取消、背压——都是用户或某个库在此基础上构建的。

## 构建尽可能小的调度器

理解 Amp v3 与 ReactPHP 内部到底在做什么，最好的办法是自己动手做一个玩具版本。接下来就来做这件事：一个并发运行若干 Fiber 的调度器，每个 Fiber 通过原始非阻塞 socket 抓取一个 URL，并由一个 Io\Poll\Context 统一恢复。

```php
<?php

declare(strict_types=1);

use Io\Poll\{Context, Event};

final class MiniScheduler
{
    private Context $poll;

    /** @var array<int, Fiber> */
    private array $fibers = [];

    public function __construct()
    {
        $this->poll = new Context();
    }

    public function spawn(callable $task): void
    {
        $fiber = new Fiber($task);
        $fiber->start();

        if ($fiber->isTerminated()) {
            return;
        }

        $this->fibers[spl_object_id($fiber)] = $fiber;
    }

    public function run(): void
    {
        while ($this->fibers !== []) {
            foreach ($this->poll->wait(timeoutSeconds: 1) as $watcher) {
                $fiber = $watcher->getData()['fiber'];

                $fiber->resume($watcher);

                if ($fiber->isTerminated()) {
                    unset($this->fibers[spl_object_id($fiber)]);
                }
            }
        }
    }

    public function awaitReadable($stream): void
    {
        $fiber = Fiber::getCurrent();
        $handle = new StreamPollHandle($stream);
        $watcher = $this->poll->add($handle, [Event::Read], ['fiber' => $fiber]);

        Fiber::suspend();

        $watcher->remove();
    }

    public function awaitWritable($stream): void
    {
        $fiber = Fiber::getCurrent();
        $handle = new StreamPollHandle($stream);
        $watcher = $this->poll->add($handle, [Event::Write], ['fiber' => $fiber]);

        Fiber::suspend();

        $watcher->remove();
    }
}
```

这实际上就是大部分内容。spawn() 启动一个 Fiber，它会一直运行到遇上 Fiber::suspend()。run() 对 poll 上下文调用 wait()，该调用会阻塞，直到某个被监听的流真正可读，然后恢复恰好等待它的那个 Fiber。没有紧密轮询循环，没有每个 tick 都扫描一遍所有流。操作系统在就绪的第一时间通知，控制权随即直接交还给关心它的那个 Fiber。

现在是真正的任务：基于原始 socket 的非阻塞抓取。这里需要修正初稿中的一处问题：向非阻塞流写入可能发生短写，因此请求必须在一个循环中写入，每当内核发送缓冲区回压时就等待可写状态，而不能指望一次 fwrite() 调用就把整个请求发完：

```php
<?php

declare(strict_types=1);

function writeAll(MiniScheduler $scheduler, $stream, string $data): void
{
    while ($data !== '') {
        $written = fwrite($stream, $data);

        if ($written === false) {
            throw new RuntimeException('Write failed');
        }

        if ($written === 0) {
            $scheduler->awaitWritable($stream);
            continue;
        }

        $data = substr($data, $written);
    }
}

function fetch(MiniScheduler $scheduler, string $host, string $path): string
{
    $stream = stream_socket_client("tcp://{$host}:80", $errno, $errstr, 30);

    if ($stream === false) {
        throw new RuntimeException("Connect to {$host} failed: {$errstr}");
    }

    stream_set_blocking($stream, false);

    writeAll($scheduler, $stream, "GET {$path} HTTP/1.1\r\nHost: {$host}\r\nConnection: close\r\n\r\n");

    $response = '';

    while (!feof($stream)) {
        $scheduler->awaitReadable($stream);
        $response .= fread($stream, 8192);
    }

    fclose($stream);

    return $response;
}
```

关于终止：这个循环依赖 feof() 在一次读到流尾之后翻转为 true，这与 RFC 自己的 TCP 客户端示例采用同一模式。这里之所以成立，有一个值得点明的理由：awaitReadable() 只请求 Event::Read，但 Event::Error 与 Event::HangUp 会被每个后端自动监控，无论请求的是什么，因此当服务器关闭连接时 wait() 仍会返回该 watcher。代码在调用 fread() 之前并不依据 hasTriggered() 做分支，一旦被唤醒就无条件调用它；而在已关闭的非阻塞流上，fread() 会返回空字符串并置位 EOF 标志，既不会阻塞也不会报错。正是这一点让最后一轮迭代干净利落地退出，而不是卡在最后一个描述符上。如果想更严格，读取前检查 hasTriggered(Event::Read)、把 Event::HangUp 单独处理，是更防御性的写法；只是不想让核心循环淹没在一堆不改变普通 HTTP GET 结果的分支之下。

把五个这样的任务接入调度器并发运行：

```php
<?php

declare(strict_types=1);

$scheduler = new MiniScheduler();

$hosts = [
    'example.com',
    'httpbin.org',
    'jsonplaceholder.typicode.com',
];

foreach ($hosts as $host) {
    $scheduler->spawn(function () use ($scheduler, $host) {
        $body = fetch($scheduler, $host, '/');
        echo "{$host}: " . strlen($body) . " bytes\n";
    });
}

$scheduler->run();
```

三个 Fiber，各自阻塞在自己的 socket 上，全部由一个 Io\Poll\Context 独立恢复。从结构上讲，这就是 Revolt 的 driver 在做的事，也是 ReactPHP 的 loop 在做的事。这里只是写出了仍然可用、且最小的那个版本。

## 刻意不展示的东西

这个调度器没有定时器，没有取消令牌，没有从 Fiber 传回调用方的错误传播，没有对永不挂起、从而拖住其他所有人的 Fiber 的防护，也没有 DNS 处理——除 stream_socket_client() 免费提供的部分之外。这不是疏漏，这正是重点。

Amp v3 与 ReactPHP 之所以存在，是因为把这件事做成正确、安全的版本确实很难；要让数百个并发 Fiber 的取消与背压都处理妥当，不是周末就能完成的项目。别把这个调度器带到生产环境附近。把它带来的理解带进你真正选用的那个库。

## 坦诚地做基准测试

在给出数据之前，先把局限说清楚。写下本文时，PHP 8.6 仍是 pre-alpha，从 master 自行编译，并不是可以 apt install 的打包构建。没有稳定版本，没有发行版软件包，Io\Poll 实现到 GA 之前仍可能变化。请把后面的内容视为方向性参考，而非生产环境 SLA。

上面的三主机抓取以四种方式各跑一遍：顺序阻塞的 file_get_contents() 调用、8.6 alpha 构建上的上述迷你调度器、8.4 上 ReactPHP 的 StreamSelectLoop、8.4 上跑在 Revolt 之上的 Amp v3。同样的三个主机、同样的简单 GET 请求，每种十轮，取中位数。

顺序阻塞大致等于三次往返之和，这并不意外，因为每个请求都要等上一个完成后才开始。迷你调度器与 ReactPHP 的 StreamSelectLoop 结果接近，二者大致受限于最慢的单个请求而非总和，这正是并发 I/O 想要的结果。跑在 Revolt 上的 Amp v3 比两者都略微领先，这也符合预期——Revolt 背后有多年调优，而这里只有四十行的调度器。

有趣的结果不是耗时，而是 CPU 行为。基于 stream_select() 的循环，随着被监听流数量的增长，会在用户态重扫描述符集合上消耗明显更多的开销。Io\Poll\Context 版本则保持平稳。三条流对三十条流，每次 wait() 调用代价大致相同，因为 epoll 不会重扫整个集合，它只告诉你哪些就绪了。这才是真正的回报，而且除非有人真的在高并发——数百上千条流，而不是三条——下做基准测试，否则它不会清楚地显现出来。

这个对比中有一个诚实的缺口：ReactPHP 与 Amp v3 跑在 8.4 上，迷你调度器跑在 8.6 pre-alpha 上，因此测到的是循环实现与 PHP 版本一起变化，而非循环本身。同版本对比——ReactPHP 与 Amp v3 都基于同一个 8.6 构建上的 Polling API 后端——才能干净地剥离出循环自身的贡献。目前这还做不到，因为两个项目都还没有交付 Io\Poll driver，而这恰恰是整篇文章的题眼。请把 CPU 行为当作更可靠的信号，因为它是架构层面的，不依赖跑的是哪个 PHP 构建；墙钟耗时则当作粗略的合理性校验，而非定论。

## 这对 Fiber、ReactPHP、Swoole 与 Amp v3 之争意味着什么

这正是前文说要串联起来的争论，以下是最终结论。

Swoole 其实不属于这个对比的范畴，把它当作四个选项之一，正是大量网络争论跑偏的地方。Swoole 是另一个 PHP 运行时。它取代应用原有的启动方式，透明地修补核心函数，使其变为非阻塞，并提供内置 worker 进程的生产级 HTTP 服务器。不是往现有应用里加 Swoole，而是从零开始为 Swoole 构建应用。对合适的工作负载，它确实非常出色；当每一毫秒都要精打细算、且具备在 Docker 镜像中管理编译扩展的运维纪律时，C 层面的协程切换让它对用户态 Fiber 拥有真实优势。Polling API 不会改变这个权衡的任何一个侧面，因为 Swoole 从未被 Polling API 所修复的那个问题限制住。

真正受影响的是 ReactPHP 与 Amp v3，而且方向一致。二者的存在，都是想在 Fiber 之上提供事件循环，而不要求你围绕另一个运行时重写应用。两者都花了多年时间维护多套后端实现——ReactPHP 的 StreamSelectLoop、ExtUvLoop、ExtEventLoop、ExtEvLoop，Amp 的同等规模铺开——纯粹是为了掩盖这样一个事实：PHP 核心从未给它们一个可靠的原生轮询原语。Polling API 终于就是那个原语，它消解了这些平行实现存在的原因。尤其期待 Revolt 会迅速把它接为原生后端——Revolt 本来就坐在 Amp v3 之下，充当共享的底层 driver，而这正是它被设计用来抽象的那类内部管道。

这一切都不会让 ReactPHP 与 Amp v3 之间的选择消失。那仍然主要是一个风格问题。Amp v3 的 Fiber 优先 API 读起来更接近同步代码；ReactPHP 的 promise 链式风格在你想要时给你对循环更显式的控制；而如果确实需要两者共存于同一进程，它们可以通过 revolt/event-loop-adapter-react 互操作。Polling API 所做的是剥夺二者继续维护特制原生后端的借口，同时意味着：一台五美元的 droplet 上跑原版 PHP 8.6，就能获得过去需要编译 PECL 扩展（大多数共享主机都不具备）才能得到的同等 epoll 性能。

## 用 PestPHP 对调度器做个快速检查

如果不想仅凭上面的耗时数字相信并发论断，而是想自行验证，这是大致的测试方式：用两个服务器，各自在响应前固定睡眠一段时间，以确认总耗时跟随最慢的请求而非总和：

```php
<?php

declare(strict_types=1);

it('resumes concurrent fibers without serialising the wait time', function () {
    $scheduler = new MiniScheduler();
    $started = microtime(true);

    foreach (['sleepy-one.test', 'sleepy-two.test'] as $host) {
        $scheduler->spawn(function () use ($scheduler, $host) {
            fetch($scheduler, $host, '/sleep?ms=200');
        });
    }

    $scheduler->run();

    $elapsed = microtime(true) - $started;

    expect($elapsed)->toBeLessThan(0.35);
});
```

两个各约两百毫秒的请求，总耗时远低于二者相加的四百毫秒，这就是整个测试。它不是什么精妙的断言，但它正是这里真正要紧的那一个，而且一旦在某个 Fiber 里不小心写了阻塞代码又忘了，它会立刻失败。

## 实际结论

如果今天在写应用代码，请选择 Amp v3 或 ReactPHP，而不是手写的调度器，并依据想要原生 Fiber 的使用体验，还是显式的 promise 控制来决定。如果运行的负载中每一毫秒、每个连接每一字节内存都举足轻重，并且具备使用编译扩展的运维成熟度，那么 Swoole 配得上它的复杂度。如果你本人就是维护这些库中某一个的人，Polling API 就是当下应该投入开发的东西——趁它还走在 alpha 之前，你的反馈还能真正影响 11 月发布的东西。

PHP 花了整整十年被人断言做不好这件事。事实证明，它只是需要操作系统不再陌生。
[Fiber 与 PHP 8.6  Polling API 异步初探](https://catchadmin.com/post/2026-08/fibers-plus-the-polling-api)

几周前的一篇文章曾介绍 Polling API RFC，并将其定位为被低估的提案，原因主要在于：报道往往漏掉了真正的动机——那是内部 php_poll.h API，而非用户态的 Io\Poll 类。这一判断至今仍然成立。不过随后收到了不少类似"好吧，可它到底能用来做什么？"的反馈。这是个合理的问题，也正是本文要回答的问题。

Fiber 与 PHP 8.6  Polling API 异步初探

前端

PHP 8.6 PollingAPI 与 Fiber 结合，为异步编程提供原生底层原语，无需依赖 PECL 扩展。本文通过构建迷你调度器，对比 ReactPHP、Ampv3 及 Swoole，揭示其在高并发场景下的 CPU 效率优势，并探讨对现有异步生态的深远影响。

HTTP服务器

代码解释

服务器

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Fiber 与 PHP 8.6  Polling API 异步初探-腾讯云开发者社区-腾讯云

Fiber 与 PHP 8.6 Polling API 异步初探

Fiber 与 PHP 8.6 Polling API 异步初探

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐