PHP 8.6 原生 Polling API 实战：摆脱 stream_select 的高效 I/O 多路复用方案

当 PHP 后端需要同时等待多个网络连接、管道或其他 I/O 资源时，传统的 stream_select() 往往会成为代码和扩展能力上的限制。PHP 8.6 引入的 IoPoll 命名空间提供了原生 I/O 轮询接口，让应用可以用更统一的方式等待可读、可写或异常事件。它不是完整的异步框架，也不会自动替你调度任务，但可以作为 WordPress 插件接口、后台任务服务或独立 PHP 守护进程中的底层 I/O 监视组件。

为什么需要 Polling API

I/O 多路复用的核心并不是让 CPU 同时执行多个 PHP 任务，而是让一个进程在等待多个 I/O 资源时，不必阻塞在其中某一个连接上。轮询器会等待一组资源，当其中某个资源具备读取、写入或异常条件时，再把控制权交给应用代码处理。

在 PHP 8.6 之前，标准 PHP 代码主要通过 stream_select() 完成这项工作。它基于传统的 select() 机制，能够解决基础的多连接等待问题，但存在几个实际限制：

• 需要分别维护读集合、写集合和异常集合；
• 每次调用前通常都要重新准备资源数组；
• 返回结果会修改传入的资源集合，业务代码需要额外判断；
• 代码容易把“连接管理”“事件判断”和“任务执行”混在一起；
• 底层使用的机制受 select() 模型限制，面对大量连接时扩展性有限。

PHP RFC 对 IoPoll 的定位，是提供统一的用户空间轮询接口，并允许底层根据运行平台选择更合适的实现，例如 Linux 上的 epoll、BSD 或 macOS 上的 kqueue，以及 Windows 环境中的 WSAPoll。这改善的是 I/O 事件监视能力，不等于 PHP 自动获得了完整的事件循环或协程运行时。

stream_select() 与 IoPoll 的思路差异

使用 stream_select() 时，应用通常围绕“当前哪些资源在数组里”组织代码。下面是一个简化的旧式轮询结构：

$read = $clients;
$write = [];
$except = $clients;

$changed = stream_select($read, $write, $except, 1);

if ($changed === false) {
    throw new RuntimeException('等待 I/O 事件失败');
}

foreach ($read as $stream) {
    $data = fread($stream, 8192);

    if ($data === '' && feof($stream)) {
        fclose($stream);
        continue;
    }

    // 处理读取到的数据
}

这段代码可以工作，但随着连接状态增多，外围逻辑会迅速膨胀。应用需要自行维护客户端集合、连接状态、待写数据、异常连接以及资源关闭流程。更麻烦的是，stream_select() 返回的是被筛选后的资源集合，业务代码还要通过数组身份判断每个资源属于哪一类事件。

IoPoll 的重点是把“订阅资源”和“获取事件”分开。应用先把资源注册到轮询器中，并声明关心的事件类型；轮询器返回事件后，应用只处理本次真正就绪的资源。这样更适合封装成连接管理器或任务调度器。

下面的代码展示推荐的组织方式。由于 IoPoll 属于 PHP 8.6 的新 API，具体方法名和事件常量应以目标 PHP 8.6 正式文档为准；代码重点是事件循环的职责划分，而不是兼容旧版本的完整实现。

<?php

use IoPoll;

$poll = new Poll();
$clients = [];

function registerClient(Poll $poll, $stream, array &$clients): void
{
    stream_set_blocking($stream, false);

    $id = (int) $stream;
    $clients[$id] = $stream;

    // 按 PHP 8.6 正式 API 注册可读事件。
    $poll->subscribe($stream, Poll::READ);
}

$server = stream_socket_server(
    'tcp://127.0.0.1:9000',
    $errorCode,
    $errorMessage
);

if ($server === false) {
    throw new RuntimeException($errorMessage, $errorCode);
}

stream_set_blocking($server, false);
$poll->subscribe($server, Poll::READ);

while (true) {
    // 等待一批已经就绪的 I/O 资源。
    $events = $poll->poll(1.0);

    foreach ($events as $event) {
        $stream = $event->stream();

        if ($stream === $server) {
            $client = stream_socket_accept($server, 0);

            if ($client !== false) {
                registerClient($poll, $client, $clients);
            }

            continue;
        }

        $data = fread($stream, 8192);

        if ($data === '' && feof($stream)) {
            $id = (int) $stream;

            $poll->unsubscribe($stream);
            fclose($stream);
            unset($clients[$id]);

            continue;
        }

        if ($data !== '') {
            // 在这里处理客户端请求，或把任务放入待执行队列。
            fwrite($stream, "HTTP/1.1 200 OKrn");
            fwrite($stream, "Content-Type: text/plainrn");
            fwrite($stream, "Content-Length: 2rnrnOK");
        }
    }
}

这段示例中的 subscribe()、unsubscribe()、poll()、stream() 以及事件常量是为了说明轮询模型而使用的接口占位写法。实际开发时不能直接依据旧版草稿猜测方法名，应以 PHP 8.6 发布版本的 IoPoll API 定义为准。重要的是不要把 IoPoll 和 stream_select() 的返回结构混用：两者都服务于 I/O 多路复用，但资源注册、事件返回和状态管理方式可能不同。

一个简单的异步任务轮询模型

