生产环境必须用http.NewServeMux()创建独立实例注册/healthz和/readyz，避免DefaultServeMux冲突及中间件污染；需绑定独立端口（如:8081），响应非空body并显式设状态码。
用 http.ServeMux 显式注册健康路由，别碰 DefaultServeMux
多人协作或模块化项目里，直接调用 http.HandleFunc 会往全局 http.DefaultServeMux 写路由，不同包注册同路径（比如都注册 "/healthz"）会导致 panic。生产环境必须用 http.NewServeMux() 创建独立实例，再传给 http.Server。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 主服务和健康检查用两个分离的
http.ServeMux实例，避免中间件污染 - 健康 mux 只注册
"/healthz"和"/readyz"，路径不带前缀（如不要"/api/health"） - 启动时显式传入：
http.Server{Addr: ":8081", Handler: healthMux}，而非http.ListenAndServe
gin/echo 等框架里怎么绕过中间件注册健康端点
框架默认路由链（如 gin 的 Use()、echo 的 MiddlewareFunc）会把日志、鉴权、CORS 全套加到健康 handler 上——这会让一个 JWT 失效直接导致整个服务被下线。必须剥离中间件。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- gin：不用
r.GET("/healthz", ...)，改用gin.New().NoRoute(...)或直接http.ServeMux启独立 server - echo：不走
e.GET("/healthz", ...)，而是http.Handle("/healthz", http.HandlerFunc(...))并起新http.Server - 验证方式：用
curl -v http://localhost:8081/healthz，确认响应头没有X-Request-ID、WWW-Authenticate等业务字段
监听地址必须独立，别复用主服务端口
Docker 的 HEALTHCHECK 或 Kubernetes 的 livenessProbe 是从宿主机网络 namespace 直连容器 IP+端口，它不经过任何反向代理、Ingress 或框架路由栈。如果只在主服务 :8080 上挂 "/healthz"，但没确保该路径实际可被外部访问（比如被 nginx 重写、被 istio sidecar 拦截），探针就会超时失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 健康检查起单独
http.Server，绑定固定地址如":8081"，和主服务端口物理隔离 - Dockerfile 里加
EXPOSE 8081，K8s YAML 中livenessProbe.httpGet.port对应填8081 - 主服务
http.Server初始化时务必设ReadTimeout: 5 * time.Second和WriteTimeout: 10 * time.Second，防 GC STW 卡住整个端口
框架配置里最容易漏掉的三件事
很多团队在框架里配完路由就以为完事了，结果上线后 K8s 频繁重启 Pod。核心问题不在代码逻辑，而在配置层缺失关键约束。
必须检查：
-
livenessProbe和readinessProbe的path字段，是否和http.HandleFunc注册的路径**严格一致**（大小写、尾部斜杠、编码） - 所有健康 handler 必须写非空 body：
w.Write([]byte("ok"))或json.NewEncoder(w).Encode(...)，空响应会被某些 kubelet 版本判为失败 - 就绪检查失败时，必须显式调用
w.WriteHeader(http.StatusServiceUnavailable)，不能只靠http.Error(w, "", http.StatusServiceUnavailable)——Go 默认 fallback 到 500
健康检查不是“能返回 200 就算通”，而是每个字节、每个 header、每个 timeout 都得对齐基础设施的预期。最常出问题的地方，永远是路径名拼错、状态码没显式写、或者把 /readyz 塞进了带鉴权的路由链里。
