健康检查端点不能仅用http.HandleFunc硬编码注册，因缺乏超时控制、上下文取消、结构化响应及动态状态反馈，易致K8s探针误杀Pod或故障扩散；须用context.Context管理生命周期，返回JSON状态码严格区分200/503。
健康检查端点为什么不能只用 http.HandleFunc 硬写
直接注册一个 /health 路由看似简单，但实际部署时容易踩坑：Kubernetes 的 livenessProbe 和 readinessProbe 会高频调用该端点，而裸写的 handler 缺乏超时控制、上下文取消支持和结构化响应，一旦后端依赖（如数据库连接池耗尽）卡住，整个探针会 hang 住，触发误杀 Pod。
更关键的是，硬编码逻辑无法动态反映组件状态——比如 Redis 连接断开时，/health 仍返回 200，导致流量继续打进来，故障扩散。
- 必须使用
context.Context控制单次检查的生命周期，避免阻塞 - 响应体应为 JSON，包含各依赖项的详细状态（如
"redis": "ok"或"db": "timeout"），方便运维定位 - HTTP 状态码需严格区分：整体健康才返回 200；任一关键依赖失败，返回 503
用 net/http 实现可扩展的健康检查 handler
核心是把检查逻辑拆成独立函数，每个函数接收 context.Context 并返回 (status string, err error)。主 handler 统一调度、设置超时、聚合结果。
示例中，checkDB 和 checkRedis 是两个依赖检查函数，它们内部必须尊重传入的 ctx，例如用 db.PingContext(ctx) 替代 db.Ping()：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
func checkDB(ctx context.Context) (string, error) {
if err := db.PingContext(ctx); err != nil {
return "fail", fmt.Errorf("db ping failed: %w", err)
}
return "ok", nil
}
func healthHandler(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
defer cancel()
checks := map[string]func(context.Context) (string, error){
"db": checkDB,
"redis": checkRedis,
"cache": checkCache,
}
results := make(map[string]string)
var hasFailure bool
for name, fn := range checks {
status, err := fn(ctx)
results[name] = status
if err != nil {
hasFailure = true
}
}
w.Header().Set("Content-Type", "application/json")
if hasFailure {
w.WriteHeader(http.StatusServiceUnavailable) // 503
} else {
w.WriteHeader(http.StatusOK) // 200
}
json.NewEncoder(w).Encode(results)
}
为什么不用第三方库如 uber-go/zap 或 go-health
除非项目已重度依赖对应生态，否则不建议引入专用健康检查库。像 go-health 默认带 goroutine 泄漏风险（未正确处理 context 取消）、配置抽象层过重，反而增加调试成本。
-
zap是日志库，和健康检查无直接关系，混用容易误导架构设计 - 轻量级服务用原生
net/http+context完全够用，代码行数少、行为透明、便于审计 - 如果真需要自动注册多个检查项，自己封装一个
HealthChecker结构体比引入新依赖更可控
生产环境必须加上的三个细节
很多团队实现了基本功能就上线，结果在压测或网络抖动时暴露问题：
-
http.TimeoutHandler不能替代context.WithTimeout：前者只限制 handler 执行总时长，不传递取消信号给底层依赖（如db.PingContext），必须双保险 - 健康端点路径建议固定为
/healthz（K8s 社区惯例），避免和业务/health冲突；同时禁止记录 access log，减少 I/O 压力 - 检查逻辑里禁止调用任何非幂等操作（如发消息、写 DB），否则探针反复调用可能引发副作用
最常被忽略的是：没有对检查函数做 panic 捕获。一旦 checkDB 内部 panic，整个 HTTP server 会 crash。务必用 defer/recover 包裹每个检查调用。
