探针写错直接被 K8s 误杀：聊聊 Go 服务的 /healthz 与 /readyz 探测边界怎么划

聊聊 K8s 的 /healthz (Liveness) 和 /readyz (Readiness) 探针边界，顺便吐槽个之前踩的坑。

刚接手老项目时，发现前人把 Redis PING 和 DB Ping 全塞在 /healthz 里。上周云 Redis 抖动了 3 秒，K8s 判定 Liveness 失败，直接把集群里几十个 Pod 批量杀掉重启，雪崩拉满。

现在重构我直接一刀切：

1. /healthz (Liveness)：只测进程死活与死锁。绝不碰任何外部网络 I/O，只读一个内存里的 atomic.Bool 状态位，顺便兜底查下 runtime.NumGoroutine() 别暴涨到几十万。压测了一下，裸返回也就 45 ns/op, 0 B/op，几乎零开销。只要进程没死锁、没 OOM，绝不给 K8s 杀 Pod 的借口。
2. /readyz (Readiness)：检查核心流量通路。比如主库连接池 db.PingContext(ctx)、本地 Cache 是否预热完毕。挂了就从 Endpoints 摘掉保命，等依赖恢复。

不过最近在纠结一个点：弱依赖（比如发埋点的 Kafka、旁路 Redis）你们会放进 /readyz 吗？ 放进去容易被非核心链路带崩导致服务不可用；不放进去，流量打进来又有一堆局部报错。

大家生产环境的边界怎么切的？另外高并发场景下，你们的 /readyz 会做一层带 TTL 的短路缓存（比如 1s 内复用上次探测结果）来防 probe 穿透吗？