必须等服务监听就绪再注册：确认net.Listen成功且/health返回200后调用RegisterService；客户端需重写ResolveNow主动刷新列表；Consul需设WaitTime防轮询，etcd须绑定Lease防幽灵节点；空发现结果应降级+本地缓存兜底。
服务注册必须等监听就绪再触发
很多团队在 TarsGo 服务启动时直接调用 RegisterService，结果注册中心记录了一个“假在线”实例：gRPC 还没开始 server.Serve(lis)，HTTP /health 接口也未响应，下游一拉取就调用失败。
正确做法是显式等待服务真正可接受连接：
- 确认
lis, err := net.Listen("tcp", ":8080")成功且err == nil - 若启用了 HTTP 健康检查，先用
http.Get("http://localhost:8080/health")验证返回200 - 再调用
tars.RegisterService(...)，避免注册中心缓存不可用地址
TarsGo 客户端 resolver 必须实现 ResolveNow
当后端服务实例宕机或网络抖动时，TarsGo 客户端默认不会主动刷新服务列表，而是继续向已失效 endpoint 发起请求，直到超时——这会放大延迟、拖垮调用方。
resolver 是关键干预点，必须重写 ResolveNow() 方法：
立即学习“go语言免费学习笔记（深入）”；
- 在连接断开（如
conn.Close()或context.DeadlineExceeded）时主动触发重新发现 - 不要依赖下一次
dial自动重试，那是被动行为 - 配合本地缓存（
sync.Map存最近 30 秒有效 endpoints），避免每次调用都查注册中心
选 Consul 还是 etcd？看事件模型是否匹配
TarsGo 对注册中心的适配不是“插上就能用”，Consul 的阻塞查询（WaitTime）和 etcd 的 watch 租约机制差异很大，直接影响失效感知速度。
实际部署中容易踩坑：
- 用 Consul 时，
Health.Service调用必须显式传WaitTime: 5 * time.Second，否则变成轮询，压垮注册中心 - 用 etcd 时，
registry模块必须绑定Lease，不能写裸 key；否则进程崩溃后实例不自动注销，留下“幽灵节点” - Consul 的
DeregisterCriticalServiceAfter="30s"必须大于健康检查间隔（如设为"10s"），否则网络抖动导致误删
本地缓存 + 降级兜底是容错底线
注册中心集群故障、跨 DC 同步延迟、ACL 权限未生效……这些场景下，tars.Discover 返回空切片是常态，不是 bug。硬编码 panic 或重试三次就放弃，会引发雪崩。
必须设计两级容错：
- 首次发现失败或返回空列表时，fallback 到预设降级地址（如
"localhost:8081"），仅用于开发或紧急恢复 - 本地缓存使用
sync.Map存最近 30 秒内有效的 endpoints，缓存过期时间需略大于注册中心心跳周期 - 调用前检查 endpoint 是否在缓存中，不在则走发现逻辑；发现仍失败，才走降级路径
高可用不靠单点健壮，靠的是注册、发现、缓存、降级四层漏斗——任何一层断裂，都不该让业务直接报错。最易被忽略的是本地缓存 TTL 和降级地址的维护成本：缓存过期太短，频繁查注册中心；太长，故障实例残留；降级地址若长期不用，很可能配置已失效。
