Golang服务健康检查应暴露轻量探活端点，HTTP适用于多数场景（如K8s、Nginx），gRPC适合内部强契约通信；需避免耗时操作、引入状态缓存、分离Liveness/Readiness逻辑。

用 Golang 做服务健康检查，核心是暴露一个轻量、可靠、低开销的探活端点，并让外部（如 K8s、Consul、Nginx 或自建巡检系统）能定期调用它。HTTP 和 gRPC 各有适用场景：HTTP 简单通用，适合大多数基础设施集成；gRPC 更适合内部微服务间强契约、低延迟的健康通信，但需客户端支持。

HTTP 健康检查：简单可靠，推荐默认方案

HTTP 方式最常用，Kubernetes Liveness/Readiness、Nginx upstream health check、Prometheus blackbox exporter 都原生支持。关键是要返回明确状态码 + 可读响应体。

• 用标准 http.HandleFunc 注册 /healthz（或 /health）端点，返回 200 OK 表示存活，非 200（如 503）表示异常
• 避免在健康端点中做耗时操作（如 DB 连接池 ping、远程 HTTP 调用），只检查本地关键依赖是否就绪（例如：DB 连接池是否非空、Redis client 是否可 Ping、配置是否加载完成）
• 可返回 JSON 响应体辅助排障，例如：{"status":"ok","checks":{"db":"ok","redis":"ok"}}，但不要影响状态码逻辑
• 建议加 Timeout 和 Keep-Alive 控制：启动 HTTP server 时设置 ReadTimeout、WriteTimeout，防止健康接口被阻塞拖垮整个服务

gRPC 健康检查：符合 gRPC 生态，适合服务网格场景

如果你的服务已全面采用 gRPC，且调用方也是 gRPC 客户端（如 Istio、gRPC-Go 客户端），可用官方 gRPC Health Checking Protocol，它定义了标准的 HealthCheckService 接口。

• 导入 google.golang.org/grpc/health 和 google.golang.org/grpc/health/grpc_health_v1
• 创建 health.Server 实例，调用 SetServingStatus 主动上报服务状态（servicename 为空字符串表示默认服务）
• 将 health server 注册到你的 gRPC server：grpc_health_v1.RegisterHealthServer(grpcServer, healthServer)
• 客户端用 grpc_health_v1.NewHealthClient(conn).Check(ctx, &grpc_health_v1.HealthCheckRequest{Service: ""}) 发起探活，成功且 status == SERVING 即为健康
• 注意：gRPC 健康检查本身不自动探测后端依赖，仍需你在 SetServingStatus 前同步执行轻量检查（如检查数据库连接是否有效）

主动定时自检 + 状态缓存：避免每次探活都触发检查

频繁的探活请求（尤其高并发时）若每次都实时检查 DB/Redis，会带来不必要压力。更优做法是后台 goroutine 定期执行真实检查，把结果缓存在内存中，探活端点只读取快照。

• 启动时起一个 goroutine，用 time.Ticker 每 5–10 秒执行一次依赖检查（如 db.PingContext()）
• 用 atomic.Value 或 sync.RWMutex 包裹状态结构体（如 type HealthStatus struct { DBOK, RedisOK bool }），保证并发安全读写
• HTTP/gRPC 探活 handler 中只做快速读取，根据缓存状态决定返回码和响应体
• 这样既保证探活低延迟，又避免雪崩式下游探测压垮依赖服务

集成 Kubernetes：Liveness 与 Readiness 分离设计

K8s 中 livenessProbe 决定是否重启容器，readinessProbe 决定是否加入 Service Endpoint。二者逻辑应不同：

• Liveness：只检查进程是否卡死（如 goroutine 泄漏、死锁），可仅检测 HTTP 端口是否可连、gRPC server 是否 accept，**不检查外部依赖**（否则 DB 挂了会导致无限重启）
• Readiness：检查服务是否真正可服务，包括关键依赖（DB、Redis、配置中心）。只有全部 OK 才返回 200 / SERVING，否则 503 / NOT_SERVING，让流量暂时绕过
• Golang 中可复用同一套检查逻辑，但通过 URL path 或 gRPC service name 区分（如 /healthz/liveness vs /healthz/readiness）

基本上就这些。HTTP 适合绝大多数场景，开箱即用；gRPC 健康检查适合深度 gRPC 架构；加上状态缓存和 K8s 探针分离，就能支撑生产级稳定性要求。不复杂但容易忽略细节——关键是别让健康检查本身成为故障源。