Kubernetes健康检查需严格区分/livez和/readyz语义：/livez仅检测本地进程状态且响应≤1秒，禁用任何外部调用；/readyz须并行检查DB等依赖并缓存结果，失败必须返回503，路径与探针配置严格一致。
Go 健康检查不是加个 /health 返回 200 就完事——Kubernetes 会根据状态码和响应行为决定是否重启 Pod 或摘除流量，错配语义或阻塞逻辑，轻则误下线，重则雪崩。
为什么 /livez 绝对不能查数据库
查 DB 的 /livez 是“假活探测器”：DB 网络抖动 1 秒，livenessProbe 就失败，K8s 立刻 kill + restart 容器。而此时进程完全活着，只是依赖暂时不可用，反复重启反而压垮恢复路径。
-
/livez只检查本地状态：HTTP server 是否还在 accept 连接、runtime.NumGoroutine()是否突增（如 > 1000）、runtime.ReadMemStats().HeapInuse是否超阈值（如 > 500MB） - 禁用所有外部调用：
db.PingContext、http.Get、os.ReadFile、time.Sleep都不准出现 - 响应必须 ≤ 1 秒：初始化
http.Server时务必设ReadTimeout: 5 * time.Second和WriteTimeout: 10 * time.Second，防 GC STW 卡住探针
/readyz 怎么安全检查 DB 而不打爆连接池
高频轮询下每次调 db.PingContext 会新建连接，连接数飙升、超时堆积，甚至拖垮数据库。真正该复用的是连接池当前状态 + 轻量 SQL。
- 先快速过滤：
db.Stats().OpenConnections > 0，为 0 直接返回503 - 再执行轻量查询：
db.QueryRowContext(ctx, "SELECT 1").Scan(&dummy)，ctx必须带超时（如2 * time.Second），绝不用context.Background() - 所有依赖（DB、Redis、gRPC）必须并行执行，共用同一个
ctx，任一失败就整体返回503 - 别在 handler 里实时探测——启动后台 goroutine 每 5 秒检查一次，结果缓存在
sync.RWMutex保护的结构体中，/readyz只读快照
路由注册和中间件为什么必须绕开
健康端点一旦被日志、鉴权、CORS 等中间件拦截，就可能因中间件 panic、延迟抖动或 header 注入导致探针误判。K8s 不关心你有没有 X-Request-ID，只看状态码和 body 是否为空。
立即学习“go语言免费学习笔记（深入）”；
- 禁用全局
http.DefaultServeMux：用http.NewServeMux()创建独立实例，避免多包注册冲突 - 不走任何业务中间件链：
/livez和/readyz的 handler 必须是裸函数，不 import 业务包、不调os.Getenv、不读配置文件 - 确保响应非空：即使返回纯文本，也要写
w.Write([]byte("ok"))；部分旧版 kubelet 对空 body 判为失败 - 显式设
Content-Type：如w.Header().Set("Content-Type", "text/plain; charset=utf-8")，某些 Ingress 会因此截断响应
状态码写错一个字就等于主动下线
Kubernetes readiness 探针只认 HTTP 状态码，不解析响应体。返回 200 但 DB 已断连，等于把流量引向故障节点；误用 http.Error(w, "msg", http.StatusServiceUnavailable) 却没设状态码，Go 默认用 500，探针直接判定失败。
- 必须显式写
w.WriteHeader(http.StatusServiceUnavailable)，或确保http.Error第三个参数是目标码（如http.StatusServiceUnavailable） -
/livez失败用500，/readyz失败必须用503——这是 K8s 行为分界线 - 路径名无所谓是
/healthz还是/readyz，但 K8s YAML 中的readinessProbe.httpGet.path必须与http.HandleFunc注册路径严格一致 - handler 里禁止
log.Fatal、os.Exit或未 recover 的 panic，否则整个服务不可用
最易被忽略的是：所有依赖检查必须受统一 context 控制，并行执行；单个慢依赖卡住整个 /readyz，比不检查更危险。
