hyperf 3.1 rpc调用在提供者下线后超时，根本原因是客户端未启用服务治理与熔断机制，导致无法及时感知节点失效并快速失败。
Hyperf 3.1 的 RPC 服务调用在提供者下线后出现超时，本质不是“等太久”，而是客户端根本拿不到可用节点——熔断不是自动触发的兜底机制，而是需要显式配置+合理治理联动才能生效的行为。
服务下线后为什么不是立刻报错，而是卡超时？
Hyperf 默认不开启熔断（Circuit Breaker），也没有内置的“节点失联快速失败”逻辑。当提供者容器退出或进程崩溃：
- Consul/Nacos 中该实例会被标记为 critical 或直接剔除，但客户端不会实时感知
- RPC 客户端仍会尝试从负载均衡器中选取节点，若 nodes 静态配置非空，则反复连已下线地址，直到 TCP connect timeout（默认几秒）
- 若使用服务发现且 nodes=[]，但治理组件未启用或拉取间隔过长（如 consul.php 中 watch_interval=30s），客户端可能持续使用缓存中的旧列表
- 最终表现为 read timed out 或 Cannot select any node from load balancer，而非明确的“服务不可用”异常
必须启用服务治理并配置健康检查联动
仅靠 Consul Web UI 看到服务消失，不代表客户端能及时反应。关键动作：
- 确认 config/autoload/services.php 中已启用对应治理驱动，例如：
'providers' => ['consul']，且 consul.php 配置了正确的 host/port/token - 服务提供者启动日志中必须出现 Registered service xxx，否则注册失败，消费者永远查不到
- Consul 健康检查的 check.timeout 必须大于服务 /health 接口实际 P95 耗时（建议 ≥ 2s），check.interval 建议设为 5–10s，避免探测太频繁导致误踢
- 消费者端需启用服务变更监听：确保 hyperf/service-governance-consul 已安装，并在 services.php 中配置 'watch' => true
手动加熔断：用 Sentinel 或自定义 Failover
Hyperf 3.1 原生不带熔断器，需引入外部组件或简单降级：
- 接入 hyperf/sentinel：配置规则对指定 RPC 方法启用熔断，失败率阈值设为 50%，时间窗口 60s，触发后直接返回 fallback（如空数组或默认值）
- 自定义 LoadBalancer：继承 AbstractLoadBalancer，在 select() 中增加节点存活校验（如预发 HTTP 健康探针），跳过已知不可达节点
- 业务层兜底：在 RPC 调用外层包 try/catch，捕获 ConnectException 和 RequestException，降级走本地缓存或返回友好提示，避免用户看到超时白屏
验证是否真“下线即失效”，别信日志和界面
别只看 Consul UI 或 provider 日志说“已注销”。实操验证步骤：
- 进 consumer 容器，执行 curl -v http://consul:8500/v1/health/service/shop_provider_user?passing，确认返回为空数组
- 查 consumer 进程内存：php bin/hyperf.php di:info 'Hyperf\ServiceGovernance\Listener\UpdateServiceListener'，看最近一次服务列表更新时间
- 临时将 consumer 的 rpc_client.php 中 nodes 设为 []，强制走服务发现，再调用，观察错误是否变为 No service found —— 若仍是 timeout，说明治理未生效
