不能。PHP原生fopen配合HTTP封装协议会等待响应体完全接收才返回句柄，不支持真正流式读取；其底层HTTP封装器不暴露分块边界、会静默解压、缺乏状态码/重定向控制，而curl_init配合CURLOPT_WRITEFUNCTION才是轻量可靠的流式替代方案。
PHP
能不能直接流式调用 HTTP 服务？
不能。原生
（配合
或
封装协议）默认会等待整个响应体接收完毕才返回句柄，不支持真正的逐块读取流式响应——尤其在服务端使用
、
持续输出时，
通常卡在
或阻塞在
判断上。
为什么
+
看似流式实则不可靠？
常见写法是：
打开 URL，再循环
或用
，但问题在于：
底层
的 HTTP 封装器不暴露 chunked-transfer
编码
的原始分块边界，
可能合并多个 chunk 或截断在中间
若服务端未设置
或未禁用 gzip 压缩（
），
会静默解压整个 body 后才释放数据，彻底失去流式意义
超时、重定向、
状态码
判断能力弱，无法感知
等流式友好响应
轻量替代方案：用
配合
这是 PHP 中最贴近“流式调用”的轻量做法，无需额外扩展，兼容 PHP 5.5+：
关键点：
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
立即学习
“
PHP免费学习笔记（深入）
”；
设为空字符串，强制不接受
/
回调中可实时处理每批到达的数据，无内存累积
若需解析 Server-Sent Events 或 NDJSON，可在回调里按
或
分割，而非等全文本收完
真正需要低延迟流式时，别硬套
比如调用 LLM 流式接口（
）、实时日志 tail、或大文件分片上传，
的抽象层级太高，丢失了 TCP 层控制权。这时候要么用
的流式回调，要么直接上
/
的异步 HTTP 客户端——但后者已不属于“轻量”范畴。
记住：流式不是“能不能读”，而是“能不能在第一个
字节
到达时就开始处理”。
在 HTTP 场景下做不到这点，别在它身上浪费调试时间。
fopenfopenhttp://https://flush()ob_flush()fopenfread()feof()fopenstream_get_contentsfopenfread($fp, 8192)stream_get_contents($fp, -1, -1)php_streamfreadTransfer-Encoding: chunkedAccept-Encoding: identityfopenHTTP/1.1 206 Partial Contentcurl_initCURLOPT_WRITEFUNCTION$ch = curl_init('https://api.example.com/stream');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, false);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
curl_setopt($ch, CURLOPT_ENCODING, ''); // 禁用自动解压
curl_setopt($ch, CURLOPT_WRITEFUNCTION, function($ch, $data) {
echo $data; // 或写入文件、推入队列、解析 JSON 行等
return strlen($data); // 必须返回写入字节数
});
curl_exec($ch);
curl_close($ch);
CURLOPT_ENCODINGgzipdeflateCURLOPT_WRITEFUNCTION\ndata:fopentext/event-streamfopencURLReactPHPSwoolefopen