PHP实时输出基于HTTP短连接单向推送，适合短时进度展示；WebSocket基于独立TCP长连接双向通信，适用于实时交互场景。
PHP实时输出本质是HTTP长连接，不是真正的双向通信
PHP的flush()和ob_flush()只是把缓冲区内容推给客户端，整个过程仍基于传统HTTP请求—响应模型：浏览器发一次请求，PHP脚本执行完就断开。它不维持连接，也不能主动向服务端发数据。常见于日志流、安装进度条、CLI转Web界面等单向推送场景。
容易踩的坑：
– Nginx默认启用fastcgi_buffering on，会拦截flush输出，需显式关掉；
– Apache的mod_deflate可能压缩并缓存响应体，导致前端收不到分段数据；
– 浏览器（尤其是移动端）可能对小块响应做延迟合并，需在每段后加足够空格或注释“填充”到1KB以上。
WebSocket是独立TCP连接，支持全双工、低延迟、长生命周期
WebSocket协议（ws://或wss://）建立后，客户端和服务端可随时互发消息，不依赖HTTP轮询。PHP本身不原生支持WebSocket服务器，需借助ReactPHP、Swoole或Workerman等扩展实现服务端逻辑。
典型适用场景：
– 实时聊天、协作编辑、多人游戏状态同步；
– 仪表盘数据秒级刷新（如监控告警）；
– 用户在线状态广播、消息未读数实时更新。
立即学习“PHP免费学习笔记（深入）”；
注意：Swoole\WebSocket\Server必须运行在CLI模式，不能跑在Apache/Nginx的FPM里；前端用new WebSocket('ws://localhost:9501')连接，且要处理onopen/onmessage/onclose事件。
选PHP实时输出还是WebSocket？看连接是否需要“保持”和“反向触发”
如果只是“服务端单向吐数据，且整个过程不超过几十秒”，比如部署脚本执行流、大文件导出进度、AI推理中间结果展示，用ob_implicit_flush(true) + ob_end_flush() + 循环echo更轻量，无需额外进程或端口。
但只要涉及以下任一条件，就必须上WebSocket：
– 客户端要随时发送指令（如暂停任务、调整参数）；
– 多个用户间需广播消息（如弹幕、点赞）；
– 连接需维持数分钟以上，且期间无固定请求节奏；
– 服务端需根据其他来源（如数据库变更、Redis Pub/Sub）主动推送给指定用户。
性能与部署差异极大：一个走现有Web栈，一个要单独起服务
PHP实时输出复用原有Nginx/Apache+PHP-FPM架构，只需调优缓冲和超时参数（如fastcgi_read_timeout设为300），部署零新增。
WebSocket则完全不同：
– 必须单独启动一个常驻PHP进程（如php websocket_server.php）；
– 需反向代理配置（Nginx的proxy_pass ws://backend）或直接暴露端口；
– 进程管理、心跳保活、连接数限制、异常断连重试都要自己处理；
– Swoole虽快，但不兼容所有PHP扩展（如xdebug在协程中不可用）。
别低估连接管理成本：1000个WebSocket长连接 ≈ 1000个持续占用的PHP进程/协程，而1000个HTTP实时请求是瞬时并发、很快释放的。
真正难的从来不是“怎么推”，而是“推给谁”“推多少次”“断了怎么办”“别人改了数据你怎么知道”。这些逻辑在WebSocket里得自己写，在PHP实时输出里压根不存在——因为根本没连接。
