group是服务注册与发现时的匹配标签，用于逻辑级负载均衡隔离；需在注册、发现及客户端配置中显式一致指定，否则无法生效。
Hyperf服务发现里group参数到底起什么作用
Hyperf的consul或nacos服务发现客户端中，group不是命名空间隔离，而是注册/发现时的**匹配标签**。它不自动创建网络隔离，但能配合ServiceDiscoveryInterface筛选出指定分组的服务实例，是实现逻辑级负载均衡隔离的基础。
常见错误是以为设了group就天然“互不调用”，结果ServiceClient仍可能从其他分组拉取实例——因为默认没做分组过滤。
-
group只影响服务注册时写入注册中心的元数据字段（如Consul的Tags或Nacos的groupName） - 服务发现时必须显式传入
group参数，否则getNodes()默认查所有分组 - RPC客户端（如
JsonRpcHttpClient）不会自动读取当前服务的group，需手动配置
如何让JsonRpc客户端只调用同group服务
关键在JsonRpcPoolTransporter的nodes配置不能写死IP，而要动态走ServiceDiscovery并限定group。
在config/autoload/services.php中：
'jsonrpc' => [
'transporter' => Hyperf\JsonRpc\Transporter\JsonRpcPoolTransporter::class,
'nodes' => [
// 不要在这里填具体地址
// 而是留空，靠discoverer动态填充
],
'discoverer' => [
'mode' => Hyperf\ServiceGovernance\Discoverer::MODE_PULL,
'group' => 'payment-v1', // ← 必须显式指定
'namespace' => 'default',
],
],
同时确保被调用方（Provider）注册时也带相同group：
// config/autoload/services.php
'service' => [
'name' => 'payment_service',
'group' => 'payment-v1', // ← 两端group必须一致
],
Consul注册中心下group实际存成Tag还是Metadata
Hyperf 3.x 默认把group写入Consul的Tags数组，不是Meta。这意味着：
- 你在Consul UI里看到的是
Tags: ["group=payment-v1"]，不是单独字段 - 自定义
ConsulDriver扩展时，如果重写了register()，别误删Tags里的group=xxx - 用
curl直接查Consul API时，得解析Node.Tags而不是Node.Meta
验证方式：curl http://localhost:8500/v1/health/service/payment_service?passing，看返回JSON中Service.Tags是否含group=xxx。
多个group共存时，RPC调用失败却没报错的原因
最常踩的坑：某服务同时注册了group=order-v1和group=order-v2（比如本地开发误启两个进程），但客户端只配了v1，结果getNodes()返回空数组，JsonRpcPoolTransporter因无可用节点，会静默fallback到failover策略——若没配failover，就直接抛Hyperf\Rpc\Exception\NoAvailableNodeException；若配了，反而可能调到错误分组，且日志里只有WARN级别提示。
- 检查手段：在
ServiceDiscoveryInterface::getNodes()调用前后加日志，确认返回数量 - 推荐做法：在
beforeInvoke事件里校验$node['group'] === $expectedGroup - 生产环境务必禁用
failover，避免跨group兜底
分组隔离真正生效的前提，是注册、发现、调用三方的group值完全一致，且中间链路不被任何兜底逻辑绕过。漏掉任意一环，隔离就形同虚设。
