/health不能查数据库，因其失败会触发容器重启，一次网络抖动即导致雪崩；/readyz必须查依赖，因其失败仅剔除流量，需真实反映服务就绪状态。
为什么/health不能查数据库，而/readyz必须查
因为 Kubernetes 的 livenessProbe 和 readinessProbe 语义完全不同：前者失败会直接 kill 容器并重启，后者失败只从 Service Endpoints 剔除流量。如果把 DB 检查塞进 /health，一次网络抖动就触发误杀，形成雪崩。
-
/healthz只做三件事：确认http.Server还在 accept 连接、关键 goroutine 未 panic、内存/协程数未异常飙升 -
/readyz必须并发探测下游依赖，但每个检查项要独立设超时：db.PingContext(ctx)≤ 1s，redis.Client.Ping()≤ 500ms，HTTP 依赖用http.DefaultClient.Do(req.WithContext(ctx))控制总耗时 ≤ 3s - 别用
db.Ping()—— 它不走 context，连接池卡死时会永久阻塞；必须用db.PingContext()或执行轻量SELECT 1
如何避免健康检查 Goroutine 泄漏和响应超时
高频探活（如每 10 秒一次）下，每次都在 handler 里新建 context 并调用 db.PingContext() + redis.Ping()，不仅延迟高，还会对下游造成脉冲压力，且容易因超时未 cancel 导致 goroutine 泄漏。
- 启动一个后台 goroutine，按固定间隔（如 5s）执行全量依赖检查，结果缓存到
sync.Map或带读锁的 struct 中 -
/readyzhandler 只读缓存快照，不触发真实探测；缓存有效期建议设为检查间隔的 2–3 倍（如检查每 5s，缓存 10–15s） - 所有依赖检查必须用
errgroup.Group并发执行，任一失败立即返回503，不等其余项完成 - 禁止在 handler 里用
time.Sleep或无超时的http.Get—— 这类操作一旦卡住，整个探针就 hang 死
为什么健康端点必须用独立 http.Server
Docker 的 HEALTHCHECK 和 Kubernetes 的 livenessProbe 都是从宿主机 namespace 直连容器 IP:PORT，不经过任何中间件、反向代理或框架路由层。复用主服务 mux 极易被鉴权、CORS、日志中间件干扰，导致探针收不到响应或延迟超标。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 显式创建新
http.ServeMux，只注册/healthz和/readyz两个路径 - 用独立
http.Server绑定固定端口（如:8081），避免和主服务争抢 listen 地址 - 容器退出前必须
server.Shutdown(context.WithTimeout(...))等待健康 server 关闭，否则 SIGTERM 后探针仍可能收到 5xx - 别在
main()里直接http.ListenAndServe()—— 它会阻塞主线程，无法优雅关闭
响应体字段和状态码哪些不能省略
Kubernetes 默认只认 200 为健康，但 Consul、Nacos、Spring Cloud Gateway 等会解析响应体。返回 200 OK 却没 Content-Type: application/json，某些网关会拒绝转发；字段名大小写不统一或值非 "UP"，会导致注册中心判定为异常。
立即学习“go语言免费学习笔记（深入）”；
- 状态码必须是
200（健康）或503（不就绪），禁用500或502—— 这些会让 K8s 认为服务不可达而非暂时不可用 - 响应头必须含
Content-Type: application/json，否则部分 Ingress controller 会丢弃响应体 - JSON 至少含
status字段，值严格为"UP"或"DOWN"（小写，字符串，不是布尔值） - 推荐加
timestamp（RFC3339 格式）和service字段，便于日志追踪和多实例区分
