Kubernetes中Go服务健康检查必须分离/livez和/readyz端点：/livez仅检查进程存活且响应≤1秒，/readyz验证DB等真实依赖并设独立超时；探针参数须与代码超时严格对齐，避免CrashLoopBackOff。
直接上结论：Kubernetes 里为 Go 服务配健康检查，必须写两个独立 HTTP 端点（/livez 和 /readyz），再配两套探针参数，且 Go 代码里不能依赖全局 http.DefaultServeMux。光在 YAML 里加 livenessProbe 是没用的——K8s 不会“自动探测”，它只按你写的路径和状态码做判断；而 Go 服务若没暴露端点、或返回了 200 却没连上 DB，就会导致滚动更新卡死、Pod 反复 CrashLoopBackOff。
/livez 和 /readyz 必须拆开实现
混用一个 handler 是生产事故高频区。/livez 只检查进程是否活着（比如 goroutine 数量突增、主循环心跳是否更新），/readyz 才查真实服务能力（DB Ping、Redis 连接、下游 gRPC 健康状态）。
-
/livez响应必须 ≤ 1 秒，禁止任何外部调用；可用atomic.LoadInt32(&up)检查主 goroutine 是否 panic 后未重启 -
/readyz每项依赖检查都要带独立超时，例如ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond)，失败直接返回http.StatusServiceUnavailable - 别用
http.HandleFunc注册在默认 mux 上——第三方库（如promhttp.Handler()）可能悄悄覆盖路径；改用http.NewServeMux()显式绑定 - 响应体建议加 JSON，比如
{"status":"ok","timestamp":1712345678}，方便人工curl验证，也利于日志追踪
Kubernetes 探针参数必须和 Go handler 耗时对齐
常见错误是把 timeoutSeconds: 1 和一次 db.PingContext() 放一起——网络抖动时 P99 超过 1 秒，K8s 就判定失败并杀 Pod，形成自毁循环。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
-
timeoutSeconds至少设为最慢依赖的 P99 延迟（建议 ≥ 1.5 秒） -
initialDelaySeconds不能为 0：Go 服务启动后要加载配置、预热连接池，至少设10（liveness）和5（readiness） -
failureThreshold要防抖动：若periodSeconds: 5，建议设failureThreshold: 3，避免单次 DB 抖动就触发重启 - 两个探针路径必须严格匹配代码注册路径：
livenessProbe.httpGet.path: /livez对应 Go 里的mux.HandleFunc("/livez", livezHandler)
Gin/Echo 框架注册健康路由容易踩的坑
框架中间件（如 JWT 鉴权、日志、CORS）默认会拦截所有请求，导致 /livez 返回 401 或超时，K8s 直接判失败。
立即学习“go语言免费学习笔记（深入）”；
- Gin 中，健康路由必须在
r.Use()之前注册，或显式跳过：r.GET("/livez", livezHandler).SkipAuth = true（注意不是NoRoute） - Echo 中，用
e.GET("/readyz", readyzHandler).SkipMiddleware = true，不是Use().Skip - 别把
/metrics和/readyz放同一个 group 里——语义不同，共享中间件会导致指标采集被拖慢甚至失败 - handler 里禁止同步打日志、发 metric、做鉴权：高频探针（每秒数次）会撑爆日志卷或 Prometheus pushgateway
真正难的不是写两个 handler，而是每个依赖检查都得有超时、降级、独立失败标识，并确保 K8s 探针的 timeoutSeconds、periodSeconds、failureThreshold 和 Go 代码里 context 超时、重试逻辑严丝合缝——差 100 毫秒，高峰期就可能进 CrashLoopBackOff。
