Kratos 通过 registry.Registrar 和 registry.Discovery 接口对接 Consul/Etcd/Nacos 等外部注册中心，需按机制配置健康检查、心跳续租与缓存策略；注册必须在 main.go 中通过 wire 注入 Registrar 并传给 kratos.App，Endpoints 填真实 IP，Discovery 返回实例列表后需自行实现负载均衡。
Kratos 本身不内置注册中心，而是通过 registry.Registrar 和 registry.Discovery 两个接口抽象服务注册与发现行为，具体实现交给 Consul、Etcd、Nacos 等外部组件。选型和接入方式直接决定服务能否被正确发现、健康状态是否及时同步、实例上下线是否可靠 —— 这些不是“配完就能用”的事，而是要对齐注册机制、心跳策略、客户端缓存行为。
怎么选注册中心：Consul / Etcd / Nacos 各自的关键差异
不是所有注册中心都适合你的场景，硬套会导致服务列表延迟、健康检查失灵、甚至请求打到已下线实例：
-
Consul：适合中小规模集群，自带 HTTP/TCP/gRPC 多种健康检查方式，但默认使用 blocking query 拉取服务列表，客户端需主动轮询或监听变更；consul.New()初始化时若未显式配置watch选项，Discovery 可能返回过期缓存 -
Etcd：强一致性 Raft，适合高可用要求严苛的场景，但健康检查依赖租约 TTL，服务进程必须定期续租（KeepAlive），否则实例会立即被剔除 —— Kratos 的etcd.New()默认不开启自动续租，需手动 wrap 或传入带 lease 的 client -
Nacos：AP 模式为主，支持客户端心跳和服务端探测双模式，但要注意nacos.New()构造时若未传入ClientConfig.NotLoadCacheAtStart = false，首次启动可能因本地缓存为空导致 Discovery 返回空列表
注册逻辑写在哪：main.go + wire 注入是关键路径
Kratos 不允许在业务逻辑里调用注册 API，必须通过 kratos.App 的 kratos.Registrar 选项统一接管。漏掉这步，服务就只是个裸跑进程，不会出现在任何注册中心里：
- 在
main.go的newApp()函数中，必须把registry.Registrar实例传给kratos.Registrar(r)，否则App.Run()不会触发注册 -
Registrar实例不能直接 new，得用wire注入 —— 因为它依赖配置（如 Consul 地址）、client 实例（如api.Client）、服务元数据（ID/Name）等，硬编码会导致测试难、环境切换麻烦 - 服务元数据中的
Endpoints字段必须填真实可访问地址，例如"10.244.1.5:9000"，不能写"localhost:9000"或"0.0.0.0:9000"，否则其他服务无法连接
服务发现失败的典型现象和排查点
常见报错不是“找不到注册中心”，而是静默失败或列表为空，原因往往藏在配置或生命周期里：
- 调用
discovery.GetInstances("user")返回空切片，先确认该服务名是否和ServiceInstance.Name完全一致（区分大小写、无空格） - gRPC 客户端 Dial 报
connection refused，检查Endpoints里的 IP 是否属于 Pod 网络段（K8s 环境下不能填 NodeIP） - 服务重启后旧实例仍被发现，大概率是注册中心没收到 Deregister 请求 —— 确保
App.Stop()被正常调用（如 SIGTERM 信号被捕获），且Registrar.Deregister()不被 panic 中断 - 使用 Istio 时，
ServiceEntry的hosts必须和 Kratos 服务注册的Name匹配，否则 Envoy 无法做服务网格路由
最易被忽略的是：Kratos 的 registry.Discovery 是只读接口，不负责负载均衡。拿到实例列表后，你要自己实现轮询、随机或一致性哈希 —— 框架不替你做这个决策，也没法替你做。
