/healthz不能走Gin中间件链，因为日志、recover、鉴权等中间件会带来冗余开销、日志撑爆卷、远程调用阻塞及超时风险；正确做法是绕过中间件，用router.Any()配合c.AbortWithStatus(200)直接响应。
为什么 /healthz 不能走 Gin 中间件链
Gin 的 gin.Engine 默认给所有路由套上日志、recover、CORS 等中间件，而 /healthz 每秒被 Kubernetes 轮询一次，中间件会带来三重开销：recover 捕获 panic 是冗余的（健康端点不该 panic）、日志写入撑爆 volume、鉴权可能触发 JWT 解析或远程调用。更严重的是，某些中间件（比如自定义的 context 注入或 trace 初始化）会在 handler 执行前阻塞，导致响应超时。
正确做法是绕过整个中间件栈，直接注册原生 http.ServeMux 或用 Gin 的 Any() + AbortWithStatus(200)：
router.Any("/healthz", func(c *gin.Context) {
// 只检查内存标志，不碰 DB、磁盘、网络
if atomic.LoadInt64(&healthy) == 1 {
c.AbortWithStatus(200)
return
}
c.AbortWithStatus(503)
})- 必须用
AbortWithStatus，不是String或JSON，否则中间件仍会继续执行 - 不要在 handler 里调用
c.Next()，它会强制走后续中间件 - 如果用了
gin.Default()，记得在Run()前禁用默认中间件：router.Use(gin.Recovery())不要加到/healthz上
livenessProbe 和 readinessProbe 怎么分工
混淆二者是容器化 Go 服务最常踩的坑——把数据库连通性塞进 /healthz，结果 DB 一抖就触发无限重启（CrashLoopBackOff）。Kubernetes 明确区分语义：
-
livenessProbe对应/healthz：只答“进程是否卡死”，检查atomic.LoadInt64(&healthy)、goroutine 数突增、内存泄漏标记等纯进程内状态 -
readinessProbe对应/readyz：答“能否收流量”，可查 DB 连接池、Redis ping、下游 HTTP 服务连通性，但必须设短超时（如context.WithTimeout(ctx, 200 * time.Millisecond)）并容忍临时失败 - StartupProbe（K8s 1.16+）适合冷启动长的应用：比如加载大模型权重或初始化缓存，避免
livenessProbe在启动完成前误杀
Deployment YAML 中两者的配置差异很关键：
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30 # 给应用留足启动时间
periodSeconds: 10
timeoutSeconds: 1 # 必须 ≤1s，否则 K8s 认为卡死
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5 # 启动后快速接入流量
periodSeconds: 5
timeoutSeconds: 2 # 允许稍慢，但不能拖垮调度如何避免健康检查被 GC 或调度延迟误判
Go 的 STW（stop-the-world）GC 或 Linux CFS 调度器偶尔会让 goroutine 延迟数秒执行，导致 /healthz 响应超时。这不是代码 bug，而是运行时现实。单纯调大 timeoutSeconds 会掩盖真实问题，正确解法是分层容忍：
- 在
livenessProbe中设置failureThreshold: 3，允许连续 3 次失败才重启，避开单次 GC 尖峰 - 用
atomic标记代替实时计算：比如在 main goroutine 启动后置atomic.StoreInt64(&healthy, 1)，而非每次请求都查 runtime.NumGoroutine() - 避免在健康 handler 里分配堆内存（如
fmt.Sprintf、json.Marshal），防止触发 GC - 若服务有大量定时任务，确保它们不抢占
/healthz所在的 P，可用runtime.LockOSThread()隔离关键路径（慎用）
Dockerfile 里 HEALTHCHECK 和 K8s probe 冲突吗
会。Docker 的 HEALTHCHECK 指令和 Kubernetes 的 livenessProbe 是两套独立机制，同时启用会导致重复探测、资源浪费，甚至因 Docker 守护进程对容器状态的误判引发异常重启。
生产环境只保留 K8s probe，Dockerfile 中应删掉 HEALTHCHECK 指令，或明确注释禁用：
# 禁用 Docker 原生健康检查，由 K8s livenessProbe 统一管理 # HEALTHCHECK --interval=30s --timeout=3s --retries=3 CMD curl -f http://localhost:8080/healthz || exit 1
- K8s probe 更灵活：支持
httpGet、tcpSocket、exec，且能感知 Pod 网络拓扑 - Docker HEALTHCHECK 在 Swarm 或单机调试时有用，但进 K8s 后就是冗余逻辑
- 镜像构建阶段若需验证基础镜像健康，可在 CI 中用
docker run --rm+curl测试，而非固化到镜像里
真正容易被忽略的是：K8s 探针的 initialDelaySeconds 必须大于应用冷启动耗时，而这个时间往往随环境变化（比如 Dev 环境用 SQLite，Prod 用 PostgreSQL，连接初始化时间差 3 秒以上）——别写死数字，用配置中心或环境变量注入。
