健康检查端点必须显式注册如/healthz，不可依赖根路径或中间件；就绪检查应仅验证本地服务状态与快速依赖探活（≤200ms），避免阻塞操作和日志输出。
健康检查端点必须用 http.HandleFunc 注册到根路径或明确路径
Go 标准库的 http.ServeMux 不支持通配路由，/healthz、/health 这类路径必须显式注册。如果只注册了 /，而请求发到 /healthz，会返回 404 —— 这是部署到 Kubernetes 时最常见的失败原因。
实操建议：
- 始终为健康检查单独注册一个路径，例如：
http.HandleFunc("/healthz", healthHandler) - 避免依赖中间件自动注入（如某些框架的全局 health route），K8s 的
livenessProbe和readinessProbe默认不带任何 header 或 cookie，中间件可能意外拦截或重定向 - handler 内部不要调用阻塞型 DB 连接池
db.Ping()，应改用非阻塞探测（如检查连接池是否已初始化、或使用db.Stats().OpenConnections）
使用 net/http 实现轻量级就绪检查（readiness）
就绪检查要反映服务是否能真正处理业务请求，但又不能太重。常见错误是把数据库 Ping() 放进 readiness handler，导致 DB 短暂抖动时整个服务被 K8s 下线。
推荐做法：
立即学习“go语言免费学习笔记（深入）”；
- 只检查本地状态：HTTP server 是否已启动监听、gRPC listener 是否就绪、必要配置是否加载完成
- 对依赖服务做快速探活（超时严格控制在 200ms 内），例如用
http.Client带Timeout: 200 * time.Millisecond请求下游 /healthz - 避免日志输出：K8s 会高频轮询，每秒一次的
log.Println("readiness ok")会刷爆日志系统
func readinessHandler(w http.ResponseWriter, r *http.Request) {
select {
case <-serverReady:
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
default:
w.WriteHeader(http.StatusServiceUnavailable)
w.Write([]byte("not ready"))
}
}Kubernetes 中 livenessProbe 和 readinessProbe 的参数差异直接影响 Go 服务行为
Go 程序没有 JVM 那样的 GC 暂停感知能力，probe 配置不当会导致误杀或雪崩。关键区别在于：livenessProbe 失败会重启容器，readinessProbe 失败只是摘流量 —— 两者不能共用同一 handler。
典型配置陷阱：
-
initialDelaySeconds: 5对 Go 服务往往不够：若主逻辑含 initDB()、loadConfig() 等同步耗时操作，5 秒内 handler 可能还没注册成功，probe 就已开始，直接触发重启循环 -
periodSeconds: 10+timeoutSeconds: 10是危险组合：HTTP handler 若因锁竞争卡住 10 秒，probe 超时后立即发起下一次请求，形成并发雪球 - 务必设置
failureThreshold: 3（默认是 3），避免单次网络抖动导致误重启
用 http.Server.Shutdown() 配合健康检查实现优雅终止
健康检查本身不解决进程退出问题，但它是优雅终止的前提。当 K8s 发送 SIGTERM 后，需先停止接受新请求（即让 readiness 变为 false），再等活跃连接关闭。
关键步骤：
- 用
sync.WaitGroup跟踪活跃 HTTP 连接数，在 handler 入口wg.Add(1)，deferwg.Done() - 在 shutdown 流程中，先关闭 listener，再调用
srv.Shutdown()，最后wg.Wait() - 健康检查 handler 必须响应
ctx.Done()：若 shutdown 已触发，/healthz 应立即返回 503，而不是等待 wg.Wait 完成
最容易被忽略的一点：Go 的 http.Server 默认不启用 SetKeepAlivesEnabled(false)，长连接可能拖慢 shutdown —— 生产环境建议显式关闭 keep-alive 或缩短 IdleTimeout。
