FrankenPHP怎么把队列处理结果推送给前端-php教程-PHP中文网

frankenphp 用原生 eventsource（sse）实现实时推送，需后端保持连接、分段输出 data: 格式内容并调用 ob_flush()/flush()，前端用 eventsource 自动重连；不推荐 websocket 因其需额外进程且无法与 frankenphp 共享上下文。

frankenphp怎么把队列处理结果推送给前端

用 FrankenPHP 的 `eventsource` 实现实时推送

FrankenPHP 本身不内置消息队列或 WebSocket 服务，但支持原生 PHP 的 eventsource（Server-Sent Events，SSE），这是最轻量、兼容性最好、且无需额外进程的前端推送方案。关键在于：后端不能一次性输出完响应，而要保持连接打开、分段写入；前端用 EventSource 接收。

常见错误是直接 echo 一堆数据后 exit，导致浏览器收不到任何事件——SSE 要求响应头必须包含 Content-Type: text/event-stream，且每次发送需以 data: 开头、空行结尾。

PHP 脚本开头必须调用 header('Content-Type: text/event-stream') 和 header('Cache-Control: no-cache')
每次推送前调用 ob_flush() 和 flush()，否则数据卡在缓冲区
避免使用 exit 或脚本超时中断，可用 set_time_limit(0) 延长执行时间
前端 new EventSource('/sse-queue-handler.php') 自动重连，但需处理 error 事件防死循环

// sse-queue-handler.php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
set_time_limit(0);

while (true) {
    $job = pop_from_queue(); // 你的队列消费逻辑，比如从 Redis List 或 SQLite 表取一条
    if ($job) {
        echo "data: " . json_encode(['status' => 'done', 'id' => $job['id'], 'result' => $job['result']]) . "\n\n";
        ob_flush();
        flush();
    }
    sleep(1); // 避免空轮询压垮 CPU
}

为什么不用 WebSocket？FrankenPHP 的限制在哪

FrankenPHP 是基于 Caddy 的 PHP 运行时，它不托管独立的长连接服务进程。虽然你能用 swoole 或 workerman 启一个 WebSocket 服务器，但它和 FrankenPHP 是两个分离进程，无法共享内存或原生会话上下文。这意味着：你得自己维护队列状态同步、用户认证透传、连接生命周期与 PHP 请求生命周期解耦——复杂度陡增，且违背 FrankenPHP “无额外服务”的设计初衷。

相比之下，SSE 天然适配 FrankenPHP 的 HTTP/2 流式响应能力，Caddy 会自动处理连接复用、心跳、断线重试，PHP 脚本只管“推”，不用管“连”。

前端设计优化skill

前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。

下载

WebSocket 需要额外守护进程（如 php artisan websocket:serve），FrankenPHP 不接管它
SSE 的 EventSource 在所有现代浏览器中开箱即用，无需 polyfill
如果队列任务耗时长（>30s），需在 Caddy 配置里调大 timeout_idle 和 timeout_read

如何让队列处理和 SSE 推送不互相阻塞

PHP 是单进程同步模型，如果把「消费队列」和「推送 SSE」写在一个脚本里，那一个慢任务就会堵住整个流。正确做法是拆成两层：一个短生命周期的「触发器」（如 HTTP 请求提交任务），一个长生命周期的「监听器」（SSE 脚本只负责读结果）。

推荐用 Redis Pub/Sub 或简单 List 作中间媒介：队列消费者（CLI 脚本或 cron）处理完任务后，PUBLISH queue:result {json} 或 RPOP queue:results；SSE 脚本则用 BRPOP queue:results 0 阻塞等待新结果。

不要在 SSE 脚本里调用 sleep() 轮询数据库——用 BRPOP 或 redis->subscribe() 实现真阻塞等待
CLI 消费者和 SSE 脚本共用同一 Redis 实例，零配置同步
若用 SQLite，注意 WAL 模式 + PRAGMA journal_mode = WAL，否则 SELECT 可能被写锁阻塞

前端接收时容易忽略的细节

很多开发者以为 EventSource 收到数据就万事大吉，但实际有三个坑常被跳过：

默认只监听 message 事件，如果后端发的是 event: job_done，前端必须显式写 source.addEventListener('job_done', ...)
没有设置 withCredentials: true 时，跨域请求不会带 cookie，导致会话丢失——Caddy 反向代理下通常同域，但若前端走 Vite/HMR 开发服务器则可能跨域
Chrome 对单个域名的 SSE 连接数有限制（通常 6 个），测试时反复刷新可能触发 net::ERR_INSUFFICIENT_RESOURCES，需在 beforeunload 中调用 source.close()

队列结果推送这件事，核心不在“怎么发”，而在“谁来发、什么时候发、发给谁”。FrankenPHP 的优势是让你把精力留在业务逻辑上，而不是搭通道。别为了“看起来更高级”去硬套 WebSocket，SSE 在绝大多数队列通知场景里，就是更稳、更省事的选择。