服务发现客户端必须封装租约与自动续租逻辑，否则易致注册后迅速消失；etcd需用clientv3.keepalive持续续租，consul需真实健康检查端点配合interval；应统一抽象接口屏蔽底层差异。
服务发现客户端必须封装租约与自动续租逻辑
不封装租约管理的客户端，上线后大概率出现“服务注册了但很快消失”的问题。etcd 的 Lease 和 Consul 的 Check 都依赖持续心跳，而裸调用客户端 API 很容易漏掉续租或健康上报。
- etcd 场景下，必须用
clientv3.KeepAlive启动 goroutine 持续监听续租响应流，不能只调一次Grant就完事 - Consul 场景下，
DeregisterCriticalServiceAfter是兜底机制，但真正可靠的是 HTTP/TCP 健康检查端点 +Interval，且该端点必须真实返回 200 - 建议把租约 ID 或服务 ID 作为结构体字段存入客户端实例，避免多处引用导致续租错乱
- 续租失败时应触发本地注销（如调
client.Agent().ServiceDeregister），否则注册中心残留僵尸节点
统一接口要屏蔽 etcd 与 Consul 的差异
直接暴露两个 client 实例给上层业务，等于把协议细节和错误处理甩给每个调用方。统一客户端的核心不是“能连两种注册中心”，而是让业务代码完全感知不到底层是 etcd 还是 Consul。
- 定义抽象接口如
Register(service *ServiceInfo) error和Watch(serviceName string) ，不暴露 <code>clientv3.Client或consulapi.Client - 服务信息结构体（
ServiceInfo）字段需兼顾两者：比如Address、Port、Tags是共有的；TTL（etcd）和Check.HTTP（Consul）则由实现层按需映射 - 错误统一转换：把
context.DeadlineExceeded、rpc.Error、consulapi.QueryMeta等底层错误转为自定义错误类型如ErrRegistrationFailed，避免上层用字符串匹配判断 - 初始化时通过配置项（如
registry.type=etcd）决定实例化哪个具体实现，而非硬编码 switch 分支
Watch 机制必须带本地缓存与事件去重
直接把 client.Watch 或 client.Agent().Services() 返回的原始结果透传给业务，会引发频繁重建连接、重复更新负载均衡器、goroutine 泄漏等问题。
- etcd 的
Watch流可能因网络抖动重连，导致同一变更被推送两次；Consul 的Watch在 long poll 超时后也会重复返回全量列表 - 必须在客户端内部维护一个内存 map（如
map[string][]*Instance），每次更新前比对版本号或 checksum，仅当实际变化才通知上层 - 提供
GetInstances(serviceName string)同步读取方法，让业务能安全获取当前快照，避免竞态访问 watch channel - watch channel 应设缓冲（如
make(chan []*Instance, 16)），防止消费者阻塞导致注册中心连接被断开
退出时必须主动注销并等待确认
进程收到 SIGTERM 后直接退出，注册中心里服务条目不会立刻消失——etcd 等待租约过期（最长 TTL），Consul 等待健康检查超时（最长 DeregisterCriticalServiceAfter）。这期间流量仍会被路由到已死实例。
- 注册成功后，应将注销逻辑绑定到
os.Interrupt或syscall.SIGTERM信号处理中 - etcd 注销需调
client.Delete(ctx, key)并等待响应；Consul 必须调client.Agent().ServiceDeregister(id)，不能只靠租约到期 - 注销操作应设超时（如 3 秒），超时后记录 warn 日志但不 panic——毕竟进程终将退出，强一致性不如可用性重要
- 建议在注销前先关闭监听端口、拒绝新请求（如 HTTP server 的
Shutdown()），再执行注销，形成完整优雅退出链
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
