Consul服务注册必须显式声明健康检查类型，否则状态恒为critical；需明确配置HTTP、TCP、Script或TTL之一，不可仅设Timeout/Interval，且HTTP须用完整URL、返回2xx状态码。
Consul 服务注册时必须显式声明健康检查类型
Go 程序向 Consul 注册服务时，Check 字段不能留空或仅填超时时间——Consul 不会自动 fallback 到默认 TCP 或 HTTP 检查。必须明确指定 HTTP、TCP、Script 或 TTL 类型之一，否则注册成功但健康状态始终为 critical。
常见错误是只写 Timeout 和 Interval，漏掉 HTTP 或 TCP 字段：
// ❌ 错误：缺少检查类型，Consul 认为无健康检查
Check: &api.AgentServiceCheck{
Timeout: "5s",
Interval: "10s",
}正确做法是根据服务暴露方式选择：
- HTTP 服务：填
HTTP（含完整 URL，如"http://localhost:8080/health"） - TCP 端口监听：填
TCP（格式为"localhost:8080"） - 自定义逻辑（如 DB 连通性）：用
Script+ 本地脚本，或改用TTL主动上报
使用 TTL 类型需手动调用 Pass / Fail / Warn 接口
TTL 是唯一需要 Go 程序主动维护健康状态的类型。Consul 不轮询，而是依赖服务端定期调用 /v1/agent/check/pass/xxx 等接口“续命”。一旦停止上报，TTL 超时后状态自动变 critical。
实操要点：
- 注册时设置
TTL（如"30s"），并确保ID唯一且与后续上报一致 - 用 goroutine 启动定时器，每
TTL/2左右调用一次client.Agent().PassTTL() - 检查失败时调用
FailTTL()，避免带病服务继续被发现 - 注意
PassTTL()第二个参数是可选的注释，不传则清空上次失败信息
示例片段：
go func() {
ticker := time.NewTicker(15 * time.Second)
defer ticker.Stop()
for range ticker.C {
if isHealthy() {
client.Agent().PassTTL("service:myapp", "")
} else {
client.Agent().FailTTL("service:myapp", "db unreachable")
}
}
}()HTTP 健康检查路径返回非 2xx 状态码即视为失败
Consul 对 HTTP 类型检查非常严格：只要响应状态码不是 2xx（如返回 404、503、甚至 302），就标记为 critical，不会读取 body 内容做进一步判断。
这意味着：
- 不要把
/health实现成重定向（3xx）或权限校验页（401/403） - 避免依赖中间件注入的全局状态码（如 Gin 的
c.AbortWithStatus(503)） - 推荐返回
200 OK并在 body 中放 JSON（如{"status":"pass"}），用于人工排查，但 Consul 不解析它 - 如果服务启用了 HTTPS，Consul 默认不校验证书；若需校验，得在
HTTPURL 前加https://并确保 Consul agent 能访问该证书链
服务注销时未 deregister check 可能残留僵尸检查项
Go 程序退出前调用 client.Agent().ServiceDeregister(serviceID) 只删除服务本身，不自动清理关联的 Check。若注册时用了随机 ID 或未指定 Check.ID，Consul 会生成一个内部 ID（如 service:myapp:1），但你无法在下线时准确引用它。
规避方法只有两个：
- 注册时**显式设置
Check.ID**（如"check:myapp:http"），下线前先调用client.Agent().CheckDeregister(checkID) - 或干脆不手动 deregister，依赖 Consul 的
TTL自动过期（适合短生命周期服务）
遗留检查项虽不影响服务发现，但会在 UI 和 API 中持续显示为 critical，干扰运维判断。
真正麻烦的是跨节点部署时——不同实例可能注册了同名但不同 ID 的检查，手工清理极易出错。所以从一开始就在 Check.ID 上保持确定性，比事后补救更可靠。