“异步任务”在这里应理解为：任务不会阻塞整个轮询循环，应用在每次 I/O 事件处理之间推进少量任务。IoPoll 只负责发现 I/O 事件，任务本身仍然需要应用代码管理。

例如，一个 WordPress 插件可能需要在后台服务中等待多个外部连接，同时处理待执行的内容同步任务。任务可以使用状态对象表示，而不是在循环里直接执行一个可能长时间阻塞的函数：

<?php

$tasks = [
    [
        'id' => 'sync-001',
        'state' => 'waiting',
        'step' => 0,
    ],
    [
        'id' => 'sync-002',
        'state' => 'waiting',
        'step' => 0,
    ],
];

function runTaskStep(array &$task): bool
{
    if ($task['state'] === 'done' || $task['state'] === 'failed') {
        return true;
    }

    // 每次只推进一个小步骤，避免阻塞其他连接。
    if ($task['step'] < 3) {
        $task['step']++;
        return false;
    }

    $task['state'] = 'done';

    return true;
}

while (true) {
    // 这里应调用 PHP 8.6 正式 API，等待 I/O 事件。
    $events = $poll->poll(0.1);

    foreach ($events as $event) {
        $stream = $event->stream();

        // 读取数据、更新连接状态，或创建新的待执行任务。
        $data = fread($stream, 8192);

        if ($data === '' && feof($stream)) {
            $poll->unsubscribe($stream);
            fclose($stream);
        }
    }

    foreach ($tasks as &$task) {
        if ($task['state'] === 'waiting') {
            runTaskStep($task);
        }
    }
    unset($task);

    $pending = array_filter(
        $tasks,
        static fn (array $task): bool =>
            !in_array($task['state'], ['done', 'failed'], true)
    );

    if ($pending === []) {
        break;
    }
}

这个模型的关键是“分步推进”。如果 runTaskStep() 内部仍然执行一个长时间阻塞的数据库查询、文件操作或网络请求，那么轮询器依旧无法及时处理其他连接。要获得实际收益，任务需要拆成较小的状态转换，或者把可能阻塞的工作交给独立进程、队列消费者或其他执行单元。

因此，IoPoll 适合承担的是事件等待层，而不是业务任务本身。它可以通知“某个连接现在可以读取了”，但不会替你决定如何解析协议、如何限制任务耗时，也不会自动提供协程调度。

性能差异应该怎样判断

IoPoll 相比 stream_select() 的主要潜在优势，来自底层事件监视机制和更适合扩展的事件管理方式，而不是某一段 PHP 语法天然更快。实际性能仍会受到连接数量、事件活跃程度、数据包大小、业务处理时间和操作系统实现的影响。

可以从三个维度进行判断。

首先是轮询开销。传统 select() 模型通常需要把资源集合交给系统调用，并在返回后重新检查结果。连接规模增大时，资源集合的维护和遍历会变得更明显。原生 IoPoll 可以在支持的平台上使用更适合大量连接的底层机制，从而减少轮询层的额外工作。

其次是代码复杂度。stream_select() 并非不能用于并发连接，数量较少、逻辑简单的后台脚本完全可以继续使用它。IoPoll 的价值在于把资源订阅、事件类型和就绪事件更清晰地组织起来，减少业务代码对资源数组细节的依赖。

最后是端到端耗时。即使轮询器本身更高效，如果每次事件处理都执行复杂的 PHP 逻辑、慢速数据库查询或阻塞式远程请求，整体吞吐量仍然会受到这些环节限制。不要只比较轮询函数耗时，应同时记录事件等待、数据处理、任务执行和连接关闭等阶段。

如果要在项目中验证差异，应该使用相同的连接行为、相同的数据量和相同的业务处理逻辑，分别测试 stream_select() 与 IoPoll。测试结果需要结合目标操作系统和 PHP 构建环境解读，不能把某个环境中的结果直接当作所有部署环境的结论。

在 PHP 或 WordPress 项目中如何落地

对于普通 WordPress 请求生命周期，IoPoll 并不会自动改变 PHP-FPM 的执行模式。一个插件在处理单次管理后台请求时，通常不应该为了使用轮询器而长期占用 PHP worker。更合适的场景包括独立运行的 CLI 脚本、后台同步服务、站点内部的长连接组件，或由队列系统启动的专用任务进程。

如果 WordPress 插件需要连接多个外部服务，可以把轮询逻辑放在独立的 PHP 进程中，再通过数据库、任务队列或站点接口与 WordPress 主站交换状态。这样既能利用原生 I/O 监视，也不会让普通页面请求承担长时间连接管理。

落地时还需要检查几个边界：

• 确认生产环境确实运行 PHP 8.6，并核对 IoPoll 的正式 API；
• 不要把 IoPoll 当作完整事件循环或协程框架；
• 每个连接都要设置明确的关闭、错误和超时处理；
• 对输入数据设置合理的缓冲区和解析边界；
• 长任务应拆分为小步骤，避免单个回调阻塞整个轮询循环；
• 在 WordPress 环境中避免让前台请求长期持有连接。

IoPoll 的实际意义，是为 PHP 提供一个更现代的原生 I/O 监视基础。它可以减少对 stream_select() 的依赖，也可以让开发者在不引入完整异步运行时的情况下构建更清晰的连接管理层。但性能提升不会自动发生：只有当应用正确管理事件、避免阻塞任务，并根据目标部署环境完成测试时，原生轮询 API 才能真正转化为后端接口的并发能力。