健康检查接口应返回含组件状态的json结构，如{"status":"healthy","timestamp":"...", "checks":{"db":{"status":"healthy","latency_ms":4.2},"redis":{"status":"degraded","latency_ms":1280},"auth_service":{"status":"unavailable"}}}，每个子项需独立状态、实测延迟、带时间戳；/health/live仅查进程存活，/health/ready须验证业务就绪条件，所有探测须设超时且读缓存而非实时调用。
健康检查接口该返回什么结构
Go 服务暴露 /health 接口时，别只返回 200 OK 或 {"status": "ok"}。这种设计在真实运维中几乎没用——你没法区分是 HTTP 层通了，还是数据库连不上、Redis 超时、下游 gRPC 调用卡死。应该返回带组件状态的 JSON，例如：
{
"status": "healthy",
"timestamp": "2024-06-12T10:32:15Z",
"checks": {
"db": { "status": "healthy", "latency_ms": 4.2 },
"redis": { "status": "degraded", "latency_ms": 1280 },
"auth_service": { "status": "unavailable" }
}
}
关键点：每个子检查必须有独立状态（healthy/degraded/unavailable），不能靠整体 status 掩盖局部失败；latency 必须实测，不是硬编码；timestamp 用于排查时序问题。
如何避免健康检查拖慢主请求链路
常见错误是把 db.Ping() 或 redis.Ping() 直接塞进 HTTP handler —— 一旦依赖服务响应慢，/health 就卡住，Kubernetes 的 liveness probe 可能误判重启整个 Pod。正确做法是预热 + 超时隔离：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动时用 goroutine 预热各检查项，缓存最近一次结果（比如 30 秒内不重复探测）
- 每次 HTTP 请求只读缓存，不触发新探测
- 单独提供
/health/live（轻量级，只检查进程存活）和/health/ready（含依赖检查），让 k8s 分开配置 liveness/readiness probe - 所有底层探测必须设明确 timeout，如
ctx, _ := context.WithTimeout(context.Background(), 2*time.Second)，绝不用context.Background()
怎么让第三方组件（如 pgx、redigo）支持健康检查
官方库通常不内置 health check 方法，得自己封装。以 pgx 为例，别直接调 conn.Ping()，它可能阻塞在连接池获取上。应：
- 用
pool.Stat()检查连接池健康度（AcquireCount、AcquiredConns是否异常增长） - 发一个轻量 SQL：
SELECT 1，而非PING命令（pgx 不支持原生 PING） - 对
redigo，用conn.Do("PING")，但必须包裹在context.WithTimeout内，且提前检查conn.Err()是否已断连 - 所有封装函数签名建议统一为
func(ctx context.Context) (bool, time.Duration, error)，方便聚合统计
为什么 readiness probe 不能只看 /health 返回码
Kubernetes readiness probe 默认只看 HTTP 状态码，但 200 不代表 ready。比如服务刚启动，gRPC server 还没完成服务注册，但 HTTP server 已就绪，此时 /health 可能返回 200，却导致流量打到未就绪的服务上。必须：
- 在
/health/ready中显式检查关键就绪条件：gRPC server 的grpc_health_v1.HealthClient.Check()、消息队列消费者是否已启动、配置热加载是否完成 - 避免在 handler 里做耗时初始化，把就绪逻辑移到启动阶段，用
sync.Once+ 标志位控制 - 如果使用
uber-go/zap，可在健康检查中输出 last log timestamp，辅助判断日志 pipeline 是否卡住
真正麻烦的从来不是写个 /health 接口，而是定义清楚“健康”到底指什么——是进程活着？HTTP 可达？依赖全通？还是业务能力就绪？不同层级要拆开，不能混在一起糊弄。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
