K8s健康检查需分离liveness（只查进程状态，如goroutine数）和readiness（查DB/Redis等真实依赖），路径必须独立（如/livez与/readyz），用独立ServeMux避免冲突，probe timeout≥依赖P99，禁用日志/metric同步打点，建议绑定独立端口。
Go HTTP健康检查接口怎么写才不被K8s误杀
直接返回 200 OK 不够——K8s的 livenessProbe 和 readinessProbe 会按不同逻辑反复调用，接口必须区分“进程活着”和“服务可服务”。写成一个空 http.HandleFunc("/healthz", ...) 是常见错误起点。
关键区别在于：liveness 检查应只确认进程未卡死（比如 goroutine 泄漏、死锁），不碰外部依赖；readiness 必须验证数据库连接、下游API、本地缓存加载状态等真实服务能力。
-
liveness接口建议只检查内存分配速率、goroutine 数量突增、自定义心跳 tick 是否正常 -
readiness接口里不要做耗时操作（如重试3次连DB），超时应由 probe 自身控制（timeoutSeconds），不是 handler 里硬等 - 两个接口共用同一路径（如都用
/healthz）会导致 probe 行为混乱，必须拆开：例如/livez和/readyz
为什么 net/http.ServeMux 无法满足 probe 路由隔离需求
默认 http.DefaultServeMux 是全局单例，所有 http.HandleFunc 注册都挤在一起。一旦某人不小心注册了 http.HandleFunc("/readyz", ...)，又在另一个包里重复注册同路径，后者会静默覆盖前者——K8s 的 readinessProbe 就可能调到一个没做 DB 检查的空实现。
更危险的是，如果项目用了第三方中间件（比如 prometheus 的 /metrics handler），它也可能无意中劫持 /healthz 路径。
- 用独立
http.ServeMux实例，分别挂给liveness和readiness子服务，互不干扰 - 避免使用
http.HandleFunc，改用http.NewServeMux()+srv.Handler = mux显式绑定 - 路径注册前加运行时校验：
if mux.Handler(http.Request{URL: &url.URL{Path: "/readyz"}}).ServeHTTP != nil { panic("duplicate /readyz") }
Readiness 检查里连 MySQL 总是超时失败怎么办
不是代码写错了，而是 probe 配置和 handler 实现没对齐。K8s 默认 timeoutSeconds: 1，而 Go 的 sql.Open 不建立真实连接，db.Ping() 才真连——但一次 Ping() 在网络抖动时很容易超过 1 秒。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
更糟的是，如果 handler 里写了 db.PingContext(ctx, 5*time.Second)，而 K8s 只给 1 秒，那 Go 还没来得及返回就已被 kill，容器反复重启。
- probe 的
timeoutSeconds必须 ≥ handler 内最慢依赖的 P99 响应时间（建议至少设为 3） - handler 中不要用
context.WithTimeout套一层比 probe 更短的 timeout，这只会制造“假失败” - MySQL 检查应复用已有连接池，避免每次新建连接；可用
db.Stats().OpenConnections辅助判断连接池是否已初始化 - 若依赖多个组件（DB + Redis + gRPC），任一失败就返回
503，不要聚合所有错误再返回——延迟高且难定位
如何让健康检查不拖慢主服务吞吐量
高频 probe（比如每秒一次）打到同一个 handler，如果里面做了日志、metric 打点、或锁竞争，会显著抬高 p99 延迟。线上曾见过因 log.Printf("readyz: ok") 触发 stdout 锁争用，导致主请求平均延迟从 12ms 涨到 47ms。
这不是小题大做——probe 请求虽轻，但它是全量流量的固定倍数（如每秒 1 次 × 100 个 Pod = 每秒 100 次），放大效应极强。
- 健康检查 handler 禁用所有非必要日志，连
zap.Info都不该有；可用atomic.LoadUint64(&readyzCounter)计数替代 - metric 上报走异步 channel，不要在 handler 里直接
promhttp.Handler().ServeHTTP - 避免在 handler 里用
time.Now()或runtime.NumGoroutine()——它们在高并发下有可观开销，用预计算+定期更新的变量代替 - 把
/livez和/readyz绑定到独立端口（如:8081），和主业务端口分离，彻底规避锁和连接队列干扰
真正麻烦的从来不是写一个 200 返回，而是让这个 200 在容器漂移、网络分区、依赖抖动时依然可信——它得轻得像空气，又得准得像探针尖端。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
