健康检查端点应返回200 OK状态码及JSON响应体{"status": "ok", "timestamp": "2024-06-15T10:23:45Z"}，依赖检查需超时控制、降级处理，推荐单端点/health统一支持liveness与readiness语义。
健康检查端点该返回什么状态码和响应体
健康检查端点不是“能访问就行”，它要让调用方（比如 Kubernetes、Nginx、Consul）快速、无歧义地判断服务是否**就绪（ready）**或**存活（live）**。Kubernetes 的 livenessProbe 和 readinessProbe 默认只看 HTTP 状态码，所以 200 OK 是底线；返回非 2xx 状态码（如 503 Service Unavailable）会被视为失败。
响应体内容不强制，但建议包含最小必要信息：
- 用 JSON 返回
{"status": "ok", "timestamp": "2024-06-15T10:23:45Z"}，避免纯文本或空响应 —— 方便日志采集和调试 - 不要在健康检查里返回数据库连接详情、配置项等敏感信息
- 如果做 readiness 检查且依赖下游服务（如 Redis、PostgreSQL），可加字段
"db": "ok"，但必须控制超时（见下一条）
如何避免健康检查阻塞或拖垮服务
常见错误是把 /health 写成同步全链路探测：连 DB → 连 Redis → 调第三方 API → 校验磁盘空间……一旦任一依赖慢或挂了，整个健康端点卡住，Kubernetes 就会反复重启 Pod。
正确做法是分层、超时、非关键依赖降级：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
context.WithTimeout(ctx, 2*time.Second)包裹所有外部调用，硬性限制总耗时 - DB/Redis 连接检查只做
Ping()，不执行真实查询；第三方 API 健康检查应走独立轻量 endpoint（如/health本身），而非业务接口 - 对非核心依赖（如日志上报服务、指标推送），直接跳过检查，或设为 “degraded” 状态而不影响整体
status: "ok" - 避免在 handler 里新建 goroutine 异步检查 —— 状态不同步，且无法及时响应 timeout
Go 标准库 http.ServeMux 下的简洁实现
不需要引入完整框架（如 Gin、Echo）也能写出生产可用的健康端点。用标准 net/http 完全够用，关键是把逻辑抽离、可测试。
示例结构：
func healthHandler(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
defer cancel()
status := map[string]interface{}{
"status": "ok",
"timestamp": time.Now().UTC().Format(time.RFC3339),
}
// 检查 DB（假设 db 是 *sql.DB）
if err := db.PingContext(ctx); err != nil {
status["db"] = "error"
status["status"] = "error"
w.WriteHeader(http.StatusServiceUnavailable)
} else {
status["db"] = "ok"
}
w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(status)
}
// 注册
http.HandleFunc("/health", healthHandler)
注意：db.PingContext 是 Go 1.8+ 支持的带上下文的探活方式，比老式 db.Ping() 更安全；w.WriteHeader() 必须在 json.Encoder 之前调用，否则会被忽略。
为什么不用 liveness 和 readiness 分开两个端点
很多团队一开始照搬 Kubernetes 文档，硬拆 /live 和 /ready，结果维护两套逻辑、响应体不一致、监控告警规则重复。实际中，绝大多数 Go 服务只需一个 /health 端点，靠 probe 配置区分语义：
- Kubernetes 中，
livenessProbe可设initialDelaySeconds: 10+periodSeconds: 30，容忍启动慢；readinessProbe设initialDelaySeconds: 2+periodSeconds: 5，更快响应流量切换 - 两者都指向同一 handler，但 readiness 可额外检查
isServerRunning标志位（比如 HTTP server 是否已ListenAndServe启动），而 liveness 不检查这个 —— 这种差异应在 handler 内部通过r.URL.Path或 query 参数区分，而不是拆路由 - 拆成两个端点反而增加反向代理（如 Envoy）的路由复杂度，也容易漏配 TLS / CORS 规则
真正需要分离的场景极少，比如你有长周期后台任务（如视频转码 worker），它的 liveness 表示进程没卡死，readiness 表示当前无积压任务 —— 这类特殊逻辑才值得单独 endpoint。
