Kubernetes健康检查需分离/livez和/readyz端点：/livez仅轻量检测进程存活，/readyz才检查DB等外部依赖，二者均须绕过中间件、使用带超时的专用HTTP客户端并原子保护状态变量。
直接暴露 /livez 和 /readyz 两个独立端点
别用单个 /health，Kubernetes 会因依赖抖动反复杀掉 Pod。/livez 只确认进程活着：HTTP server 能 accept 连接、关键 goroutine 没卡死、内存没暴涨；/readyz 才检查 DB、Redis 等外部依赖是否连得上。
-
/livezhandler 里禁止调db.PingContext或redis.Ping，只做runtime.NumGoroutine()和http.CanonicalHeaderKey级别的轻量判断 -
/readyz每个依赖必须带独立context.WithTimeout(ctx, time.Second*3)，超时就降级，不拖垮整个响应 - 两个 handler 都要绕过所有中间件——用
http.ServeMux单独注册，或在主 mux 里用HandleFunc直接挂载，别包进authMiddleware里
依赖探测必须用带超时的专用 http.Client
直接用 http.Get 探下游服务，90% 的线上故障源于它默认无超时、自动重定向、不关 body。短时间高频探测会迅速耗尽文件描述符，导致服务假死。
- 构造专用 client：
http.Client{Timeout: time.Second * 4, CheckRedirect: func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse }} - 每次调用后必须
resp.Body.Close()，否则 fd 泄漏不可逆 - DB 检查用
db.PingContext(ctx)，Redis 用client.Ping(ctx).Err()，别手写 TCP 连接
状态变量必须原子保护，定时巡检要主动 stop
用 time.Ticker 做后台健康轮询很常见，但热重启时旧 ticker 不停、新 ticker 又起，多个 goroutine 并发写同一个 redisHealthy 变量，接口返回 “true” 实际已断连。
- 启动 ticker 时用
ctx, cancel := context.WithCancel(context.Background())包裹，收到 shutdown 信号时调cancel()+ticker.Stop() - 健康状态字段如
dbUp必须用sync/atomic.Bool或sync.RWMutex保护，禁止裸写dbUp = false - 不要在 handler 里实时调依赖——把结果缓存在原子变量中，handler 只读，避免阻塞
返回体要轻量、可读、不泄露信息
Kubernetes、Consul 只认 HTTP 状态码，body 是给人看的。返回数据库连接字符串或配置内容，等于把攻击面直接暴露给任意能访问 /readyz 的人。
立即学习“go语言免费学习笔记（深入）”；
- 推荐纯文本
"ok"或最小 JSON：{"status":"up","ts":1722786685}，去掉message、version等非必要字段 - 失败时返回
http.StatusServiceUnavailable（503），body 明确标注失败项：{"status":"down","failed_check":"redis"} - 绝不返回
err.Error()或堆栈，用zap.Error("redis ping failed", zap.String("component", "redis"))记日志即可
实际最难的部分不是写 handler，而是让 /livez 和 /readyz 在真实流量、依赖抖动、容器重启的混合压力下保持语义稳定——状态变量怎么同步、ticker 怎么收口、超时怎么设才既不过于敏感也不过于迟钝，这些细节不压测根本看不出问题。
