本文详解如何通过 server-sent events（sse）在 php 中建立持久化连接，使其“静默待命”——不执行业务逻辑，仅在数据库 insert 完成后主动推送数据，避免重复执行与资源浪费。
本文详解如何通过 server-sent events（sse）在 php 中建立持久化连接，使其“静默待命”——不执行业务逻辑，仅在数据库 insert 完成后主动推送数据，避免重复执行与资源浪费。
Server-Sent Events（SSE）是一种单向、服务端主动推送的标准化 Web 技术，非常适合“后台事件通知”类场景——比如用户完成订单后实时刷新其个人页面、管理员操作后同步更新其他在线同事的仪表盘等。它并非要求每次连接都触发业务逻辑；相反，SSE 连接的本质是“长生存期的 HTTP 流”，服务端只需保持响应流打开，等待信号，再按需写入事件即可。
✅ 正确理解 SSE 的服务端模型
SSE 连接在 PHP 中对应一个独立的、长期运行的脚本（如 /sse.php），其核心逻辑不是“处理请求”，而是：
- 设置正确的响应头（Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive）；
- 保持输出缓冲开启，禁用自动刷新（ob_implicit_flush(false)）；
- 进入循环：持续检查是否有新事件（例如监听 Redis Pub/Sub、轮询数据库标志位、或接收进程间信号），若无则 sleep(1) 防止空转；
- 一旦检测到 INSERT 完成（如通过唯一客户端 ID 标记、消息队列通知或共享内存），立即发送格式化事件：
// 示例：向指定 client_id 推送订单更新
echo "id: " . time() . "\n";
echo "event: order_update\n";
echo "data: {\"order_id\":123,\"status\":\"confirmed\"}\n\n";
ob_flush();
flush();⚠️ 注意：客户端 EventSource 不需要、也不应该指向执行 INSERT 的接口（如 /api/insert-order.php）。那是两个完全分离的通道：
- POST /api/insert-order.php → 执行业务逻辑 + 触发通知机制（如 redis->publish('channel:client_456', $payload)）；
- new EventSource('/sse.php?client_id=456') → 独立连接，只监听该 client_id 对应的消息。
? 如何避免“每次重连都执行 INSERT 逻辑”？
关键在于解耦连接生命周期与业务执行周期：
立即学习“PHP免费学习笔记（深入）”；
- SSE 脚本（/sse.php）本身不含 INSERT 代码，它只是“信使”；
- INSERT 发生在另一个入口点，完成后通过轻量级通信（推荐 Redis Pub/Sub 或 SQLite WAL 模式下的通知表）告知所有待命的 SSE 进程；
- 每个 SSE 进程只负责过滤出属于自己的消息（基于 client_id 参数），然后推送。
这样，即使客户端因网络波动断连重试（SSE 自动重连），服务端也只会重新建立监听，不会重复插入数据或触发业务动作——这正是你所期望的“连接常驻、代码不跑”。
? SSE vs WebSocket：何时选谁？
- 选 SSE：推送为主、无需客户端反向指令、部署简单（纯 HTTP）、兼容性好（除 IE）、运维成本低；
- 选 WebSocket：需双向实时交互（如聊天、协作编辑）、低延迟要求极高（毫秒级）、服务端需维护连接状态和心跳；
- ❗长轮询（Long Polling）的瓶颈（连接频繁建立/销毁、HTTP 头开销大）在 SSE 和 WebSocket 中均被消除——二者都复用底层 TCP 连接。现代 HTTP/2 更进一步通过多路复用降低 SSE 的头部冗余。
✅ 最佳实践总结
- 使用 EventSource 时务必携带唯一标识（如 ?client_id=<?=$_SESSION['id']?>），便于服务端精准推送；
- PHP SSE 脚本需设置 set_time_limit(0) 和 ignore_user_abort(true)，防止超时中断；
- 生产环境务必配合 Nginx 配置 proxy_buffering off; proxy_cache off;，避免代理层缓存或截断流；
- 若并发连接数高（>1000），建议用 Swoole/Swoft 替代传统 PHP-FPM，提升连接管理效率。
SSE 不是“必须绑定业务接口”的黑盒，而是一个可编程的、可控的推送管道——你掌控何时连接、何时监听、何时发送。只要架构分层清晰，它就能以极简方式替代长轮询，且比 WebSocket 更专注、更可靠。
