RSS疯涨但HeapAlloc几乎不涨，是因为HeapAlloc仅统计Go堆中存活对象，而RSS包含未归还OS的内存、timer闭包、CGO、mmap等堆外内存；常见诱因是time.After或http.Client超时未Stop，致timer及闭包变量无法GC。
为什么 RSS 疯涨但 HeapAlloc 几乎不涨？
这是 Go 应用在 K8s 里 OOM 的典型错觉：runtime.MemStats.HeapAlloc 只统计 Go 堆上被分配且尚未回收的对象，而 RSS 是进程实际占用的物理内存页——包括未归还给 OS 的释放内存、timer 和 net.Conn 等 runtime 内部结构、CGO 分配、以及 mmap 映射的 slab 内存。
最常见诱因是：time.After、time.NewTimer 或 http.Client 超时未显式停止，导致底层 timer 永久挂在 runtime 全局链表上，闭包变量无法 GC，RSS 持续累积。
- 每次
select中写都新建一个 <code>Timer，即使超时未触发，它也一直活在 timerBucket 里 - Go GC 不会主动把空闲内存页交还 OS，除非触发
runtime/debug.FreeOSMemory()（不推荐）或满足内存压力阈值 - Linux cgroup v1 的
kmem子系统存在已知泄漏 bug（尤其 3.x/4.x 内核），container_memory_kmem_usage_bytes异常增长却不出现在 Heap Profiling 中
怎么用 pprof 快速定位 Go 内存热点？
别等 OOM 后再抓，要在 Pod 还活着、RSS 刚过 limit 70% 时就导出 heap profile。关键是抓 alloc_space 而非 inuse_space，因为泄漏往往藏在高频分配但未释放的路径里。
操作步骤：
- 确保服务启用了
net/http/pprof，且端口（如6060）在容器内监听并暴露到 Pod 网络 - 执行端口转发：
kubectl port-forward pod/<pod-name> 6060:6060</pod-name> - 抓取分配空间快照：
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap - 进入交互模式后，输入
top20 -cum查看累计分配量最高的调用栈
若发现 time.After、time.NewTimer、net/http.(*Transport).getConn 占比异常高，基本可锁定泄漏源头。
Go 应用内存配置和运行时参数怎么设才靠谱？
K8s 里 Go 应用的 memory.limit 不是随便拍的数字，它直接决定 GC 行为和 OOM 风险边界。
- 设置
GOMEMLIMIT（Go 1.19+）：比如GOMEMLIMIT=1.8GiB，让 Go 运行时主动控制堆上限，避免 RSS 突破 cgroup limit - 慎用
GOGC：默认100在低内存限制下易引发 GC 风暴；若 limit 为2GiB，可设GOGC=50提前回收，但需监控 GC CPU 开销 - 资源 requests/limits 建议：requests = 基线 RSS（压测 P95），limits = requests × 1.3～1.5；不要让 limits 过小（如
512MiB）又跑高并发 goroutine - HTTP 客户端必须复用：
http.DefaultClient默认无连接池限制，务必自定义http.Transport并设置MaxIdleConns、MaxIdleConnsPerHost
排查时最容易忽略的三个点
很多团队花半天查代码，最后发现败在基础设施层。
-
cgroup.memory=nokmem启动参数没加：老内核（尤其是 CentOS 7 / RHEL 7）的kmemleak 会让container_memory_kmem_usage_bytes持续上涨，pprof完全看不到，journalctl -k | grep "oom-kill"却频繁报Memory cgroup out of memory - 没检查
--previous日志：OOM 后重启的 Pod 日志是空的，必须用kubectl logs <pod> --previous</pod>才能看到崩溃前最后一段内存行为 - 误信
kubectl top pod：它显示的是 cgroup accounting 数据，含 page cache，不是应用真实堆内存；真要对比，得用container_memory_working_set_bytes（working set）而非container_memory_usage_bytes
