HTTP健康检查应实现轻量级端点，如/health返回{"status":"ok"}；依赖检查需并发、超时、缓存且不记录error日志；K8s中liveness与readiness须分离路径；第三方库易引发竞态和指标冲突，推荐手写。
HTTP 服务内置健康检查端点怎么写
Go 标准库 net/http 没有内置健康检查逻辑，但实现一个轻量级端点非常直接：监听 /health 或 /healthz，返回 200 和简单 JSON 即可。关键在于避免引入额外依赖、不阻塞主线程、不带副作用。
- 用
http.HandleFunc注册路径，不要用中间件封装过度（除非已有统一中间件体系） - 响应体保持极简：
{"status":"ok"}，Content-Type 设为application/json; charset=utf-8 - 务必设置超时 —— 如果检查逻辑涉及 DB 或外部调用，必须加
context.WithTimeout，否则健康检查本身可能拖垮探针 - 不要在健康检查里做重操作（如刷新缓存、重连数据库），它只应反映「当前可响应」状态，不是「完全就绪」状态
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
w.WriteHeader(http.StatusOK)
w.Write([]byte(`{"status":"ok"}`))
})
需要检查后端依赖时怎么设计
真实服务往往依赖数据库、Redis、下游 HTTP 接口等。这时健康检查不能只看自身进程存活，得探测关键依赖是否可达。但要注意：探测粒度、失败策略和缓存结果都影响可用性判断。
- 每个依赖单独检查，不要串行阻塞（用
sync.WaitGroup或errgroup.Group并发） - 对每个依赖设独立超时，比如 DB 用 500ms，Redis 用 200ms —— 避免一个慢依赖拖垮整个健康响应
- 失败时不 panic，也不记录 error 级日志（健康检查高频调用，会刷爆日志），可记录 warn 级并带上依赖名
- 考虑加简单缓存（如 30 秒内复用上次结果），防止探针每秒多次请求把依赖打挂
func checkDB(ctx context.Context) error {
ctx, cancel := context.WithTimeout(ctx, 500*time.Millisecond)
defer cancel()
return db.PingContext(ctx)
}
如何与 Kubernetes liveness / readiness 配合
K8s 的 livenessProbe 和 readinessProbe 默认都调用同一个 HTTP 端点，但这容易导致误杀：比如 DB 临时不可用，liveness 触发重启，反而加剧雪崩。应该拆开语义。
-
liveness只检查进程是否卡死（例如 goroutine 泄漏、死锁），可只返回200 OK，不做任何外部依赖检查 -
readiness才检查 DB/Redis/下游等，返回 200 表示「可接收流量」，返回 503 表示「暂时别转发请求」 - 在 K8s YAML 中明确区分路径：
livenessProbe.httpGet.path: /healthz/liveness，readinessProbe.httpGet.path: /healthz/readiness - 注意 K8s 默认重试 3 次、初始延迟 30 秒，若你的服务启动慢，需调大
initialDelaySeconds，否则容器反复重启
用第三方库如 go-health 有什么坑
go-health 这类库能自动聚合检查项、输出结构化 JSON，但实际落地常被低估两个问题：初始化时机和指标污染。
立即学习“go语言免费学习笔记（深入）”；
- 注册检查器必须在 HTTP server 启动前完成，否则热更新检查逻辑会导致竞态（比如新检查器刚注册，旧的还在跑）
- 如果用了 Prometheus client，
go-health的默认指标名（如health_check_duration_seconds）可能和你已有的监控命名冲突，需手动 prefix 或禁用指标导出 - 它的
Checkers是全局单例，多个服务共用一个实例时，不同服务的检查逻辑会互相覆盖 —— 必须按服务实例隔离 - 除非团队已有统一健康检查规范，否则从零项目建议手写，复杂度低、可控性强、调试直观
