Kubernetes本身不分析内存泄漏，仅依据探针返回的状态码和响应时间执行动作；所谓“因内存泄漏触发健康检查失败”，实为用户在/livez等探针中主动嵌入runtime指标判断并返回非200状态，kubelet据此执行重启。
为什么Kubernetes不会直接“识别”内存泄漏
Kubernetes 本身不分析 Go 程序的堆内存、goroutine 数量或 GC 压力。它只看探针返回的状态码（比如 http.StatusServiceUnavailable）和响应时间。所谓“因内存泄漏触发健康检查失败”，其实是你主动在健康 handler 里加了内存相关的快照判断，并让它在异常时返回非 200 ——K8s 只是忠实地执行了这个结果。
/livez 必须包含 runtime 内存与 goroutine 快照
内存泄漏早期往往表现为 goroutine 持续增长、heap alloc 持续上升，但 HTTP server 还能响应。这时候 /livez 是唯一能提前预警的端点。别只写 return http.StatusOK。
- 用
runtime.NumGoroutine()：若超过阈值（如 5000），返回 503；注意避免误判初始化阶段的临时高峰 - 用
runtime.ReadMemStats(&m)检查m.Alloc或m.HeapInuse是否持续增长（比如 30 秒内上涨 >30%），需缓存上一次采样值 - 检查
runtime.GCStats().LastGC时间戳是否太久（如 >5 分钟），可能说明 GC 被阻塞或 STW 过长 - 所有判断必须带超时（
context.WithTimeout(r.Context(), 300*time.Millisecond)），不能让探针卡住
健康检查返回 503 后，Kubernetes 实际做了什么
如果 livenessProbe 指向 /livez 并持续收到 503，kubelet 会按配置执行重启 ——但这不是“修复内存泄漏”，只是把泄漏进程干掉，靠新实例重置状态。所以必须配对使用：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
livenessProbe指向/livez，failureThreshold: 3+periodSeconds: 10，避免单次 GC 暂停误杀 -
readinessProbe仍指向/readyz，且不检查内存，只查依赖连通性；否则滚动更新时可能全量摘流 - 镜像中必须禁用
GODEBUG=madvdontneed=1（Go 1.22+ 默认开启），否则 RSS 上升不明显，m.Alloc却已暴涨，导致漏判
容易被忽略的信号：/livez 不该有日志、不该打指标、不该写磁盘
内存紧张时，任何额外开销都可能压垮服务。你在 /livez handler 里调用 log.Printf、写 Prometheus counter、甚至 JSON 序列化整个 MemStats，都会分配新内存、触发 GC、加剧抖动。
- 响应体保持极简：
"livez: ok"或{"status":"ok","goroutines":4211}，字段严格控制 - 禁止在 handler 里 new struct、调用 fmt.Sprintf、做 map 遍历 —— 全部预分配或用 sync.Pool
- 不要复用业务用的
http.Client或sql.DB，/livez必须零外部依赖
真正难的不是“检测到内存涨了”，而是让检测动作本身不成为内存泄漏的新源头。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
