hyperf 3.1.66 版本新增 grpc 多客户端负载均衡支持，非 3.1.68；确认版本应以 composer show hyperf/framework 或 hyperf ersion::version 输出为准；配置需启用 service-governance、指定 load_balancer 且注册中心返回多个健康实例。
Hyperf 3.1.68 没有多客户端负载均衡支持——这是对 v3.1.66 版本特性的误传。官方更新日志明确标注，gRPC 多客户端负载均衡支持 是 v3.1.66 引入的核心特性，不是 3.1.68 的新增功能。
怎么确认自己用的是哪个 Hyperf 版本
别信 composer.lock 里模糊的 “~3.1.0” 或包名后缀，直接看运行时输出或命令行：
- 启动服务后日志第一行通常带版本号，如
[INFO] Hyperf Framework v3.1.66 - 执行
composer show hyperf/framework，输出中versions字段为准 - 代码里调用
HyperfVersion::VERSION，返回字符串可精确比对
如果你看到的不是 3.1.66，那所谓“3.1.68 的多客户端负载均衡”大概率是本地未更新依赖、缓存未清，或文档抄错版本号。
gRPC 多客户端负载均衡实际怎么配
这个特性只作用于 gRPC Consumer（即调用方），不是 HTTP 客户端或数据库连接池。它解决的是：一个服务有多个 gRPC 实例注册到 Nacos/Consul 后，Hyperf 如何在它们之间分发请求。
- 必须启用
hyperf/service-governance和对应注册中心组件（如hyperf/nacos） - Consumer 配置里要显式指定
load_balancer，例如：'load_balancer' => 'round_robin' - 不配置时默认用
random，但least_conn和round_robin才算真正“多客户端”调度 - 注意：gRPC 连接是长连接，负载均衡发生在连接建立阶段，不是每次 RPC 调用都重选
为什么 load_balancer 设了也不生效
常见失效不是配置写错，而是底层没走服务发现链路：
- Consumer 的
service值没匹配注册中心里发布的接口全限定名（比如少了App\Grpc\UserServiceInterface的命名空间） - 用了
host/port直连模式（即配置了servers数组），会跳过服务发现和负载均衡逻辑 - 注册中心没真正返回多个实例——检查 Nacos 控制台或 Consul UI，确认同一
service_name下至少有两个 healthy 实例 -
hyperf/grpc-client版本低于3.1.66，旧版根本不识别load_balancer配置项
升级到 v3.1.66 后要注意的兼容点
这个版本改动集中在 gRPC 和连接池，其他模块基本无感，但两个点容易漏：
-
Pool组件的max_idle_time默认从60改为30秒，短连接场景下可能提前回收连接，需按业务心跳周期调整 -
Guzzle客户端默认开启cookies持久化，若你原来靠手动管理 CookieJar，现在要检查是否重复 setCookie 导致冲突 - 如果项目里自定义了
GrpcClientFactory，需确认构造参数签名是否匹配新版本——v3.1.66增加了$loadBalancer第四个参数
版本号写错、配置路径不对、注册中心没返回多实例——这三个地方卡住，再漂亮的负载均衡策略也跑不起来。
