Consul服务发现失败90%源于网络配置错误而非代码问题：客户端地址错用localhost、服务注册ID非唯一、Address填127.0.0.1、健康检查路径不可达或未返回200；应使用环境变量或DNS配置Address，注册Singleton ConsulClient，缓存服务列表，Watch需Start()且单例管理。
Consul服务发现跑不起来，90%不是代码问题，而是客户端连错了地址或服务注册字段填错。
ConsulClient初始化必须显式指定Address
本地开发能通，一上Docker或K8s就报HttpRequestException或超时——八成是ConsulClient构造时用了"http://localhost:8500"。容器里localhost指向自己，根本连不到宿主机或Consul容器。
- 开发环境建议从环境变量读：
Environment.GetEnvironmentVariable("CONSUL_HTTP_ADDR") ?? "http://127.0.0.1:8500"（注意用127.0.0.1而非localhost） - Docker Compose场景下，
Address应设为Consul服务名，如http://consul:8500 - Kubernetes中通常填Service DNS：
http://consul-server.default.svc.cluster.local:8500 - 别在
Startup里每次请求都new一个ConsulClient，它本身是线程安全的，应注册为Singleton
服务注册时ID、Address、Check三处最容易填错
注册后Consul UI里看不到服务？点开Services标签页没列表？先检查这三项：
-
ID必须全局唯一：同一服务多个实例不能共用ID，推荐格式$"myapp-{Process.GetCurrentProcess().Id}-{DateTimeOffset.UtcNow.ToUnixTimeSeconds()}" -
Address必须填其他服务能访问到的真实IP或DNS名，绝不能是127.0.0.1或localhost；K8s中用Pod IP或Service name -
Check.HTTP路径必须真实存在、返回200且响应头含Content-Type: text/plain；比如http://10.244.1.5:5000/health，不是/api/health这种需要认证的路径
IHttpClientFactory封装服务发现调用才是正解
直接用HttpClient查Consul API发请求，等于把服务发现逻辑和HTTP调用耦死，还容易引发连接池耗尽、DNS缓存不更新等问题。
- 注册命名client：
services.AddHttpClient("consul-service-client") - 用
IConsulClient查服务实例时，只取ServiceEntry.Service.Address和ServiceEntry.Service.Port拼URL，别硬编码端口 - 服务列表必须缓存：用
MemoryCache存30秒，Key按服务名+数据中心生成，避免高频轮询拖垮Consul - 多实例场景下，别手动写轮询逻辑；优先用
LoadBalancer或Ocelot网关做负载分发，Consul只管提供健康列表
Watch监听必须单例启动且不能漏掉Start()
想实时感知服务上下线？光注册ConsulClient不够，Watch对象得自己Start()，否则监听根本不会触发。
-
Watch对象必须注册为Singleton，否则每次解析都新建一个，旧监听器被GC后就收不到事件 - 调用
Watch.KeyValuePrefix("config/")这类方法后，必须显式调用.Start()或.Wait()，否则只是个未激活的Task - Watch回调里别做耗时操作（如DB写入），建议发消息到
Channel或QueueBackgroundWorkItem异步处理 - Watch异常不会自动重试，需在回调里捕获
OperationCanceledException并重新Start()
Consul服务发现真正的复杂点不在API调用，而在网络拓扑与生命周期管理的对齐——容器网络、K8s Service DNS、Consul Agent模式、健康检查路径的可访问性，四者稍有错位，整个链路就静默失败。调试时优先抓包看GET /v1/health/service/myapp是否真能通，比翻C#代码快十倍。
