健康检查接口必须暴露 /health 且返回 200，需同步探测数据库、Redis、下游HTTP等关键依赖并设超时，/health 与 /ready 必须分离，同时通过 Prometheus 暴露多维健康指标。
健康检查接口必须暴露 /health 且返回 200
绝大多数服务发现组件（Consul、Eureka、Kubernetes liveness probe）默认只认 /health 或 /healthz，且严格依赖 HTTP 状态码——不是 200 就判定为不健康。Golang 中用 http.HandleFunc 注册时别写成 /health/（末尾斜杠），K8s 的 probe 默认不带尾部斜杠，匹配失败直接标记为 CrashLoopBackOff。
最简可行实现：
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
json.NewEncoder(w).Encode(map[string]string{"status": "ok", "timestamp": time.Now().UTC().Format(time.RFC3339)})
})
注意：w.WriteHeader 必须在 json.NewEncoder 之前调用，否则 Go 的 http.ResponseWriter 会自动补 200，掩盖你本意是返回 503 的场景。
依赖服务连通性要主动探测，不能只看自身 goroutine
常见误区是健康接口只返回 {"status":"ok"}，但数据库连接已断、下游 gRPC 服务超时，此时服务逻辑实际不可用。必须在 /health 处理函数里同步探测关键依赖。
立即学习“go语言免费学习笔记（深入）”；
- 数据库：执行一条轻量
SELECT 1，设置context.WithTimeout(ctx, 2*time.Second)防卡死 - Redis：用
client.Ping(ctx).Err()，别用Get(ctx, "health").Val()—— 万一 key 被删了就误报故障 - 下游 HTTP 服务：用
http.DefaultClient.Do(req.WithContext(ctx))，手动构造GET /health请求，不复用主服务的路由逻辑
所有探测必须加超时和错误分类。例如 PostgreSQL 连接失败时返回 503 + {"status":"degraded","checks":{"db":"dial tcp 10.0.1.5:5432: i/o timeout"}}，让运维能区分是网络问题还是 SQL 错误。
就绪检查（/ready）和存活检查（/health）必须分离
Kubernetes 要求 livenessProbe 和 readinessProbe 使用不同端点或不同逻辑。共用一个 /health 接口会导致严重问题：比如服务刚启动，gRPC server 还没 bind 完毕，但数据库已连上——此时 /health 返回 200，K8s 认为可接收流量，结果请求进来直接 panic。
正确做法：
-
/health：只检查进程存活、核心依赖（DB、Redis）是否可达，不检查业务初始化状态 -
/ready：额外检查grpcServer.IsServing() == true、HTTP server 是否已ListenAndServe、必要配置是否加载完成（如config.Loaded）
如果用 go-grpc-middleware，可在 ready 里调用 grpc_health_v1.NewHealthClient(conn).Check 查下游 gRPC 健康状态；但注意别让它成为单点瓶颈——加 WithBlock(false) 避免阻塞。
健康状态不能只靠 HTTP 接口，要配合指标暴露给 Prometheus
HTTP 健康端点只能告诉“此刻是否活着”，无法回溯“过去 5 分钟是否抖动过”。必须用 prometheus.ClientGolang 暴露指标：
var (
healthStatus = promauto.NewGaugeVec(prometheus.GaugeOpts{
Name: "service_health_status",
Help: "1 if healthy, 0 otherwise",
}, []string{"endpoint", "dependency"})
)
// 在 /health 处理函数中：
if dbErr != nil {
healthStatus.WithLabelValues("health", "postgres").Set(0)
} else {
healthStatus.WithLabelValues("health", "postgres").Set(1)
}
关键点：指标名必须含 service_health_status 这类明确前缀，避免和第三方库冲突；label 用 endpoint 区分 /health 和 /ready，用 dependency 区分各依赖项。否则 Grafana 里根本没法做多维下钻。
最容易被忽略的是：健康检查逻辑本身不能成为性能瓶颈。所有数据库 Ping、下游 HTTP 请求都必须设独立超时（建议 ≤1s），且整个 /health 处理耗时应稳定在 10ms 内——K8s 默认每 10 秒探一次，超时 1 秒就会触发重启风暴。
