必须显式配置带依赖校验的健康检查端点，因单纯注册/health路由无法验证数据库、缓存等真实就绪状态，易致流量过早导入引发500错误；需区分liveness与readiness语义，支持可插拔检查项、结构化json响应及kubernetes探针关键参数（如timeoutseconds≤handler超时、failurethreshold≥3）精准配置。
生产环境必须显式配置健康检查端点，Fiber 默认不提供内置 /health 路由，也不能依赖中间件自动注入。
为什么不能只用 app.Get("/health", ...) 就完事
单纯注册一个路由在 Kubernetes 或 Istio 等环境中会被判定为“不可靠探针”：它不校验服务真实就绪状态（比如数据库连接、缓存连通性、队列消费者是否启动）。Istio 的 readinessProbe 若只访问静态响应，可能在 DB 还没连上时就把流量导进来，直接触发 500。
- 健康检查必须区分
/health（liveness，进程存活）和/ready（readiness，服务就绪）两个语义 - 必须支持可插拔的检查项，例如：
db.PingContext()、redis.Ping()、http.Head("http://upstream:8080/health") - 响应体应包含各依赖项状态，而不仅是 HTTP 状态码 —— 方便人工排查或 Prometheus 抓取
fiber.New() 初始化时禁用默认错误处理，避免干扰探针
Fiber 默认的 ErrorHandler 会把 panic 转成 HTML 错误页，这对 curl -I 类探针极不友好。Kubernetes 的 livenessProbe 只看 HTTP 状态码，HTML 响应体反而可能让监控误判。
- 初始化时传入自定义错误处理器：
fiber.Config{ErrorHandler: func(c fiber.Ctx, err error) error { return c.Status(fiber.StatusInternalServerError).SendString("health check failed") }} - 确保所有健康检查 handler 内部不调用
c.Next()，否则可能被其他中间件劫持响应 - 禁止在健康路由里使用
recover()捕获 panic —— 探针需要明确失败信号，不是静默吞掉异常
如何写一个带依赖校验的 /ready handler
不要手写 if db == nil 这类空值判断，那只是“变量存在”，不是“服务可用”。真实场景下，DB 连接池可能已建立但网络中断，Redis 可能响应超时但未断连。
- 每个依赖检查必须带 context 和超时：
ctx, cancel := context.WithTimeout(c.Context(), 2*time.Second); defer cancel() - 数据库检查用
db.PingContext(ctx)，不是db.Exec—— 前者只发握手包，开销低且语义准确 - 外部服务检查优先用
http.Head，比GET少传 body，降低链路压力 - 返回 JSON 格式，字段名统一小写：
{"db": "ok", "redis": "timeout", "status": "degraded"}，便于日志提取和告警规则匹配
app.Get("/ready", func(c fiber.Ctx) error {
ctx, cancel := context.WithTimeout(c.Context(), 2*time.Second)
defer cancel()
status := map[string]string{"status": "ok"}
if err := db.PingContext(ctx); err != nil {
status["db"] = "failed"
status["status"] = "degraded"
}
if err := redisClient.Ping(ctx).Err(); err != nil {
status["redis"] = "failed"
status["status"] = "degraded"
}
code := fiber.StatusOK
if status["status"] == "degraded" {
code = fiber.StatusServiceUnavailable
}
return c.Status(code).JSON(status)
})
Kubernetes 配置里容易漏掉的三个字段
很多人只配了 initialDelaySeconds，却忽略探针行为细节，导致滚动更新卡住或误杀 Pod。
-
failureThreshold必须设为 ≥3：网络抖动时单次失败不应触发重启 -
periodSeconds生产建议设为 10–15 秒，太短会压垮服务，太长故障发现慢 -
successThreshold对 readinessProbe 必须是 1（默认值），但 livenessProbe 在容器重启后需重置计数，建议显式写successThreshold: 1
最常被忽略的是 timeoutSeconds：它必须 ≤ 后端 handler 的 context 超时（比如上面代码用了 2s），否则 Kubelet 等不到响应就直接 kill probe 进程，返回 Unknown 状态。
