Consul.Client.GetHealthService返回空列表主因是服务未注册成功或健康检查失败，仅返回Passing状态实例；需检查注册名、健康检查配置、数据中心、客户端配置及服务IP地址等。
consul.Client.GetHealthService 返回空列表？检查服务注册状态和健康检查
查不到服务实例，八成不是 Go 代码写错了，而是 Consul 里压根没注册成功，或者健康检查失败了。Consul 的 GetHealthService 只返回 Passing 状态的实例，Critical 或 Warning 都会被过滤掉。
- 用
curl http://localhost:8500/v1/health/service/my-service?passing直接调 Consul HTTP API 确认结果，绕过 Go 客户端干扰 - 确认服务注册时填了正确的
Service.Name，且没带多余空格或大小写混淆（Consul 默认区分大小写） - 检查服务注册里是否配置了
Checks，比如 TCP 或 HTTP 健康检查地址写错、端口不通、超时时间太短，都会导致状态卡在Critical - Go 客户端初始化时没设
consul.DefaultConfig()也可能连错数据中心，默认是dc1，而你的服务注册在dc2
用 consulapi 包还是 hashicorp/consul/api？选后者
别用已归档的 consulapi（github.com/cablespaghetti/consulapi），它不维护了，HTTP client 没做连接复用，高并发下容易耗尽文件描述符。官方 hashicorp/consul/api 是唯一推荐路径。
- 初始化客户端时显式传入
config.Address，别依赖默认值，尤其在容器或 Kubernetes 里，Consul Agent 地址往往不是localhost:8500 - 设置
config.HttpClient.Timeout，默认 0 会无限等待，线上必须设（比如5 * time.Second） -
api.NewClient(config)不校验连接可用性，第一次client.Health().Service(...)才真正发请求，错误得在调用处捕获
服务实例 IP 是 127.0.0.1？改用 Node.Address 或服务注册时指定 LAN IP
本地跑 demo 没问题，一上生产就发现所有实例 IP 都是 127.0.0.1，根本连不通——这是因为服务注册时没填 Service.Address，Consul 自动 fallback 到所在节点的 Node.Address，而 Agent 配置里这个值常是 127.0.0.1。
- 启动 Consul Agent 时加
-bind=真实内网IP（如consul agent -server -bind=10.0.1.100 ...） - 服务注册代码里显式写
Address: "10.0.1.101"，别依赖自动推导 - 如果用的是 Kubernetes，考虑用 Downward API 注入 Pod IP，再塞进
Service.Address - 实在不行，退一步读
service.Node.Address+service.Service.Port拼地址，但注意这假设服务和 Consul Agent 在同一节点
频繁轮询 /v1/health/service 导致 Consul 压力大？用 blocking query + TTL 缓存
每秒查一次服务列表，Consul HTTP 接口很快扛不住。Blocking query 能让请求挂起直到数据变更，配合客户端本地缓存，才是合理做法。
立即学习“go语言免费学习笔记（深入）”；
- 调
client.Health().Service时传api.QueryOptions{WaitTime: 5 * time.Minute, RequireConsistent: true} - 响应里的
X-Consul-Index要保存下来，下次请求带上WaitIndex，否则变轮询 - 本地缓存建议加 TTL（比如 30 秒），防止 blocking 失败后长时间用旧数据
- 别在 goroutine 里无限制启新查询，用单个长连接 + channel 分发更新更稳
服务发现不是“查一次够用”，关键在怎么应对动态变化。Index、TTL、健康状态三者漏掉任何一个，都可能让流量打到已下线的实例上。
