服务发现需确保注册中心稳定、健康检查准确、客户端及时刷新，否则流量打到下线或卡死实例；Consul注册必填Name、ID、Check三项；Health().Service()须设passingOnly=true；gRPC resolver需异步轮询并显式更新状态。
服务发现不是“配个地址就能用”，而是微服务存活的前提——注册中心没接稳、健康检查没写对、客户端没及时刷新，流量就会打到已下线或卡死的实例上，报 rpc error: code = Unavailable desc = connection closed 或持续超时。
serviceRegister 里这三个字段不填准出事
用 hashicorp/consul/api 注册服务时，api.AgentServiceRegistration 结构体中以下三项必须显式设置，缺一不可：
-
Name：服务名只能含字母、数字、短横线（-），不能有下划线（_），否则 Consul UI 不显示、API 查询也返回空 -
ID：必须全局唯一，建议拼成"order-service-$(hostname)-$(port)-$(unix-timestamp)"；重复 ID 会导致后注册覆盖前注册，出现“服务突然消失”现象 -
Check：必须带健康检查，别只写TTL: "10s"——那要求你的服务每 9 秒主动调一次client.Agent().PassTTL()，稍有 goroutine 泄漏或 GC STW 就会误注销；推荐改用 HTTP 检查：&api.AgentServiceCheck{HTTP: "http://localhost:8080/health", Interval: "5s", Timeout: "2s"}
Health().Service() 的 passingOnly 参数决定你是否真在做服务发现
查服务列表时，这行代码里的第三个参数不是可选项，而是生产环境生死线：
services, _, _ := client.Health().Service("order-service", "", false, nil)
其中 false 表示 passingOnly = false，即返回所有状态（passing、warning、critical）的实例。这意味着你的负载均衡器可能把请求发给一个数据库连不上、但端口还通着的“幽灵实例”。
立即学习“go语言免费学习笔记（深入）”；
正确做法是设为 true：
- 只拿
services中s.Checks.AggregatedStatus() == api.HealthPassing的节点 - 如果服务注册时加了 tag（如
Tags: []string{"v2"}），第二个参数可传"v2"过滤，避免灰度流量混入
别让 resolver 堵住整个 gRPC 连接池
用 gRPC-Go 做服务发现时，很多人直接套 dns:/// 或写个同步 HTTP 请求去查 Consul，结果一卡全卡——因为 resolver 的 Watch() 方法是阻塞调用，且 gRPC 默认不会自动重试或超时。
实操要点：
- resolver 必须异步轮询 + context 超时（比如
ctx, _ := context.WithTimeout(context.Background(), 3*s)） - 每次拿到新 endpoints 后，必须显式调
cc.UpdateState(resolver.State{Addresses: addrs})和cc.ResolveNow(resolver.ResolveNowOptions{})，否则连接池缓存旧地址，新实例上线后几分钟都收不到流量 - 禁止在 resolver 里做任何阻塞 IO（如没设 timeout 的
http.Get），否则整个 client 的所有 RPC 都 hang 住
最常被忽略的一点：健康检查接口（如 /health）必须真实反映业务可用性——它得校验 DB 连接、Redis 连通性、核心 handler 是否响应，而不仅是进程活着。否则注册中心认为“服务正常”，流量照打，结果全量 500 或超时。
