gin 不支持服务发现，需手动集成 consul：注册须配置 check 和 deregistercriticalserviceafter，健康接口返回 200，服务发现需轮询 api 并动态更新上游。
Gin 本身不支持服务发现，必须靠外部库注册 + 手动调用 Consul API 实现服务注册与发现。 没有“一键集成”，所有关键逻辑（注册、健康检查、注销、服务拉取）都得自己写或封装。
注册服务时 AgentServiceRegistration 必须带 Check
Consul 默认只把注册的服务当静态条目，不自动做健康检查。没配 Check，服务即使挂了也会一直留在目录里，Gin 路由转发过去就 502。
-
HTTP字段要填完整可访问路径，比如"http://127.0.0.1:8080/health"，不能只写"/health" -
Interval建议设为"5s"或"10s"，太短会压垮 Consul，太长故障感知延迟高 -
DeregisterCriticalServiceAfter必须设（如"30s"），否则节点宕机后服务不会自动下线 -
ID必须全局唯一，推荐用"service-name-hostname-timestamp"格式，避免多实例注册冲突
健康检查接口 /health 要返回 200 且响应体可为空
Gin 的 GET /health 路由不能带重定向、不能返回非 2xx 状态码，Consul 会直接标记服务为 critical 并从服务列表剔除。
- 别用
c.Redirect或c.JSON(503, ...)—— 这些都会让 Consul 认为服务异常 - 建议只做轻量检查：DB 连接池 ping、内存阈值、goroutine 数量，不要查业务表或调下游
- 如果用了 gRPC 或其他协议暴露健康端点，Consul 的
HTTP检查不适用，得换TCP类型并配TLSSkipVerify: true（若用自签证书）
服务发现需主动轮询 /v1/health/service/{name} API
Gin 是 HTTP 框架，没有内置监听机制。想实现“动态上游”，你得自己起 goroutine 定期调 Consul 的健康服务列表接口，再更新本地缓存或重载路由逻辑。
- API 返回的是带节点信息的完整结构，关键字段是
Service.Address和Service.Port - 别直接信任
Node.Address—— 它可能和注册时填的Address不一致，优先用Service.Address - 轮询间隔建议 ≥
Interval的 2 倍（如检查间隔 10s，轮询设 20s），避免请求堆积 - 注意处理空结果：首次调用可能返回空数组，得 fallback 到静态配置或 panic 提前退出
consul/api 客户端初始化容易漏掉超时和重试
默认配置下，api.NewClient 的 HTTP client 没设超时，网络抖动时整个 Gin 启动卡住，或健康检查协程阻塞。
- 必须显式设置
config.HttpClient.Timeout = 5 * time.Second - 注册失败时别直接
panic，应记录 error 并重试 2–3 次（用指数退避），否则容器启动即失败 - Consul 地址写死在代码里风险高，建议从环境变量读取，如
os.Getenv("CONSUL_ADDR")，默认 fallback 到"127.0.0.1:8500" - 如果 Consul 启用了 ACL，
config.Token必须设，否则ServiceRegister返回 403
真正麻烦的不是注册这一步，而是怎么让 Gin 的反向代理或客户端调用感知到服务列表变化——你得自己维护一个线程安全的 service map，还要处理 DNS 缓存、连接复用、故障熔断。Consul 不推变更，只等你来拉，这个模型决定了它没法做到毫秒级同步。
