/livez 和 /readyz 必须监听独立端口：/livez 仅检查进程是否卡死（accept 状态、goroutine 数量），严禁外部调用；/readyz 读缓存验证依赖状态，响应需含 status 字段与正确 Content-Type。
/livez 和 /readyz 必须监听独立端口
共用业务 HTTP server 是最隐蔽的故障源：主服务 GC 停顿、锁竞争或请求积压时，/livez 可能卡住不响应，Kubernetes 就会反复 kill 重启 Pod——而其实 goroutine 还在跑。这不是服务挂了，是探针被拖垮了。
正确做法是用 http.NewServeMux() 新建专用 mux，启动独立 http.Server，监听如 :8081 这类非业务端口。Kubernetes 的 livenessProbe 和 readinessProbe 分别指向这个端口下的不同路径，彻底隔离业务逻辑、中间件和 panic 风险。
- 不要把
/livez挂在/api/healthz下，避免鉴权或日志中间件介入 - 禁用所有中间件（包括 CORS、JWT、request ID 注入）
- 独立端口还能防止业务路由 panic 导致整个 HTTP server 崩溃，让探针彻底失联
/livez 只做本地快照，严禁任何外部调用
/livez 的唯一职责是回答“进程是否卡死”，不是“DB 能不能连上”。一旦它去拨 Redis 或 DB，下游超时就会触发 Kubernetes 反复重启——默认 failureThreshold: 3，连续三次失败就杀 Pod，而网络抖动太常见了。
它该检查的只有三件事：HTTP server 是否还在 accept 连接、关键 goroutine 是否存活、runtime.NumGoroutine() 是否突增（建议阈值 ≤ 5000）。耗时超过 200ms 就该报警，而不是继续等。
- 绝对不调
db.PingContext()、redis.Ping()、grpcConn.GetState() - 不 new 任何 client 实例，不写日志到 stdout/stderr
- 禁止
log.Fatal、panic、os.Exit，它们会让探针直接断连
/readyz 必须查依赖，但只能读缓存结果
/readyz 决定流量是否进来，所以必须验证 DB、Redis、gRPC 等真实连通性；但它又不能每次请求都新建连接——高频 probe（比如每 2 秒一次）下，db.Ping() 会瞬间打爆连接池，甚至触发雪崩。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
解决方案是后台用 time.Ticker 每 5 秒执行一次全量探测，结果存进带 sync.RWMutex 保护的结构体；/readyz handler 只读缓存，不发新请求。每个依赖项必须设独立超时：db.PingContext(ctx, 2*time.Second)、redis.Ping(ctx).Err()、grpcConn.WaitForStateChange(ctx, connectivity.Ready)。
- 响应体必须含
status字段（值为"UP"或"DEGRADED"），不能只返回空 body - 必须设
Content-Type: application/json; charset=utf-8，否则 Traefik 等 Ingress 会截断响应 - 状态码永远是
200，503 是 Kubernetes 用来剔除 endpoint 的，不是你该返回的
Kubernetes 探针配置必须与语义对齐
YAML 写错等于白写健康接口。常见错误是两个 probe 指向同一路径、timeoutSeconds 设得比业务请求还短，或者 initialDelaySeconds 没给 DB 连接池 warmup 留时间。
生产配置应严格遵循：livenessProbe 用 /livez，initialDelaySeconds: 10，timeoutSeconds: 1；readinessProbe 用 /readyz，initialDelaySeconds: 15（留出初始化窗口），timeoutSeconds: 3。两者都设 periodSeconds: 5 和 failureThreshold: 3，避免网络抖动误判。
- 不要复用同一个健康路径，
livenessProbe和readinessProbe的语义正交，不可耦合 - exec 探针慎用，脚本里混用“端口监听”和“DB 连通性”会导致判断逻辑混乱
- 路径、端口、超时参数必须和 Go 代码中实际暴露的一致，差一个字符都会让探针静默失败
真正的难点不在写 handler，而在让所有环节——Go 代码、Kubernetes YAML、Ingress 控制器、监控告警——对同一个状态信号达成无歧义共识。一个没设 Content-Type 的响应，或 YAML 里少了一个 s（timeoutSecond → timeoutSeconds），就足以让整个健康机制失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
