ms.Alloc才是Go程序当前活跃堆内存字节数，而/proc/self/status中的VmRSS才反映真实物理内存占用；二者不可混用，前者不含栈、cgo、mmap等，后者是内核统计的物理页使用量。
Statsviz 不能替代你对 runtime.MemStats 和 /proc/self/status 的理解，它只是把已有数据画出来；想调优，得先懂哪些数字真正反映内存压力。
runtime.ReadMemStats(&ms) 返回的 ms.Alloc 才是你要盯的“活跃堆”
很多人误以为 ps aux 里的 RSS 或 top 的 RES 就是 Go 程序真实堆内存——不是。runtime.ReadMemStats 是唯一能拿到运行时精确堆快照的入口，其中 ms.Alloc 字段才是当前未被 GC 回收的活跃堆字节数。
-
ms.Alloc单位是字节，除以 1024 才是 KB；它不包含栈、cgo 分配、mmap 大块内存或 runtime 元数据 - 必须传非 nil 的
*runtime.MemStats指针，否则会 panic - 调用开销在微秒级，适合每 2–5 秒采集一次；但别塞进高频 HTTP handler 里
-
ms.Sys是向 OS 申请的总虚拟内存，不能代表物理占用，数值通常远大于ms.Alloc
/proc/self/status 中 VmRSS 才反映真实物理内存占用
runtime.ReadMemStats 说不清楚你的程序到底吃了多少物理内存。Linux 内核给出的真实物理页占用，在 /proc/self/status 的 VmRSS: 行里，单位 KB，和 ps -o rss= -p $PID 一致。
- 路径固定为
/proc/self/status，无需拼 PID - 需逐行扫描，匹配以
VmRSS:开头的行，再取第二个字段（注意空格分隔） - 容器环境（尤其是 rootless）可能因权限不可读，务必加 error fallback
- 不要每秒都读——频繁 syscall 会增加开销；建议与
runtime.ReadMemStats同步采样
Statsviz 只是把 runtime 数据推到浏览器，不是监控系统
statsviz 的核心逻辑很简单：起一个 WebSocket 服务（/debug/statsviz/ws），每秒调用 runtime.ReadMemStats 和 runtime.NumGoroutine()，把结果发给前端绘图。它不采集 VmRSS，也不做聚合、告警或持久化。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 注册方式只有两种：
statsviz.RegisterDefault()（走http.DefaultServeMux）或statsviz.Register(mux)（自定义 mux） - 默认路由是
/debug/statsviz/，页面依赖 WebSocket 实时推送，断网或防火墙拦截会导致图表停住 - 它不处理高并发采集压力——所有指标都来自单次
ReadMemStats调用，无缓存、无批处理 - 若你的服务没 HTTP，可单独启个
http.ListenAndServe，但得确保端口不冲突、路由不暴露公网
goroutine 泄漏比内存泄漏更容易被 statsviz 误导
statsviz 图表里 goroutine 数量曲线平滑上升，不代表真泄漏——它只展示 runtime.NumGoroutine() 的瞬时值。这个值跳变本身是精确的，但持续缓慢上涨才值得警惕。
- 常见卡点：阻塞在无缓冲 channel receive、
time.Sleep未被 cancel、等待context.Done()、syscall 未超时 - 健康检查接口中调用
runtime.NumGoroutine()是安全的；但别在每毫秒请求里调用 - 发现异常上涨，立刻用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看完整栈，比图表更准 -
statsviz不展示 goroutine 的阻塞原因，只给总数；别把它当 pprof 替代品
真正卡住的从来不是工具链，而是混淆 Alloc 和 RSS、把图表当因果、用 statsviz 当“已调优”证明。调优的前提，是知道哪个数字在说谎，以及为什么说谎。
