PHP实时输出失败主因是中间层缓冲与超时，需同时配置Nginx（proxy_buffering off、fastcgi_buffering off等）、PHP（set_time_limit(0)、ob_implicit_flush(true)、flush()）及服务端心跳保活。
PHP 实时输出长连接（比如 Server-Sent Events 或流式响应）本身不难，难的是在真实环境中稳定维持——多数失败不是因为代码写错，而是被中间层（Nginx、Apache、PHP-FPM、浏览器或代理）悄悄截断、缓冲或超时。
为什么 flush() 和 ob_flush() 经常没反应
这两个函数只是把 PHP 输出缓冲区的内容“推给 SAPI”，但之后还卡在 Web 服务器和网络栈手里。常见失效原因：
- Nginx 默认开启
proxy_buffering on，会攒够 4KB 或等响应结束才发给客户端 - PHP-FPM 的
buffer_output = yes（默认）会让输出先进 FPM 缓冲区 - Apache 的
mod_deflate或mod_php输出过滤器可能延迟发送 - 浏览器（尤其 Safari）对未带
Content-Type: text/event-stream的流式响应会等 1~3 秒再渲染
实操建议：用 curl -N http://your.app/stream.php 测试（-N 关闭 curl 自动缓冲），比浏览器更可信。
Nginx 下必须关掉的三项配置
只要走 Nginx + PHP-FPM，这三处不改，flush() 基本等于摆设：
立即学习“PHP免费学习笔记（深入）”；
-
proxy_buffering off;（在location块里） -
proxy_buffer_size 4k;改成proxy_buffer_size 128k;并配proxy_buffers 8 128k;（避免小包被合并） -
fastcgi_buffering off;（Nginx 1.11.5+ 才支持；旧版本得用fastcgi_buffer_size 128k; fastcgi_buffers 8 128k;并确保fastcgi_busy_buffers_size足够大）
漏掉任何一项，都可能看到前几条数据正常，后面突然卡住或直接断连。
PHP 层该设的最小安全配置
光关缓冲不够，还要防超时和自动清理：
- 开头加
set_time_limit(0);—— 否则脚本 30 秒后被 PHP 强杀 - 禁用输出压缩：
if (function_exists('apache_setenv')) { apache_setenv('no-gzip', '1'); }（Apache）或ini_set('zlib.output_compression', 'Off'); - 清空所有已启用的输出缓冲：
while (ob_get_level()) ob_end_clean();，再ob_implicit_flush(true); - 每条消息后加换行和双换行（SSE 要求）：
echo "data: hello/n/n"; flush();
注意：ob_implicit_flush(true) 不等于自动 flush()，它只让每个 echo 后隐式调用一次，仍需手动 flush() 确保穿透到 SAPI。
超时控制必须前后端对齐
长连接不是“永不超时”，而是要明确谁管哪段超时：
- PHP：
set_time_limit(0)只防脚本执行超时，不防连接空闲超时 - Nginx：
proxy_read_timeout 300;控制 upstream 返回间隔，别设太短（如 60 秒） - 浏览器：SSE 自动重连，但首次连接若卡住，会等
EventSource的timeout（非标准属性，实际靠服务端心跳） - 推荐方案：服务端每 15~30 秒发一条空注释
": heartbeat/n/n，既保活又不触发前端message事件
最容易被忽略的是 Nginx 的 keepalive_timeout 和 send_timeout —— 如果它们比你的业务心跳还短，连接会在你毫无察觉时被 Nginx 主动断开。