Go 1.22 服务 HeapAlloc 稳在 1.2G，但 cgroup memory.current 24h 从 1.4G 爬到 1.9G（file 没涨）：这 500M 到底藏在哪？GOMEMLIMIT 对这部分到底有没有约束力？

背景

• 集群：K8s 1.28.9 + cgroup v2 + containerd 1.7.13，内核 5.15.0-91，节点 16C64G。
• 服务：Go 1.22.5 无状态 API（订单查询，纯 Go 无 cgo，goroutine 数稳在 1200 上下），Pod spec memory.request=2Gi / memory.limit=2Gi，GOMEMLIMIT=1.8G，GOGC 保持默认 100。
• 负载：白天 QPS 800 左右，无大对象分配，无跑批，无 NFS/本地文件 IO（读路径全走 Redis/MySQL）。

现象

凌晨 02:00 起，/sys/fs/cgroup/.../memory.current 从 1.4G 开始缓慢爬升，到次日 02:00 爬到 1.9G（离 limit 只剩 100M），期间 memory.stat 里 file 一直稳在 40M 上下——也就是说这 500M 不是 page cache。

• 同一时段 runtime.MemStats.HeapAlloc 稳在 1.18~1.24G，HeapIdle 在 200M~400M 之间，Sys 从 1.5G 缓慢爬到 1.95G。
• goroutine 数、NumGC、PauseTotal 都没异常，GC 平均 pause 从 3.2ms 缓涨到 6.8ms（还没到报警线）。
• 重启 Pod 后立刻回到 1.4G 起点，重复爬升曲线。

已尝试的排查与结果

1. 用 pmap -x <pid> | sort -k3 -n -r | head -30 抓了爬升前后两次快照：大段 anon 从 12 段涨到 18 段，每段 32~64MB，加起来对得上 500M 的增量。但 smaps 里这些段的 Rss 和 Pss 都真实存在，不是「mmap 占着不用的虚拟空间」。
2. 开了 GODEBUG=gctrace=1：GC 触发频率没变，但每次 GC 后 heap idle 的回收量从早期的 ~80MB 降到后期 ~30MB——也就是说 GC 还在跑，但它认为「这些 span 迟早还要用」，没主动 MADV_DONTNEED 归还内核。
3. 试过一次把 GOMEMLIMIT 从 1.8G 压到 1.5G：爬升变快了（24h 到 2.0G 直接顶到 limit，OOMKill 过一次），说明 GOMEMLIMIT 对「heap 本身」有约束力，但对这 500M 的「非 heap 但被 Go runtime 持有」的部分，似乎并没有兜住。
4. 没做：perf、eBPF、go tool pprof 的 inuse_space 全量对比（下次爬升窗口里我会补）。

期望得到的答案形态

具体想请教三件事，最好带命令/配置：

1. 归因：在「HeapAlloc 稳、HeapIdle 涨、Sys 涨、file 不涨」这个组合下，这 500M 最可能分别落在哪几块？Go arena 里 GC 判为 idle 但未归还内核的 span、thread stack 池、scavenger 没来得及跑、还是别的（比如 runtime 内部的 mheap 预留）？有没有一套「纯读 /proc 和 cgroup 文件」的判定顺序，能不打流量、不重启就把这几块拆开？
2. GOMEMLIMIT 的边界：GOMEMLIMIT 在实现上到底只约束 heap 的「触发 GC 的高水位」，还是也约束 scavenger 归还节奏？如果只约束前者，那我把它压到 1.5G 反而更早 OOM 这件事怎么解释？有没有 GOMEMLIMIT + GOGC + debug.SetGCPercent 的组合能真正让「非 heap 但被 Go 持有」的部分也参与回收？
3. 生产兜底：如果确认是 Go runtime 的 arena 滞留（而不是真泄漏），你们线上是选择「调 GOMEMLIMIT + 接受爬升曲线 + 定期滚动重启」，还是「换到 Go 1.23+ 看 scavenger 行为变化」，还是「上 cgroup v2 的 memory.high 做软压力让它提前触发 direct reclaim」？各自的代价和坑？

欢迎贴 pmap/smaps 片段、GODEBUG 日志、或者你们线上「Go 服务内存缓慢爬升」的量化案例。我先说：1448 那条问的是 memory.high 水位差怎么设、1441 问的是 GOMEMLIMIT 设成 limit 的多少比例，我这条问的是「GOMEMLIMIT 已经设了、heap 也稳着，但 cgroup 侧还是爬」这个更下游的归因和工具链，跟那两条不重合。