根本原因是Swoole HTTP/2客户端对流式帧处理不完整：未启用流控感知、窗口大小过小（默认65535）、并发流上限低（默认100）、超时过短（默认10秒），且TLS下ALPN协商不稳定；需手动配置http2_window_size、http2_max_concurrent_streams、timeout及禁用alpn_protocols，并主动循环recv消费流。
为什么Hyperf的gRPC流式调用会卡住或中断
根本原因不是Hyperf本身，而是底层Swoole协程HTTP/2客户端对流式帧（DATA、CONTINUATION）的处理不完整，尤其在长连接、低频响应或高延迟网络下。默认配置下，Swoole\Http2\Client 未启用流控感知，也未设置合理的流超时和窗口大小，导致服务端持续发包但客户端收不到或丢弃后续帧。
必须调整的三个HTTP/2核心参数
Hyperf的gRPC客户端基于Swoole的Http2\Client，需手动传入settings覆盖默认行为：
-
http2_window_size：设为4194304（4MB），避免服务端因初始窗口太小（默认65535）而阻塞发送； -
http2_max_concurrent_streams：设为1000，防止单连接流数达上限后新流被静默拒绝； -
timeout（非connect_timeout）：必须显式设为30.0或更高，否则协程在无数据时会在10秒左右自动断开，表现为“传输中途断连”。
示例配置（在config/autoload/grpc.php中）：
'client' => [
'settings' => [
'http2_window_size' => 4194304,
'http2_max_concurrent_streams' => 1000,
'timeout' => 30.0,
],
],
别忽略Swoole版本与TLS兼容性
Hyperf 3.x 默认使用 Swoole 5.x，但Http2\Client在 TLS 模式下对 ALPN 协商支持不稳定，容易触发SSL routines:ssl3_read_bytes:ssl handshake failure错误。解决路径很直接：
- 若服务端是gRPC over HTTPS，确保Swoole编译时启用了
openssl且OpenSSL版本≥1.1.1； - 禁用ALPN协商（绕过握手失败）：
'open_ssl' => true, 'ssl_host_name' => 'your-server.com', 'alpn_protocols' => []； - 测试阶段可先用
plaintext模式（http://地址）确认是否为TLS层问题。
流式消费端必须主动读取，不能依赖自动触发
Hyperf的GrpcClient封装并未对流式响应做协程自动拉取，如果你只调用$client->call()而不循环recv()，连接会在首帧后很快关闭。正确做法是：
- 用
while ($data = $stream->recv())显式消费； - 每次
recv()前检查$stream->isClosed()，避免Broken pipe异常； - 对超长流，建议每10次
recv()后加co::sleep(0.001)让出协程，防止单一协程饿死调度器。
流式失败最常发生在“以为调用完就结束了”，实际只是开了个连接，没读——这跟HTTP/1.1完全不同，必须按帧手动驱动。
