HTTP探针返回404是因为未注册对应路径的handler，Kubernetes探针默认请求/healthz或/live，需显式注册；健康状态只需返回2xx状态码（如200），不校验响应体；依赖检查应加超时并缓存结果，避免拖慢探针；initialDelaySeconds设为0会导致启动竞态而CrashLoopBackOff。
HTTP 探针用 http.ListenAndServe 时为什么返回 404？
Go 默认的 http.ServeMux 是严格匹配路径前缀的，但 Kubernetes 的 readiness/liveness 探针默认请求 /healthz 或 /live，如果没注册对应路由，就直接 404。不是服务没起来，是根本没配 handler。
- 必须显式调用
http.HandleFunc("/healthz", ...)或http.Handle("/healthz", ...) - 避免用
http.ListenAndServe(":8080", nil)启动后忘记注册 ——nil表示用默认 mux，但它空空如也 - 若用自定义
http.ServeMux，需传入http.ListenAndServe(":8080", mux)，不能漏掉第二个参数
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
})
http.ListenAndServe(":8080", mux) // 注意：第二个参数是 mux，不是 nil
}
探针逻辑该返回什么状态码才被 Kubernetes 认为“健康”？
Kubernetes 只看 HTTP 状态码：2xx 和 3xx 视为成功，4xx/5xx 视为失败。它不解析响应体内容，也不校验 JSON 结构。别在健康接口里返回 {"status":"healthy"} 还配个 200 —— 前者无意义，后者才关键。
-
http.StatusOK (200)是最稳妥的选择；http.StatusNoContent (204)也可，但需确保响应体为空（否则可能触发某些客户端重试） - 不要返回
302跳转 —— kubelet 不跟随重定向，会直接判为失败 - 数据库连通性检查失败时，应返回
http.StatusInternalServerError (500)，而不是200+ 错误文本
如何安全地做依赖检查（DB、Redis）而不拖慢探针？
健康探针必须快（通常 timeout 设为 1–3 秒），而 DB ping 可能因网络抖动卡住 5 秒以上，导致容器被误杀。不能把业务级连通性检查原样搬进 /healthz。
- 对 DB/Redis 使用带超时的上下文：
ctx, cancel := context.WithTimeout(r.Context(), 500*time.Millisecond) - 只检查连接池是否可获取连接（
db.PingContext(ctx)），不做真实查询 - 缓存最近一次检查结果（比如 3 秒内复用），避免每次请求都拨号 —— 用
sync.Once或简单时间戳判断即可 - 把耗时依赖检查移到
/readyz（就绪探针），而/healthz（存活探针）只做进程级检查（如 goroutine 数、内存水位）
为什么 livenessProbe 配了 initialDelaySeconds: 0 容器却一直 CrashLoopBackOff？
因为 Go 程序启动到 HTTP server 真正 bind 成功之间有延迟，哪怕只有几十毫秒。initialDelaySeconds: 0 会让 kubelet 在容器启动后立刻发第一个探针，此时 http.ListenAndServe 可能还没完成 listen，端口尚未 open，探针直接 connection refused，触发重启循环。
立即学习“go语言免费学习笔记（深入）”；
- 至少设
initialDelaySeconds: 5，给 Go runtime 和 TCP stack 缓冲时间 - 更可靠的做法是：在
main()中先net.Listen("tcp", ":8080")，确认端口可用再启 HTTP server，并用sync.WaitGroup或 channel 通知主 goroutine 已 ready - 避免在
init()里做任何阻塞操作（如加载大配置、初始化 DB 连接池）—— 它会拖慢整个启动流程
