结论：Consul适合Go项目开箱即用健康检查与多协议支持；etcd适合轻量KV协调，稳定低延迟；Nacos适合Java微服务生态对接，但Go客户端成熟度低。
Go 服务发现选型：Consul、etcd、Nacos 核心差异在哪？
直接说结论：如果项目已用 Go 写，且需要开箱即用的健康检查 + DNS/HTTP 多协议支持，Consul 最省心；如果只做轻量 KV 协调（比如 leader 选举、配置同步），etcd 更稳定低延迟；如果团队已有 Java 微服务生态、要对接 Spring Cloud Alibaba，Nacos 是现实选择——但 Go 客户端成熟度和文档质量明显弱于前两者。
Go 里连 Consul：别只调 consul-api，健康注册得自己埋点
github.com/hashicorp/consul/api 提供基础 client，但默认不自动上报健康状态。常见错误是只调 client.Agent().ServiceRegister() 就以为服务“活了”，结果 Consul 认为它 critical（因为没配 check）。
- 必须显式传入
Check字段，推荐用 HTTP 探针：HTTP: "http://localhost:8080/health" - Go 服务退出前要调
client.Agent().ServiceDeregister()，否则 Consul 里残留“僵尸服务” - 不要在
init()里注册——此时 HTTP server 可能还没 listen，健康检查立刻失败
etcd 做服务发现：本质是租约 + 目录监听，得自己实现服务列表缓存
etcd 没有“服务”概念，只有 key-value + lease。所谓“注册服务”，其实是往 /services/myapp/instance-123 写值，并绑定一个 10s 的 lease；客户端靠 Watch 目录变化来感知上下线。
- 必须定期
KeepAlive()续租，否则实例秒变“下线”——Go 客户端容易漏掉这个 goroutine - Watch 返回的是
WatchChan，需自己解析kv.Event.Type == mvccpb.PUT/DELETE来更新本地服务列表 - 没有内置健康检查，得额外起一个 HTTP 端点，由其他组件轮询（比如 Prometheus + Alertmanager）
Nacos Go SDK 坑多：v2 版本才支持 namespace 和鉴权，但文档几乎为零
官方 nacos-group/nacos-sdk-go v1.x 不支持 namespace 隔离，所有服务混在一起；v2.0+ 才补上，但示例代码全在 issue 里翻得到。
立即学习“go语言免费学习笔记（深入）”；
- 注册时必须显式设
GroupName，否则默认DEFAULT_GROUP，跨环境容易串 -
Subscribe接口返回的服务列表是全量快照，不是增量事件——每次变更都得自己 diff 差异 - 长连接心跳依赖
net/http默认 client，若服务启用了 TLS 双向认证，需手动传config.ClientConfig.TLSConfig
真正难的不是连上哪个后端，而是怎么让 Go 服务在节点宕机、网络分区、注册中心重启时，既不卡住请求，也不把流量打到已下线实例上——这些逻辑得自己在 RoundTripper 或服务调用层兜底。
