beego框架本身不内置服务发现能力，集成consul必须手动调用consul/api客户端完成注册与查询；不显式配置健康检查，服务在consul中会立即被标记为critical，根本不可用。
Beego 框架本身不内置服务发现能力，集成 Consul 必须手动调用 consul/api 客户端完成注册与查询；不显式配置健康检查，服务在 Consul 中会立即被标记为 critical，根本不可用。
注册服务时必须带 Check 字段，否则状态永远是 critical
Beego 启动后只是个 HTTP 服务，Consul 不知道它是否真能响应请求。你得主动告诉 Consul “怎么判断这个实例还活着”。
常见错误现象：consul members 显示服务在线，但 consul health service user-service 返回 critical，调用方查不到实例。
实操建议：
- 注册时
AgentServiceRegistration.Check字段不能为 nil，至少填一个HTTP+Interval -
HTTP地址必须是 Consul 能访问到的路径，比如http://host.docker.internal:8080/health（容器内）或http://172.17.0.1:8080/health（避免用 localhost） -
Timeout建议 ≤Interval的 1/3，否则容易误判超时 - 别漏掉
DeregisterCriticalServiceAfter，否则进程崩溃后实例不会自动清理
客户端查服务必须加 PassingOnly: true
Beego 作为服务消费者时，如果直接调 api.Health().Service 不传参数，可能拿到 passing、warning、critical 混合结果，甚至包含已下线但未 deregister 的脏数据。
使用场景：你在 controllers 里写了个 callUserService() 方法，底层用 http.Get 转发，地址从 Consul 拿——这时候错一条就 502。
实操建议：
- 查服务列表务必显式传
&api.QueryOptions{AllowStale: false, RequireConsistent: true}和PassingOnly: true - 不要每次调用都查 Consul，应在启动时初始化一个本地缓存（如
map[string][]*api.ServiceEntry），配合 goroutine 定期刷新（比如 10s 一次） - 缓存更新失败时，保留旧数据并打 warning 日志，别 panic 或阻塞主流程
Beego 启动时机要和 Consul 注册对齐
Beego 默认在 beego.Run() 才真正监听端口，但很多开发者在 init() 或 main() 开头就调注册逻辑——此时服务还没 ready，Consul 健康检查立刻失败，实例反复上下线。
容易踩的坑：日志里看到 CheckID: service:user-service-1, Status: critical, Notes: Get \"http://.../health\": dial tcp ...:8080: connect: connection refused。
实操建议：
- 注册逻辑必须放在
beego.Run()之后，或者用beego.BeeApp.Server.Started()钩子（v2.x 支持） - 更稳妥的做法：启动一个 goroutine，循环尝试
http.Get("http://localhost:8080/health")直到返回 200，再执行 Consul 注册 - 注册失败时重试最多 3 次，间隔 1s，超时则 log.Fatal，别让服务“假启动”
Consul DNS 在 Beego 容器化部署中不能直接用 net.LookupHost
很多人想省事，直接在 Beego 里写 net.LookupHost("user-service.service.consul")，但在 Docker 网络里这会失败——因为容器默认没配 Consul 的 DNS resolver。
性能影响：即使配了，DNS 查询比直接 HTTP API 多一层解析开销，且无连接池、无超时控制，容易拖慢整个请求链路。
实操建议：
- 禁用所有
net.LookupHost方式，统一走api.Health().Service()API 查询 - 若坚持用 DNS，必须在
docker run时加--dns=172.17.0.1（Consul agent IP），并在容器内安装resolvconf工具动态更新/etc/resolv.conf - Beego 的
http.Client应复用，别每次请求都 new，尤其在高频服务发现场景下
最常被忽略的一点：Beego 的 config 模块加载顺序早于 Consul 初始化，所以所有依赖服务地址的配置（比如数据库连接串里的 host）不能硬编码成 Consul DNS 名，得等注册成功后再动态 set。否则启动就 panic。
