FrankenPHP 用原生 EventSource（SSE）实现实时推送，需后端保持连接、分段输出 data: 格式内容并调用 ob_flush()/flush()，前端用 EventSource 自动重连；不推荐 WebSocket 因其需额外进程且无法与 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 脚本只管“推”，不用管“连”。
立即学习“PHP免费学习笔记（深入）”；
前端设计与 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 在绝大多数队列通知场景里，就是更稳、更省事的选择。
