Consul是Go微服务最常选的注册中心，因其开箱即用的HTTP/TCP/TTL健康检查可自动剔除故障实例；集成时须显式配置Check字段，否则实例被标记为critical，且查询需设PassingOnly: true以避免脏数据。
Go 微服务要真正跑起来，光有 gin 或 echo 不够——服务一多，调用方根本不知道该连哪个实例。集成服务发现不是“锦上添花”，而是避免硬编码地址、实现自动扩缩容和故障转移的刚性需求。
Consul 集成：开箱即用的健康检查最省心
Consul 是 Go 生态里最常被默认选中的注册中心，原因很实在：它自带 HTTP/TCP/TTL 多种健康检查方式，服务挂了不用你写逻辑，Consul 自己就从目录里剔除。
- 注册时必须传
Check字段（比如HTTP路径 +Timeout），否则即使服务注册成功，也会因无健康检查而被标记为critical - 客户端查服务时，
api.Health().Service默认只返回Passing状态实例；若漏掉PassingOnly: true参数，可能拿到已下线但未清理的脏数据 - Consul DNS 接口（如
todo-service.service.consul）在容器环境里需确保consul-template或dnsmasq配合，直接net.LookupHost会失败
etcd 集成：强一致性场景下必须自己管租约
etcd 不提供内置健康检查，所有“服务还活着”的判断都依赖客户端维持租约（lease）。这意味着注册代码里必须显式启动心跳 goroutine，否则服务一重启或网络抖动，租约过期，实例就从目录消失。
- 注册时用
clientv3.Put写入服务节点信息，LeaseID必须和clientv3.KeepAlive返回的 channel 绑定，否则无法续期 -
clientv3.Watch监听服务变更时，需处理ctx.Done()和ErrCompacted错误，否则 watch 可能静默中断且不重连 - etcd 的
Get操作默认不带Serializable选项，高并发查询服务列表时可能读到旧数据；生产环境建议显式加WithSerializable()
go-micro / go-kit 这类框架的 registry 抽象层真能屏蔽差异？
不能完全屏蔽，尤其在错误处理和重试逻辑上。比如 micro/registry/consul 和 micro/registry/etcd 的 Watch 方法返回的 Watcher 接口行为就不一致：Consul 实现会在连接断开后自动重试并补发事件，etcd 实现则需要你手动重建 watcher 并处理历史事件丢失。
立即学习“go语言免费学习笔记（深入）”；
- 用
go-micro时，别直接依赖registry.GetService单次调用——它不保证返回最新列表；应结合registry.Watch+ 本地缓存做兜底 -
go-kit的sd/consul包里，Instancer初始化时若 Consul 不可用，会 panic 而非返回 error；必须在外层加time.AfterFunc延迟初始化，避免启动失败 - 所有框架的 registry 客户端默认超时都是 5 秒，但在 K8s Service Mesh 场景下，etcd 集群跨 AZ 访问延迟可能超过此值，需显式调大
context.WithTimeout
Nacos 集成：Java 生态友好但 Go SDK 文档稀疏
Nacos 对 Go 支持靠的是社区 SDK（nacos-group/nacos-sdk-go），它不像 Consul 官方 client 那样成熟，很多边界情况得看源码才能确认。
- 服务注册时，
vo.RegisterInstanceParam的ClusterName字段为空会导致注册失败且错误信息是"invalid cluster name"，但文档没写这是必填项 - Nacos 的
Subscribe不支持像 etcd 那样的 long polling，watch 是基于定时轮询实现的，默认间隔 10 秒；高频变更场景下容易丢事件 - SDK 的
config_client和naming_client使用同一套ClientConfig，但后者不读取NamespaceId字段——必须手动在RegisterInstanceParam里重复传一遍
服务发现不是配个地址就能跑通的事。Consul 的“自动”背后要填健康检查参数坑，etcd 的“强一致”代价是租约管理代码量翻倍，框架抽象层省了初始化代码，却把重连、事件丢失、缓存同步这些复杂度悄悄转嫁给了业务逻辑。上线前务必用 kill -9 模拟服务崩溃，看消费者能否在 5 秒内感知到实例下线——这才是集成是否落地的唯一标尺。
