PHP实时输出断网不会自动丢数据，但ob_flush()和flush()发出的数据因网络中断无法到达客户端，且服务端无HTTP重连机制；常见接收失败源于Nginx/Apache代理缓冲、浏览器最小缓冲或PHP输出缓冲未关闭；可用connection_status()在每次输出前检测断连，但仅写入时才可靠；更可靠的替代方案是SSE、轮询游标或WebSocket。
PHP实时输出时断网重连是否丢数据
不会自动丢，但ob_flush()和flush()发出的数据一旦网络中断就无法到达客户端，且PHP进程不会感知断连——它照常执行、照常写入缓冲区，直到超时或脚本结束。所谓“重连”在HTTP/1.1纯服务端场景根本不存在：HTTP是无状态请求-响应模型，客户端断开后，服务端没有“重连通道”，只有下次新请求才能重建连接。
为什么flush()之后数据还是收不到
常见于Nginx、Apache代理层或浏览器自身缓存行为，导致即使PHP已调用flush()，数据仍卡在中间环节：
- Nginx默认启用
proxy_buffering on，会攒够64KB或遇到换行才透传；需配proxy_buffering off+proxy_cache off - Apache的
mod_deflate可能延迟输出，关掉压缩或设SetEnv no-gzip 1 - Chrome/Firefox对
text/html响应有最小缓冲（约1KB），建议用Content-Type: text/event-stream或开头输出2048+空格“填满”缓冲区 - PHP的
output_buffering必须设为0（或Off），否则flush()无效
如何检测客户端是否已断开
PHP提供connection_aborted()和connection_status()，但它们只反映TCP连接是否关闭，且**仅在尝试写入时才可靠触发**：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 不能靠轮询
connection_aborted()来“提前发现”断连——它多数时候返回false，直到你真正echo并flush()时才翻转 - 每次输出前加判断：
if (connection_status() !== CONNECTION_NORMAL) { exit; } - 注意CLI模式下这两个函数始终返回
0，不可用于WebSocket或长连接守护进程逻辑
替代方案比死磕flush()更可靠
真要保证消息不丢、支持断线恢复，不要依赖HTTP流式响应：
立即学习“PHP免费学习笔记（深入）”；
- 改用Server-Sent Events（SSE）：
Content-Type: text/event-stream+ 客户端EventSource自动重连，服务端通过id:字段标记序号，客户端可带Last-Event-ID头续传 - 前端轮询+服务端记录游标：每次请求带
last_id，PHP查数据库/Redis增量数据，天然防丢 - WebSocket（如Ratchet/Swoole）：连接由服务端维持，可主动
ping/pong探测，断线后客户端onclose立即重连并请求未收消息
HTTP流本质是单向“尽力而为”，拿它当可靠消息通道，就像用信鸽传银行转账指令——不是做不到，而是所有兜底逻辑都得你自己一拳一脚补全。
