Gin 服务注册需显式调用 consul.Agent.ServiceRegister，必须在 r.Run() 前完成；ID 需唯一，健康检查必配；配置监听应使用长轮询而非定时 GET；注册与监听须分离 client 超时设置。
服务注册必须显式调用 consul.Agent.ServiceRegister
Gin 本身不提供服务注册能力，它只是 HTTP 框架。注册动作必须由你主动触发，通常在 main.go 启动后、r.Run() 前完成。常见错误是把注册逻辑写在中间件里，或误以为 Gin 启动即自动注册——这会导致 Consul 中查不到服务。
关键点：
-
consul.Agent.ServiceRegister需要完整的服务定义结构体，其中Name、ID、Address、Port四个字段不能为空；ID必须全局唯一，建议拼接主机名+端口，避免多实例冲突 - 健康检查不是可选的：不配置
Check字段，Consul 默认认为服务“不健康”，状态会卡在critical；推荐用 HTTP 类型检查，指向 Gin 的一个轻量 endpoint（如/health） - 注册失败不会阻断 Gin 启动，但日志里会有
Unexpected response code: 500或连接拒绝，需检查 Consul Agent 是否运行（curl http://127.0.0.1:8500/v1/status/leader应返回 leader 地址）
动态配置不能只靠 Consul KV 轮询
Consul KV 存储本身不推配置变更，Gin 应用若想实时响应配置更新（比如数据库超时、限流阈值），必须自己实现监听机制。直接定时 GET /v1/kv/config/app 是低效且易漏的。
更可靠的做法是使用 consulapi.KV.List 的 WaitIndex 参数做长轮询：
- 首次请求带
?wait=60s和当前Index，Consul 会挂起连接直到有变更或超时 - 收到响应后解析新值，并立即发起下一轮带新
Index的请求 - 不要在 Gin 的 HTTP handler 里做这个轮询——应放在独立 goroutine，变更后通过 channel 或原子变量通知业务逻辑
- 注意 KV 值是
[]byte，需手动 JSON 解析；若值为空（nil），代表 key 不存在，不应 panic
注册与配置共用一个 Consul client 实例，但要分离超时设置
同一个 *consulapi.Client 可同时用于注册和服务发现、KV 读写，但注册操作（写）和配置监听（长连接）对网络稳定性要求不同。
必须分开配置：
- 注册用的 client：
WriteTimeout设为 3~5 秒足够，超时可重试 - 配置监听用的 client：
WaitTime设为 60 秒，MaxWaitTime不宜过长，否则变更延迟高；HttpClient.Timeout必须大于WaitTime，否则连接会被 Go 标准库提前关闭 - 别复用
http.DefaultClient，它可能被其他库修改，导致超时行为不可控
Gin 的路由和中间件无法直接感知服务发现结果
Consul 返回的服务地址列表（如 usersrv 的多个 IP+Port）不能直接塞进 Gin 的 router.GET。Gin 不是服务网格，它不处理下游服务寻址。
真实场景中，你要自己封装调用逻辑：
- 用
consul.Health.Service获取健康实例列表，再用selector.RoundRobin或随机选取一个 - 拿到地址后，用
grpc.Dial连 gRPC 服务，或用http.NewRequest构造 HTTP 请求 - 别把服务发现逻辑写在每个 handler 里——应封装成统一的 client，比如
userClient.GetUser(ctx, id)，内部自动完成发现+重试+熔断 - 如果用了
gin-contrib/cors等中间件，注意它们和 Consul 注册无关，别混淆“API 网关跨域”和“服务间发现”两个层级
Consul 的服务注册是单次写入动作，而配置监听是持续性长连接，两者生命周期、错误恢复策略、超时设置完全不同。混用同一套 client 配置或共享 goroutine 容易导致注册失败静默、配置更新卡死、甚至整个 Gin 服务启动 hang 住。
