Go HTTP服务中应为/healthz和/readyz使用独立ServeMux或路由器，/healthz仅做无IO、无锁的本地状态检查（如原子标志位），/readyz需对各依赖走最小可行路径检查并设独立超时，且必须绕过鉴权等中间件。
Go HTTP 服务里怎么加 /healthz 和 /readyz 路由
直接注册两个 http.HandleFunc 就行，但别用 http.DefaultServeMux —— 它全局共享，微服务里多个包可能偷偷往里塞路由，冲突难排查。用独立的 http.ServeMux 或第三方路由器（比如 chi）更可控。
常见错误是把健康检查写成阻塞式逻辑：比如在 /readyz 里同步调用数据库 Ping()，结果 DB 慢一点，整个探针超时，K8s 就杀 Pod。必须设超时，且用非阻塞方式检查依赖。
-
/healthz只做本地状态检查（如 goroutine 数量、内存使用率），不连外部服务 -
/readyz检查依赖是否就绪（DB 连接池、Redis、下游 gRPC 服务），每个依赖单独超时控制 - 返回状态码严格用
200（就绪）或503（未就绪），K8s 不认其他码
Liveness 探针为什么总被误判为失败
根本原因是把 /healthz 当成了“进程还活着就行”，结果它实际做了耗时操作。Liveness 触发后 K8s 会直接重启容器，如果探针本身慢或不稳定，等于人为制造雪崩。
典型坑：在 /healthz 里读配置文件、查本地磁盘、甚至调用 runtime.NumGoroutine() 配合复杂判断逻辑。这些看似轻量，但在高并发或 GC 停顿时可能卡几十毫秒，而 K8s 默认 liveness probe timeout 是 1 秒，failureThreshold 是 3 次——三次卡住就重启。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只检查进程基础状态：
atomic.LoadInt32(&isRunning)这种无锁标志位 - 绝对不要 IO、网络、锁竞争、GC 敏感操作
- 如果真要加指标，用预计算缓存值，每秒异步更新一次，探针只读缓存
Readiness 探针返回 503 但服务明明能处理请求
这通常是因为 readiness 逻辑和真实流量路径没对齐。比如你检查了 DB 连接池有空闲连接，但没检查连接是否还能执行 SELECT 1；或者检查了 Redis Ping() 成功，但没验证是否能 SET 带过期时间的 key。
另一个高频问题是 readiness 状态没及时更新。例如服务启动时 DB 连接失败，/readyz 返回 503；后来 DB 恢复了，但 readiness 标志位没重置，一直卡在不可用状态。
- 每个依赖检查必须走最小可行路径：DB 用
db.QueryRow("SELECT 1").Scan(&val)，不是db.Ping() - 用原子变量或带锁状态机管理 readiness 全局状态，DB 恢复后主动触发
atomic.StoreInt32(&ready, 1) - K8s 的
initialDelaySeconds别设太小，留给服务完成初始化和依赖探测的时间
用 Gin/Echo 等框架时怎么避免中间件干扰探针
很多团队给所有路由加了统一日志、鉴权、跨域中间件，结果 /readyz 也被拦下来打日志、校验 token，既没必要又拖慢响应。更糟的是某些鉴权中间件遇到无 token 直接返回 401，探针就永远 503。
框架默认把健康路由当成普通请求处理，中间件链全跑一遍。必须显式跳过。
- Gin：用
router.NoRoute()之前注册/healthz，或用gin.New()单独起一个无中间件的引擎 - Echo：用
e.GET("/readyz", readyHandler).SkipMiddleware(true)（需 Echo v4.9+） - 最稳做法：健康路由不走主框架，用
http.ListenAndServe单独起个http.Server绑定:8081，完全隔离
真正难的不是写几个 HTTP handler，而是让每个探针的语义和 K8s 的调度行为严丝合缝：liveness 必须快而 dumb，readiness 必须准而细，且两者状态更新时机不能有竞态。线上出问题时，90% 是因为 readiness 检查漏了某个依赖的真实可用性，而不是代码没写对。
