Consul和etcd是Golang微服务中真正能落地的服务发现方案，Consul需显式配置健康检查参数（Timeout、Interval、DeregisterCriticalServiceAfter），etcd依赖租约续期逻辑且必须自行实现Watch；Kubernetes环境下应优先使用Service DNS而非硬连外部注册中心。
Consul 和 etcd 是 Golang 微服务中真正能落地的服务发现方案，其他如 zookeeper 运维成本高、mdns 仅限本地调试，生产环境基本不用。
Consul 适合多数业务场景，但健康检查参数必须显式设对
Consul 不是“注册完就自动健康”，它的健康状态由你配的 AgentServiceCheck 决定。常见错误是只填了 HTTP 路径，却忽略 Timeout 和 Interval：
-
Timeout必须 > 你的/healthhandler 实际耗时，否则 Consul 会反复标记为critical -
Interval建议 ≥ 5s；太短（如 1s）会给 Consul agent 带来压力，且无实际意义 -
DeregisterCriticalServiceAfter别用默认"1m"，设成"30s"更稳妥——网络抖动时不会立刻剔除，也不会挂太久 - 注册前务必确认
consul agent已启动且可连通，ServiceRegister()静默失败不报错
etcd 更轻量，但租约续期逻辑必须自己写全
etcd 没有内置健康检查语义，一切靠 lease 维持。注册后服务“突然消失”，90% 是因为租约没续上：
- 必须调
clientv3.Lease.Grant()获取lease ID，再用clientv3.WithLease()绑定 key - 必须另起 goroutine 调
Lease.KeepAlive()，不能只调一次；context不能提前 cancel，否则通道关闭续租就停了 -
TTL建议 ≥ 10s，续租间隔 ≤TTL/2（比如 TTL=10s，每 4s 续一次） - 别在
main()里注册完立刻http.ListenAndServe，加time.Sleep(100 * time.Millisecond)确保注册请求发出去
gRPC 客户端必须实现 Watch，否则服务增减完全无感知
gRPC 自身不拉取服务列表，靠 resolver.Builder 注入解析器。只实现 Build 和首次 ResolveNow 是不够的：
立即学习“go语言免费学习笔记（深入）”；
- 必须在
Build返回的resolver.Resolver中启动Watch（如 Consul 用client.Health().ServicePrefix+Wait，etcd 用client.Watch()） -
UpdateState推送地址时，别直接塞全量Addresses；gRPC 默认轮询会对相同IP:port去重，重复推送会导致连接风暴 - 初始化
grpc.ClientConn时必须传grpc.WithResolvers()，否则自定义 resolver 根本不生效 - 频繁全量推送地址会触发 gRPC 内部重建连接，建议只推 diff 或加节流（如 1s 内最多更新一次）
Kubernetes 环境下别自己连 Consul/etcd
如果你的服务跑在 K8s 里，硬编码 consul.NewClient 或 clientv3.New 是冗余且危险的：
- 应直接用
my-svc.default.svc.cluster.local这类 Service DNS，KubeDNS 会自动解析到稳定 ClusterIP - 需要感知后端实例变化？用
client-go监听Endpoints资源，比轮询注册中心更准、更轻量 - StatefulSet 场景下若需区分实例，用 headless Service + DNS SRV 记录，而非拼 IP 注册
- Pod IP 不稳定，永远不要在代码里硬写
10.244.x.x或容器内网 IP
真实项目里最常被忽略的点是：服务注册和发现不是“一次配置，永久有效”。Consul 的健康检查超时、etcd 的租约续期中断、gRPC 解析器没 Watch、K8s 里还硬连外部注册中心——这些都不是配置问题，而是运行时行为没闭环。
