应在Gin中分别暴露/health（存活）、/readyz（就绪）端点：/health仅检查进程状态并快速返回，/readyz同步检测DB、Redis等关键依赖且设≤3s超时；响应结构需含status、checks、timestamp字段，依赖状态应由后台goroutine定期探测并缓存，避免每次请求触发实时检查。
如何在 Gin 中暴露标准化的 /health 接口
直接返回 200 OK 的静态健康端点无法反映真实服务状态，Gin 里必须把「可探测性」和「可解释性」分开设计。用 gin.HandlerFunc 替代裸 http.HandleFunc，才能统一走中间件链、日志、CORS 等生产级流程。
关键点：不要在 handler 里写死 status: "ok"，而是构造一个结构体，字段包含 status（字符串）、checks（map[string]any）、timestamp（time.Time）。这样前端 UI 或 Prometheus Exporter 才能解析出明细。
示例代码片段：
r.GET("/health", func(c *gin.Context) {
result := map[string]interface{}{
"status": "ok",
"timestamp": time.Now().UTC().Format(time.RFC3339),
"checks": make(map[string]interface{}),
}
c.Header("Content-Type", "application/json; charset=utf-8")
c.JSON(http.StatusOK, result)
})
数据库与缓存依赖检查该放在哪里执行
不能把 DB Ping() 放在每次 /health 请求里——高并发下会压垮连接池或触发慢查询。正确做法是：启动时建立一个后台 goroutine，定期（如每 15 秒）调用 db.Ping() 并缓存结果；/health handler 只读取这个缓存值。
缓存结构建议用 sync.Map，key 是组件名（如 "postgres"、"redis"），value 是 struct{ ok bool; lastErr error; updatedAt time.Time }。避免加锁竞争，也防止健康检查本身成为故障源。
常见错误现象：
- 每次请求都
db.Ping()→ Kubernetes readiness probe 失败率飙升 - 没设超时 → Redis 挂掉后整个
/health卡住 5 秒以上 - 错误信息直接返回给调用方 → 泄露内网地址或版本号
为什么 readinessProbe 和 livenessProbe 要分离实现
Kubernetes 的 readinessProbe 和 livenessProbe 语义完全不同：readiness 决定是否将 Pod 加入 Service Endpoints，liveness 决定是否重启容器。Gin 中必须提供两个独立 endpoint，比如 /readyz 和 /livez，不能复用同一个 handler。
/readyz 应包含所有依赖检查（DB、Redis、下游 HTTP 服务连通性），但不检查内存泄漏或 goroutine 泄漏；/livez 只做轻量级存活判断（如进程未卡死、goroutine 数未超阈值），甚至可以只返回 200。
参数差异：
-
readinessProbe：failureThreshold 建议设为 3，initialDelaySeconds 设为 10–30（等 DB 连接池建满） -
livenessProbe：timeoutSeconds 必须 ≤ 1，否则会拖慢容器重启速度
若共用一个接口，K8s 可能因 DB 临时抖动反复剔除又加入 Pod，造成流量震荡。
如何让健康检查结果被 Prometheus 自动采集
Prometheus 默认抓取 /metrics，不是 /health。想把健康状态转成指标，得用 promhttp.Handler() + 自定义 collector，而不是在 JSON 里塞一堆字段完事。
推荐方式：用 prometheus.NewGaugeVec 定义一个带 label 的 gauge，例如：
healthStatus = prometheus.NewGaugeVec(
prometheus.GaugeOpts{
Name: "service_health_status",
Help: "Health status of service components (1=ok, 0=failed)",
},
[]string{"component"},
)
然后在后台检查 goroutine 里，根据每个组件状态调用 healthStatus.WithLabelValues("postgres").Set(1) 或 .Set(0)。Prometheus 抓取时就能按 component 维度聚合告警。
容易踩的坑：
- 没注册 collector 到
prometheus.DefaultRegisterer→ 指标完全不出现 - label 值含斜杠或空格 → Prometheus 抓取报错
invalid metric name - 在 handler 里实时计算并 Set → 高频请求导致指标抖动，掩盖真实问题
复杂点在于：健康状态是瞬时快照，而 Prometheus 是拉模型，必须靠后台 goroutine 主动上报，不能等请求来了再算。这点和传统 RESTful 健康接口思维完全不同。
