PHP stream_set_timeout 后怎么判断读取是否超时

用 PHP 读取 TCP 流或远程文件时，fread() 返回空字符串并不等于“已经读完”。它可能是对端暂时没有继续发数据，也可能是流已经到达 EOF。设置 stream_set_timeout() 后，最可靠的判断位置是紧跟在 fread() 或 fgets() 后面调用 stream_get_meta_data()，检查返回数组里的 timed_out。

为什么 timed_out 要在读取调用之后检查

stream_set_timeout($stream, 2) 设置的是流等待数据的时限，单位由秒和微秒组成。它不是连接建立超时，也不是整个 PHP 请求的总耗时。只有后续读取操作确实等待不到数据，元数据中的 timed_out 才有对应意义。

官方手册对这个字段的描述很明确：它反映最近一次 fread() 或 fgets() 等待读取数据时是否超时。因此，把元数据检查放到读取之前，读到的可能仍是上一次操作留下的状态；在循环中则应每次读取后立即取一次。

这里先检查超时，再检查 false，最后用 $chunk === '' && feof($stream) 判断正常结束。实际项目还应记录 $errno、对端身份和重试次数，但不要把超时当成 PHP 异常自动处理。

超时、EOF 与空字符串不能混着判断

最容易误判的代码是 if ($data === '') { /* 读完了 */ }。对于网络流，空字符串只能说明这次没有得到可交付的字符，不能单独证明对端已经关闭。可以用下面的对比快速定位：

还有一个细节：stream_get_meta_data() 返回的 eof 在 socket 流上可能和内部缓冲区状态同时出现，官方建议判断是否还有数据时使用 feof()，不要把 unread_bytes 当成业务完成标志。

循环读取时，把判断放在每一轮的同一位置

批量读取时，建议固定成“读取一次—取元数据—分类处理”的小循环。这样不会把上一轮的 timed_out 状态误套到下一轮，也方便在超时后保留已收到的部分数据。

如果使用非阻塞模式，空读的含义会更多，不能照搬阻塞读取的判断。若操作的是 stream_socket_recvfrom() 这类高级 socket 操作，官方手册建议改用带超时参数的 stream_select()。另外，stream_get_meta_data() 不适用于 PHP Socket 扩展创建的 socket；那一类对象应使用 Socket 扩展自己的选项和 API。

一张检查清单帮你避免误判

• 确认 stream_set_timeout() 的返回值为 true，并明确它保护的是读取等待。
• 每次 fread() 或 fgets() 后立即读取 stream_get_meta_data()。
• 先判断 timed_out，再区分 false、feof() 和普通数据。
• 循环里保留已经收到的数据；超时后的重试必须有次数或总时限。
• 确认底层对象确实是 PHP stream，而不是 Socket 扩展资源。

常见问题

stream_set_timeout() 超时会抛异常吗？

不会自动产生错误或 warning。读取后主动检查 stream_get_meta_data($stream)['timed_out']，再决定记录、重试还是降级。

timed_out=true 后还能继续读取吗？

可以把它当作本次等待没有拿到数据来处理，但是否继续取决于协议和业务；继续前要限制重试次数，并保留已读取内容。

为什么 eof=true 还不能只看 unread_bytes？

socket 流的 EOF 和内部缓冲状态不是同一个概念。判断是否已到流末尾使用 feof()，不要用 unread_bytes 代替业务判断。