/health/ready应只读缓存状态而非实时探测依赖。启动时用ticker定期检查DB/Redis/gRPC并缓存结果，handler仅无副作用读取；/health/live与/health/ready须分离，前者查进程级指标，后者返回结构化依赖状态；健康端点需独立路由、禁用中间件、避免日志监控阻塞。
Go服务在Kubernetes里健康检查拖慢响应、触发误重启，八成不是探针配得不对，而是/health/ready端点本身在每次请求时同步连DB/Redis/gRPC，没缓存、没超时、没隔离——结果一个探针卡住，整个HTTP server goroutine池被占满。
为什么/health/ready每次调db.Ping()就OOM或超时
高频探针（默认periodSeconds: 5）下，每个/health/ready请求都新建连接、发一次db.PingContext()，会快速耗尽数据库连接池、触发TCP重传、堆积goroutine。Kubernetes默认timeoutSeconds: 1，只要一次探测超过1秒，就判失败；连续failureThreshold: 3次就杀Pod。
- 别在handler里调
sql.Open()或redis.NewClient()——复用启动时已初始化的全局*sql.DB和*redis.Client - 所有依赖检查必须带context超时：
ctx, cancel := context.WithTimeout(context.Background(), 1500*time.Millisecond)，总耗时压到2秒内 - 非强依赖项（如日志上报、监控push）改用异步检查+本地缓存，不阻塞响应流
- 用
sync.RWMutex保护缓存结构体，读多写少场景下避免锁争抢
怎么让/health/ready返回快又不失真
真实就绪 ≠ 每次都重连验证。应该把探测逻辑下沉到后台goroutine，定期刷新状态快照，/health/ready只做无副作用的读取。
- 启动时起一个
time.Ticker，每5秒执行一次全量依赖检查（db.PingContext()、redis.Ping()、grpcConn.GetState()） - 结果存进线程安全结构体：
type HealthStatus struct { DB string; Redis string; GRPC string; Updated time.Time } -
/health/readyhandler只读这个结构体，不做任何I/O操作 - 状态变更加简单去抖：连续3次失败才标
"DOWN"，恢复需连续2次成功且间隔>500ms
如何避免中间件或panic污染健康端点
框架中间件（如JWT鉴权、日志、panic recovery）一旦挂掉或阻塞，/health也会跟着不可用——这违背了健康检查“独立、轻量、可靠”的设计原则。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用独立
http.ServeMux注册健康路由，和业务mux完全隔离：healthMux := http.NewServeMux(); healthMux.HandleFunc("/health", ...) - Gin中必须把健康路由注册在
r.Use()之前，或显式跳过：r.NoRoute(func(c *gin.Context) { if c.Request.URL.Path == "/health" { healthHandler(c); return } }) - Echo中用
e.GET("/health", healthHandler).SkipMiddleware = true，注意不是Use().Skip - 禁止在健康handler里调用
log.Printf或prometheus.InstrumentHandler——它们可能阻塞或panic
为什么/health/live和/health/ready不能共用一个handler
混用会导致滚动更新卡死：数据库挂了但livenessProbe仍通过，K8s不重启；而readinessProbe失败后又立刻摘流量，新Pod还没起来旧Pod已下线。
-
/health/live只查进程级快照：runtime.NumGoroutine()是否突增、关键channel是否已close、http.Server.ActiveConn是否为0 -
/health/ready才查业务依赖，且必须返回结构化错误：{"db": "timeout", "redis": "ok"}，不能只写{"status": "down"} - K8s配置必须严格对应：
livenessProbe.httpGet.path指向/health/live，readinessProbe.httpGet.path指向/health/ready - 别信
initialDelaySeconds设得大就能兜底——DB连接池warmup要10秒以上，readinessProbe.initialDelaySeconds: 15是底线
最常被忽略的一点：健康检查不是“写完就跑”，它需要和K8s探针参数形成闭环——timeoutSeconds必须比你后台探测周期长，periodSeconds必须比单次快照读取耗时高至少2倍，否则再好的缓存也救不了误判。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
