确认内存泄漏需抓两次/debug/pprof/heap?gc=1快照对比，看火焰图红色新增驻留对象；同步观察runtime.NumGoroutine()是否爬升，并检查heap_alloc与heap_inuse差值是否持续扩大；alloc_space比inuse_space更能暴露高频分配源头。
线上 Kratos 服务内存持续上涨、GC 后水位不回落，基本可以判定存在内存泄漏——但 runtime.mallocgc 高不等于泄漏，inuse_space 稳定也不代表安全，关键得看对象是否被意外长期持有。
怎么确认是泄漏而不是分配抖动
别只盯 Grafana 上的“内存使用量”曲线。Kratos 场景下真正有效的判断依据是：
- 用
curl -s http://127.0.0.1:6060/debug/pprof/heap?gc=1抓两次快照（间隔 5–10 分钟），执行：go tool pprof --base base.heap.pprof current.heap.pprof，火焰图中红色区块才是新增驻留对象 - 观察
runtime.NumGoroutine()是否同步缓慢爬升——协程泄漏常伴随内存泄漏，尤其当泄漏源是未关闭的流或缓存闭包时 - 检查 GC 日志里
heap_alloc和heap_inuse的差值是否越拉越大：如果heap_alloc每次 GC 后都比上次高 20MB+，且heap_inuse不回落，就是典型泄漏信号
pprof 路由 404 或返回空？注册方式错了
Kratos 默认不自动挂载 /debug/pprof，光 import _ "net/http/pprof" 没用。常见错误有：
- 用了
http.NewServer并传入了自定义http.ServeMux，但没手动注册 handler：
必须显式调用pprof.RegisterHandlers(mux)（Kratos v2.7+）或逐个挂载：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index)) - debug server 绑定了
0.0.0.0:6060，被安全策略拦截；应改用127.0.0.1:6060，并通过反向代理（如 Nginx）做白名单访问控制 - 中间件拦截了所有
/debug/路径（比如统一鉴权 middleware），需在 middleware 中放行该路径前缀
heap profile 里全是 Kratos 函数名，怎么定位业务代码
看到 transport/http.(*Server).ServeHTTP、encoding/json.(*decodeState).object、middleware/tracing.(*Tracer).Trace 占比高，别急着怀疑框架——它们只是“经手人”，泄漏点往往藏在你传进去的东西里：
- 检查所有
context.WithValue调用：尤其是把大结构体、切片、map 甚至 *sql.DB 塞进ctx，且生命周期跨 HTTP 请求 → 这些值会随请求上下文一起存活到 response 写完，极易堆积 - 查中间件里是否启了 goroutine 但没监听
ctx.Done()：比如日志异步上报、指标采样，一旦请求提前 cancel，goroutine 就卡在 channel receive 或 sleep，连带捕获的局部变量全悬停 - 盯第三方缓存封装（如
bigcache、ristretto）：确认MaxEntrySize和HardMaxCacheSize设了硬限制，且 key 不含 request ID、traceID 等无限增长字段
为什么 alloc_space 比 inuse_space 更有用
inuse_space（默认）只反映当前堆上还活着的对象大小，对 Kratos 这类高频短生命周期分配的服务意义有限；alloc_space 统计的是整个采样期间的累计分配量，更能暴露“谁在疯狂 new”：
- 执行：
go tool pprof -sample_index=alloc_space heap.pprof，再top，排序靠前的函数若集中在你的 handler、middleware 或 dao 层，就非常可疑 - 特别注意
make([]byte, ...)、strings.Builder.Grow、json.Unmarshal后的赋值操作——这些本身合法，但如果结果被塞进全局 map 或 context，就会从“临时”变“永久” - 对比两次
alloc_spaceprofile：若某业务函数的分配量在第二次快照中翻倍，而它本不该处理更多请求（QPS 稳定），那几乎可以锁定为泄漏源头
最易被忽略的一点：Kratos 的 app.Run() 结束时，不会自动 stop 任何你手动起的 time.Ticker、http.Client.Transport 或 gRPC stream，这些 goroutine 及其捕获的变量会一直活到进程退出。线上排查时，先扫一遍所有 go func() { ... }() 和 time.NewTicker 调用点，确认都有对应的 stop/cancel 逻辑。
