生产环境的/health接口必须检查关键依赖并返回标准HTTP状态码：全健康返回200，任一关键依赖失败返回503；需用带超时的context并发探测DB、Redis等，绕过中间件，严格匹配路径，避免假活。
直接暴露 /health 接口不等于有了生产可用的探针——它可能返回 200 却掩盖数据库连不上、Redis 超时、下游服务不可达等真实问题。
为什么 c.JSON(200, gin.H{"status": "ok"}) 在生产环境会失效
这个写法只验证 Gin 服务进程是否在监听，完全不反映依赖组件的真实状态。Kubernetes 的 readinessProbe 如果只调这个端点，会把流量导给一个“活着但无法处理请求”的实例。
- 数据库连接池耗尽时，
/health仍返回 200，但所有业务请求卡在db.Query - Redis 实例宕机后，缓存层降级逻辑未触发，健康检查却无感知
- 依赖的 gRPC 服务超时，但 HTTP handler 没做超时控制，
/health延迟飙升却仍算“成功”
gin.Context 中如何做带超时和依赖聚合的健康检查
必须把外部依赖的探测封装成可取消、可超时、可并行的子检查，再汇总结果。不能用阻塞式 http.Get 或裸 sql.DB.Ping。
- 每个依赖检查单独设置上下文超时，例如数据库用
ctx, cancel := context.WithTimeout(c.Request.Context(), 2*time.Second) - 用
sync.WaitGroup或errgroup.Group并发执行，避免串行拖慢整体响应 - 返回结构里必须包含每个依赖的
status字段，比如{"db": "healthy", "redis": "unavailable", "cache": "degraded"} - HTTP 状态码按聚合结果返回：全绿 → 200；任一关键依赖失败 → 503；非关键降级 → 200 但 body 标明
"degraded": true
Docker 和 Kubernetes 对 /health 的不同使用方式
Docker 的 HEALTHCHECK 指令和 Kubernetes 的 readinessProbe 都调同一个接口，但行为逻辑不同，配置必须区分对待。
- Dockerfile 里的
HEALTHCHECK --timeout=3s CMD curl -f http://localhost:8080/health || exit 1：超时由curl控制，失败直接 exit 1，容器状态变unhealthy - Kubernetes 中
readinessProbe.httpGet.path: "/health"：默认无超时，需显式设timeoutSeconds: 5，且失败只影响 Endpoints，不重启容器 -
start_period只在 Docker Compose 有效，Kubernetes 用initialDelaySeconds替代，两者数值建议一致（如都设 30s），避免启动期误判
容易被忽略的细节：路径匹配、中间件和 CORS
/health 端点看似简单，但 Gin 的路由机制和中间件链会悄悄破坏它。
- 如果全局注册了 JWT 鉴权中间件，
r.Use(authMiddleware)，那/health也会被拦截——必须用r.NoRoute()或显式跳过：r.GET("/health", healthHandler)放在中间件注册之前 - Gin 默认不支持跨域，前端监控页面访问
/health会因 CORS 被拒，加c.Header("Access-Control-Allow-Origin", "*")即可，无需完整 CORS 中间件 - 路径必须严格匹配：写成
r.GET("/health/", ...)会导致curl /health404，因为末尾斜杠不等价
真正的难点不在写接口，而在定义“健康”的边界：哪些依赖必须在线，哪些允许降级，超时阈值设多少才不误杀也不漏判——这些得跟 SRE 和业务方对齐，不能只靠开发拍脑袋。
