PHP无法单独实时推送弹幕，因其实为无状态请求响应式语言；必须结合SSE或WebSocket等长连接技术，配合Nginx缓冲禁用、正确HTTP头设置及前端适配才能实现可靠弹幕功能。
能做，但不是靠 PHP 单独“实时”推送给浏览器——PHP 本身是无状态、请求响应式的，无法主动向客户端推送数据。真正的实时弹幕必须搭配前端长连接或服务端事件流机制。
为什么不能只用 echo + flush() 做弹幕
有人试过在 PHP 脚本里循环 echo 弹幕内容，再调用 ob_flush() 和 flush()，结果发现：要么全卡住不输出，要么只刷出最后一句。这是因为：
- Web 服务器（如 Nginx、Apache）通常会缓冲响应，
flush()对它们无效 - 浏览器也可能等待完整响应或足够字节数才渲染，尤其在未设置
Content-Type: text/event-stream或未发送足够初始字符时 - PHP-FPM 模式下，
flush()基本被忽略，根本不会透传到客户端
可行方案：SSE（Server-Sent Events）+ PHP 后端
SSE 是最轻量、兼容性好（Chrome/Firefox/Safari/Edge 均支持，IE 不支持）、适合单向广播（如弹幕）的方案。PHP 只需按规范输出流式文本，前端用 EventSource 接收。
关键点：
立即学习“PHP免费学习笔记（深入）”；
- PHP 脚本必须设置：
header('Content-Type: text/event-stream')、header('Cache-Control: no-cache')、header('X-Accel-Buffering: no')（Nginx 下禁用缓冲） - 每条弹幕要按 SSE 格式写：以
data: {json}开头，结尾双换行\n\n - 避免脚本超时：设置
set_time_limit(0)，并定期发送注释行（:keepalive\n\n）防连接断开
示例片段（danmu.php）：
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('X-Accel-Buffering: no');
set_time_limit(0);
while (true) {
$msg = ['text' => '欢迎来到直播间', 'user' => '游客123', 'time' => time()];
echo "data: " . json_encode($msg, JSON_UNESCAPED_UNICODE) . "\n\n";
ob_flush();
flush();
sleep(2);
}
更健壮的选择：WebSocket + 独立服务（如 Swoole / Workerman）
如果弹幕量大、需用户身份识别、要支持“发送弹幕”双向交互，纯 PHP CGI 模式扛不住。必须用常驻内存的 PHP 扩展框架：
-
Swoole：提供WebSocket\Server，可直接处理连接、广播、房间隔离；注意关闭output_buffering，且不能混用传统$_GET等全局变量 -
Workerman：更轻量，配置简单，适合中小项目；弹幕广播用$connection->sendToAll()即可 - 前端用原生
WebSocket连接，不再依赖 HTTP 生命周期，延迟更低、连接更稳
典型问题：Swoole 中忘记调用 $server->start() 或没监听 onMessage，会导致连接建立后无响应；Workerman 若未运行 php start.php start -d，只是个普通脚本，起不到服务作用。
别忽略前端与部署细节
后端通了，前端仍可能收不到弹幕，常见漏点：
- 前端
EventSource地址没加协议和端口（如new EventSource('/danmu.php')在非根路径会 404） - Nginx 配置里漏了
proxy_buffering off;和proxy_cache off;，导致 SSE 流被截断 - 弹幕 DOM 渲染没做节流或销毁旧节点，滚动卡顿甚至内存泄漏（建议用
requestAnimationFrame控制渲染频率，限制最多显示 50 条） - 没处理重连逻辑：SSE 断线后自动重试，但默认间隔指数增长；WebSocket 需手动实现
onclose后延时重连
真实弹幕系统里，最难的往往不是“怎么发”，而是“怎么撑住 1000 人同时在线、每秒 50 条新弹幕、不丢不卡、不崩服务器”。这时候 PHP 的 IO 模型瓶颈立刻暴露——别硬扛，该上 Swoole 就上，该加 Redis 队列就加，别迷信“PHP 万能”。
