PHP Fibers怎样把阻塞任务封装成可恢复协程怎样在批处理代码中减少额外分配

PHP Fibers 适合解决这样一类批处理问题：一个任务做到某个等待点时，先把控制权交回调度器，外部结果准备好后再从原来的调用栈继续。它能保存完整调用栈，因此比把逻辑拆成很多回调更容易维护；但 Fiber 不会把同步阻塞的网络或磁盘调用自动变成并发，真正的性能收益来自“可交回调度器的等待点”和合适的非阻塞客户端。

官方文档：https://www.php.net/manual/en/language.fibers.php

先把 Fiber 的适用压力说清楚

批量导入、逐条请求外部服务时，最难维护的往往不是循环本身，而是“这一条任务现在等待什么、结果回来后从哪里继续”。Fiber 的模式是把一段普通 PHP 调用栈放进 Fiber，遇到等待点时调用 Fiber::suspend()，调度器拿到暂停值后可以处理其他任务，稍后用 resume() 把结果送回原位置。

这里有三个边界不能混在一起：Fiber 负责保存和恢复执行上下文；调度器负责决定什么时候恢复；外部客户端负责真正的非阻塞等待。如果代码在 Fiber 中直接调用一个同步阻塞的 HTTP 方法，当前 PHP 进程仍然会卡在这个方法里，直到它返回，Fiber 并不能替你切走。

把批处理任务交给 Fiber 保存暂停点

下面的示例把“等待外部结果”表示成一个结构化暂停值。示例中的 wait_for 只是协议标记，实际项目可以由 HTTP 客户端、消息队列或事件循环来完成等待；代码展示的是调用关系，不把未运行的结果写成截图或性能证据。

 'task-result',
                'task_id' => $task['id'],
                'payload' => $task['payload'],
            ]);

            // resume() 传回的值会成为 suspend() 的返回值。
            $results[] = [
                'task_id' => $task['id'],
                'response' => $response,
            ];
        }

        // Fiber 终止后，调度器可通过 getReturn() 取得整批结果。
        return $results;
    });
}

这个结构有一个很实用的好处：任务函数只关心“暂停时需要什么、恢复后如何处理返回值”，不需要知道调度器内部如何管理多个任务。start() 负责第一次运行，第一次遇到 suspend() 时返回暂停值；之后每次 resume($value) 都从上次暂停的位置继续。

用轻量调度器把结果送回原位置

调度器不必很复杂，关键是把暂停值交给对应的外部等待器，并把得到的结果再次传给 Fiber。为了突出职责边界，下面用一个占位的 awaitTaskResult() 表示已由非阻塞客户端完成的等待；它不是可直接连接生产服务的实现。

start();

    while (!$fiber->isTerminated()) {
        try {
            // 实际项目在这里接入事件循环或非阻塞客户端。
            $response = awaitTaskResult($suspension);

            // 恢复值回到 Fiber::suspend() 的返回位置。
            $suspension = $fiber->resume($response);
        } catch (Throwable $error) {
            // 外部失败要作为异常送回 Fiber，而不是静默吞掉。
            $fiber->throw($error);
            break;
        }
    }

    // 只有终止后的 Fiber 才读取最终返回值。
    return $fiber->getReturn();
}

如果一次批处理有很多小任务，循环中的临时数组、请求描述和结果包装也会制造额外分配。可以复用一个固定形状的请求状态对象，处理完一条后覆盖字段；但不要复用仍被外部客户端或异步回调持有的对象。复用的目标是减少生命周期明确的短对象，不是把业务结果藏在全局池里。

真正的阻塞 I/O 不会被 Fiber 自动变成并发

最常见的误用是把同步函数放进 Fiber，然后以为多个 Fiber 就会同时推进。实际上，Fiber 只有在主动暂停时才把控制权交出去；如果同步 I/O 没有返回，Fiber::suspend() 根本没有机会执行。要让批处理具备协作式并发，外部依赖至少要能提供回调、事件通知或可轮询的非阻塞接口。

异常也要纳入协议：客户端失败时可以调用 Fiber::throw()，让 Fiber 内部的 try/catch 按普通调用栈处理；如果 Fiber 没有被正确恢复或抛出，任务可能一直停在暂停状态，结果集合也不会完整。

减少额外分配时，优先检查这张清单

• 任务是否真的存在可交出的等待点，而不是把普通同步函数换了一个包装？
• 每次 resume() 传入的数据是否有明确的任务归属和错误路径？
• 批次结束后，是否能释放暂停载荷、响应缓冲和不再使用的临时状态？
• 若一个 Fiber 永久不再恢复，调度器是否有超时、取消或失败收敛策略？

常见问题

PHP Fiber 和 Generator 最大的区别是什么？

Generator 通过 yield 暴露生成值，通常由生成器自身的迭代语义推进；Fiber 有独立调用栈，可以从嵌套函数中暂停，并由 start()、resume() 或 throw() 控制恢复。

用了 Fiber 后，阻塞 HTTP 请求会自动并发吗？

不会。同步阻塞调用仍会占住当前执行线程，只有底层客户端能把等待交给事件循环或其他可恢复机制时，Fiber 才能参与协作式调度。

为什么要限制暂停值和临时数组的大小？

Fiber 解决的是控制流保存，不会消除数据复制和对象分配。暂停值越大、结果集合存活越久，批处理的内存压力越明显；先缩小状态边界，再考虑复用对象，通常比盲目增加 Fiber 数量更有效。