process_resident_memory_bytes对长连接无效，因其仅反映整个go进程的常驻内存，无法定位到单个websocket/grpc stream的缓冲区、未释放channel、context携带大结构体等真实内存开销。
不能靠 go_goroutines 或 process_resident_memory_bytes 单独判断长连接内存开销——前者混杂 runtime 协程，后者是进程级快照，无法映射到单个 websocket/grpc stream 的真实内存占用。必须把连接生命周期、goroutine 数、堆对象数三者联动打点，并在连接关闭时验证内存是否回落。
为什么 process_resident_memory_bytes 对长连接无效
该指标反映整个 Go 进程的常驻内存，但长连接的真实开销往往藏在：缓冲区（如 bufio.Reader 的 4KB 默认 buffer）、未释放的 channel、context 携带的大结构体、或 handler 闭包意外捕获的请求数据。你看到内存从 120MB → 840MB，可能只是 500 个 WebSocket 连接各持有一个 1MB 的 map[string]*User 缓存，而 process_resident_memory_bytes 完全无法告诉你这些对象归属哪类连接。
常见错误现象：
- 压测后内存不降，但
go_goroutines已回落 → 实际是 map/struct 堆对象没被 GC，不是 goroutine 泄漏 - 同一服务不同实例内存差异大，但连接数一致 → 某些实例的 handler 闭包捕获了日志上下文或 trace span，导致对象逃逸到堆
-
pprof heap --inuse_space显示大量*bytes.Buffer或runtime.mspan→ 很可能是 gRPC streaming 中未设置MaxMsgSize，导致超大 payload 被缓存
必须用 GaugeVec 联动 goroutine 数与堆对象数
只跟踪连接数或只看全局内存，都会漏掉关键线索。真正可定位的指标组合是：
-
long_conn_goroutines{protocol="ws",status="active",path="/api/ws"}—— 精确到协议+路径的协程数 -
long_conn_heap_objects{protocol="grpc",status="streaming",path="/user.Stream"}—— 每类连接持有的堆对象数量（需用runtime.ReadMemStats+debug.GC差值估算） -
long_conn_buffer_bytes{protocol="http2",status="push"}—— 显式记录每个连接分配的bufio.Reader/Writer总大小
关键实操点：
- 标签必须收敛：
protocol、status、path是底线，禁用 client_id 或 session_token 等动态 label - 注册器隔离：每个指标都用同一个
prometheus.NewRegistry()，绝不用DefaultRegisterer - 更新时机要闭环：WebSocket 在
conn.SetCloseHandler里调用.Dec()后，立刻触发一次runtime.GC()并采样heap_objects差值，验证是否回落
Goroutine 创建时必须同步记录其内存足迹
很多团队只在连接建立时 .Inc()，却忽略该 goroutine 实际会分配多少内存。正确做法是在启动 goroutine 的瞬间，就把它关联的 buffer、channel、cache 都量化并累加到对应指标：
go func() {
// 记录该连接的初始内存 footprint
wsConnBufferGauge.WithLabelValues("ws", "active", "/api/ws").Add(float64(4096)) // bufio.Reader
wsConnHeapObjectsGauge.WithLabelValues("ws", "active", "/api/ws").Inc()
<pre class="brush:php;toolbar:false;">defer func() {
wsConnBufferGauge.WithLabelValues("ws", "active", "/api/ws").Sub(float64(4096))
wsConnHeapObjectsGauge.WithLabelValues("ws", "active", "/api/ws").Dec()
}()
for {
_, _, err := conn.ReadMessage()
if err != nil {
break
}
}}()
容易踩的坑：
- buffer 大小写死为 4096，但实际业务中可能用
bufio.NewReaderSize(conn, 64*1024)→ 必须从构造参数动态读取 - channel 缓冲区未计入：如
ch := make(chan *Event, 100)，每个*Event平均 2KB，则需额外.Add(200 * 1024) - goroutine 退出前未
close(ch)，导致 channel 底层hchan结构体长期驻留堆 → 这类泄漏在pprof heap --inuse_space里表现为大量runtime.hchan
最易被忽略的是：goroutine 退出 ≠ 内存释放。一个长连接 goroutine 可能已结束，但它创建的 channel、timer、或闭包捕获的 struct 仍被其他 goroutine 引用。务必在连接关闭路径上，用 runtime.ReadMemStats 对比前后 HeapObjects 和 HeapInuse，否则监控永远停留在“连接数正常”的假象里。
