健康检查接口不能直接用http.HandleFunc，因为会绕过框架的上下文、日志、超时等中间件机制，导致响应缺失统一Header、依赖无法注入，且不被HTTPS重定向或CORS中间件处理，易返回404或被拦截。
健康检查接口为什么不能直接用 http.HandleFunc
因为大多数 Go 框架（如 Gin、Echo、Fiber）都自带路由中间件机制和生命周期管理，直接注册 http.HandleFunc 会绕过框架的请求上下文、日志、超时控制等，导致健康检查响应不带框架统一的 header（比如 X-Request-ID），也难以注入依赖（如数据库连接池状态）。更关键的是：当框架启用了 HTTPS 重定向或 CORS 中间件时，裸 http.HandleFunc 注册的路径不会被这些中间件处理，可能返回 404 或被拦截。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终使用框架原生路由注册健康检查，例如 Gin 用
r.GET("/health", healthHandler)，而非http.HandleFunc("/health", ...) - 确保 handler 函数签名与框架匹配：Gin 是
func(*gin.Context)，Echo 是func(echo.Context) error，别混用 - 如果框架支持启动/关闭钩子（如 Fiber 的
App#Shutdown），把健康检查中依赖的资源状态（如 DB ping）缓存并带 TTL，避免每次请求都执行db.Ping()
如何在 handler 里安全检查数据库连接
直接在健康检查中调用 db.Ping() 是常见错误——它会阻塞当前 goroutine，且无超时。若数据库暂时不可达，整个健康检查会卡住，K8s readiness probe 可能连续失败，触发误驱逐。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout包裹db.PingContext，超时设为 1–2 秒（比 K8s probe timeout 短至少 1 秒） - 不要复用主应用的数据库连接池做健康检查；可单独配置一个轻量级连接（
&sql.DB{}+ 最小SetMaxOpenConns(1)）避免干扰业务流量 - 对 PostgreSQL，优先用
pgxpool.Pool.Stat().AcquiredConns替代Ping，更快更准；MySQL 则可用SELECT 1配合QueryRowContext
Gin/Echo/Fiber 三者的健康检查写法差异
框架抽象层不同，但核心逻辑一致：快速响应、不依赖复杂中间件、返回结构化 JSON。差异点集中在错误处理方式和上下文访问上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Gin：
c.JSON(http.StatusOK, gin.H{"status": "ok", "timestamp": time.Now().Unix()})；注意别漏掉c.Abort()后续中间件仍会执行 - Echo：
return c.JSON(http.StatusOK, map[string]interface{}{"status": "up"})；必须 return，否则 panic - Fiber：
c.Status(fiber.StatusOK).JSON(fiber.Map{"status": "healthy"})；Fiber 默认不设 Content-Type，需确认是否启用jsonParser中间件 - 所有框架都建议把健康检查路径设为静态字符串（如
/healthz），避免被路由参数解析器误匹配
为什么 K8s liveness 和 readiness 要分开实现
很多人只写一个 /health 接口供两者共用，结果是：当数据库短暂抖动时，liveness probe 失败 → 容器重启 → 连锁雪崩。liveness 应只检查进程存活（如能否响应 HTTP），readiness 才检查依赖服务就绪状态。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- liveness：纯内存检查，如
return c.String(http.StatusOK, "OK")，不碰任何外部依赖 - readiness：检查 DB、Redis、下游 gRPC 服务等，每个依赖加独立超时，失败项记录到 response body（如
{"db": "unreachable", "redis": "ok"}） - K8s YAML 中，livenessProbe 的
initialDelaySeconds设为 5–10，readinessProbe 设为 2–3，避免启动期误判 - 别在 readiness handler 里做耗时操作（如 list pods），这会让 K8s 认为服务未就绪而反复重试
curl -v http://localhost:8080/healthz 在容器内直连验证最靠谱。 
