PHP 的 subscribe() 不能用于 Web 请求，因其会阻塞 PHP-FPM worker 导致超时雪崩；正确方案是 CLI 守护进程监听 Redis Pub/Sub 并写入 List/Stream，Web 接口非阻塞拉取，前端用 SSE 消费。
PHP 的 subscribe() 不能直接用在 Web 请求里
它会卡死整个 PHP 进程，不是“不工作”，而是根本不符合 Web 架构。Apache/Nginx + PHP-FPM 下，subscribe() 一执行就阻塞，worker 进程被占住，超时（通常是 30 秒）后被 PHP-FPM 强制杀掉，前端看到的就是空白或 502。
-
set_time_limit(0)和ignore_user_abort(true)压根没用——网关和 PHP-FPM 层的超时你绕不过去 - 浏览器发起一次 HTTP 请求，期望快速响应；而
subscribe()是长连接、永不停止的监听，两者语义冲突 - 哪怕强行跑通，一个用户连上就吃掉一个 PHP worker，100 个并发 = 100 个卡死进程，服务直接雪崩
真正能落地的架构：Pub/Sub + CLI 守护进程 + Web 接口分层
把“监听 Redis 频道”这件事，从 Web 请求生命周期里彻底剥离出去，交给一个长期运行的 PHP CLI 脚本干。
- CLI 进程用
subscribe()或psubscribe()监听notifications等频道，收到消息后立刻写入Redis List（如user:123:inbox）或Redis Stream（更推荐，支持消费组和消息回溯） - Web 接口（比如
/api/notifications）只做一件事：非阻塞地从user:123:inbox里LRANGE或从 Stream 里XREAD拉取新消息，然后返回 JSON - 前端用
EventSource（SSE）轮询这个接口，比 AJAX 长轮询省资源，浏览器原生支持自动重连
为什么别硬刚 publish() + subscribe() 一把梭
Pub/Sub 本身是“发完即焚”模型，没有持久性、无 ACK、不保证送达。它适合广播类通知（比如系统公告），但不适合用户私有消息（比如私信、订单状态变更）。
- 用户 A 订阅了
user:123频道，但中途断网 5 分钟——这 5 分钟所有发到该频道的消息全丢，Redis 不存 - 频道名必须提前约定好，无法动态生成（比如按用户 ID + 设备 ID 组合），否则订阅端不知道订啥
- 如果用模式订阅（
psubscribe('user:*')），所有匹配频道的消息都会推给同一个回调，你得自己 parse$channel字符串来区分接收者，容易出错且难调试
用 SSE 接 Web 层时，ob_flush() 和 flush() 不是万能钥匙
它们只是告诉 PHP 把输出缓冲区内容推给 Web 服务器，但 Nginx/Apache 可能还自带缓冲，甚至加了 gzip 压缩，导致消息卡住不下发。
立即学习“PHP免费学习笔记（深入）”；
- 务必在 Nginx 配置里关掉代理缓冲：
proxy_buffering off;，并设置proxy_cache off; - PHP 脚本开头加：
header('Content-Type: text/event-stream');、header('Cache-Control: no-cache');、header('X-Accel-Buffering: no');（针对 Nginx） - 每次推送消息后，记得输出换行+双换行：
echo "data: ".json_encode($msg)."\n\n";，否则浏览器收不到完整事件
