grpc.dial 使用 consul:// 协议时必须携带 ?wait=10s–15s 参数，否则因异步发现未就绪导致连接失败；需显式配置 round_robin 负载均衡策略，服务名须与 consul 注册完全一致，健康检查失败后客户端存在缓存滞后。
gRPC.Dial 的 consul:// 协议必须带 wait 参数
不加 ?wait=14s 这类参数，grpc.Dial 会立即返回空列表或报错 rpc error: code = Unavailable desc = connection closed before server preface received。Consul 的服务发现是异步拉取的，gRPC 客户端默认不等待注册中心返回实例，直接建连失败。
实际使用中，wait 值建议设为 10–15 秒：太短（如 ?wait=1s）容易错过刚注册的实例；太长（如 ?wait=60s）会导致服务启动卡住，尤其在 Consul 集群响应慢时。
-
consul://127.0.0.1:8500/user-srv?wait=14s是有效格式 -
consul://127.0.0.1:8500/user-srv（无参数）大概率连不上 - 如果 Consul 启用了 ACL，还需额外加
&token=xxx
round_robin 负载均衡策略必须显式启用
gRPC 默认不开启负载均衡，即使你传了多个服务地址，它也只会用第一个连接——这和 HTTP 客户端行为完全不同。必须通过 grpc.WithDefaultServiceConfig 显式声明策略，否则轮询不会生效。
常见错误是只写了 grpc.WithInsecure() 就以为够了，结果所有请求都打到同一个实例上，健康检查和扩缩容形同虚设。
- 正确写法：
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy": "round_robin"}`) - 注意 JSON 字符串必须是单行、双引号、无换行，否则
grpc.Dial解析失败静默降级 - 别用
pick_first或留空，那是 gRPC v1.26 以前的默认策略，已弃用
Consul 服务名必须与注册时完全一致（含大小写和连字符）
服务注册时写的是 user-service，但客户端连的是 user_service 或 userservice，grpc.Dial 会查不到任何实例，且不报错，只返回空连接池——这是最隐蔽的坑之一。
验证方式很简单：直接 curl Consul HTTP API：curl "http://127.0.0.1:8500/v1/health/service/user-service"。如果返回空数组，先确认服务是否真正在运行并成功注册，而不是假设“应该有”。
- 注册代码里用的
service.Name = "user-service" - 客户端 dial 字符串里也必须是
"user-service" - Consul UI 中 Services 列表显示的名字，就是你要填的值
健康检查失败会导致实例被自动剔除，但客户端缓存可能滞后
Consul 检测到某个 gRPC 实例进程还在、但健康检查失败（比如 /health 接口超时或返回非 200），会把它从服务列表中移除。但 gRPC 客户端本地缓存的连接可能还在，导致短暂时间内继续往故障节点发请求。
这不是 bug，而是最终一致性模型下的正常现象。缓解方式只有两个：缩短健康检查间隔（Consul 端），以及在客户端加重试逻辑（Gin 层）。
- Consul 侧建议把
interval设为10s，timeout不超过3s - Gin 调用 gRPC 时，别裸调
client.GetUser，套一层带重试的封装 - 不要依赖 gRPC 自动重连——它只对连接断开有效，对服务端返回 ERROR_CODE 不重试
grpc.Dial 初始化那一刻；轮询是否生效，不取决于你写了多少中间件，而取决于那行字符串里协议、参数、服务名有没有一个字符出错。
