Go微服务健康检查需异步探测依赖并缓存快照，避免阻塞主链路；推荐用alexliesenfeld/health库管理多组件检查；K8s中livenessProbe仅查进程存活（如/healthz），readinessProbe才查完整依赖（如/health），且须合理配置超时与路径分离。
Go 微服务的健康检查不是加个 /health 路由就完事——它得能真实反映服务依赖（如数据库、Redis、下游 HTTP 服务）是否可用，且不能拖慢主请求链路。
用 net/http 搭建基础健康端点，但别在 handler 里做耗时检查
直接在 http.H 里连数据库或发 HTTP 请求，会导致健康接口超时、阻塞，甚至被 Kubernetes 误判为失活。正确做法是把检查逻辑异步化或缓存结果。
- 健康端点只返回最近一次检查的快照，例如用
sync.RWMutex保护一个全局status结构体 - 另起 goroutine 定期执行实际探测（如每 5 秒调用
db.PingContext()），更新快照 - 避免在 handler 中调用
time.Sleep、http.Get、redis.Client.Ping()等阻塞操作
go-chi/chi + health 包实现可扩展的多组件检查
当服务依赖变多（MySQL、PostgreSQL、Kafka、gRPC 对端），手写状态管理容易出错。推荐用 github.com/alexliesenfeld/health，它支持注册多个检查器并自动聚合结果。
import "github.com/alexliesenfeld/health"h := health.New(health.WithComponent("db", &health.DatabaseChecker{DB: db})) h.RegisterComponent("redis", &health.RedisChecker{Client: rdb}) h.RegisterComponent("auth-service", &health.HTTPChecker{ URL: "https://www./link/ecab0875389ce64a83f13a947994500c", Timeout: 2 * time.Second, })
// 挂载到 chi 路由 r.Get("/health", health.Handler(h))
注意：每个 HTTPChecker 的 Timeout 必须小于整体健康接口的超时（如 Nginx 或 Istio 设置的 3s），否则会级联失败。
Kubernetes readiness/liveness 探针配置要点
K8s 不关心你用什么库，只认 HTTP 状态码和响应时间。错误配置会让滚动更新卡住或触发无意义重启。
-
livenessProbe应只检查进程存活（如能否响应GET /healthz，不查 DB），失败则 kill container -
readinessProbe才该调用完整健康检查（如GET /health），失败时从 Service Endpoint 中摘除实例 - 务必设置
initialDelaySeconds: 10和timeoutSeconds: 3，避免容器启动中探针过早失败 - 不要复用同一路径——
/healthz（liveness）和/health（readiness）语义不同，混用会放大故障面
避免把健康检查变成性能瓶颈
高频探测（如 K8s 默认每 10s 一次）叠加复杂检查逻辑，可能吃光 goroutine 或连接池。
- 数据库检查用
db.PingContext(ctx)，而非执行SELECT 1——前者只走连接层，更快更轻量 - 对下游 HTTP 服务的健康检查，用带
context.WithTimeout的http.DefaultClient.Do()，禁用重试 - 如果使用连接池（如
sql.DB），确保SetMaxOpenConns(5)等参数合理，避免健康检查抢走业务连接 - 日志中过滤掉
/health请求（如 chi 中间件判断r.URL.Path == "/health"后跳过 logging）
最常被忽略的是：健康检查本身不该有副作用——比如清空缓存、重置计数器、或触发告警。它只是「读」，不是「操作」。
