CPU高或内存涨主因是Goroutine泄漏、锁争用、GC频繁或字符串/日志滥用pprof需正确采样、选型并解读栈帧如30秒以上采样、top10定位业务函数、list查具体行号、heap需两次强制GC对比、goroutine需debug2全量查看、trace要缩放查STW和GC标记。直接结论CPU 高或内存涨90% 不是代码写得“慢”而是 Goroutine 泄漏、锁争用、GC 频繁或字符串/日志滥用pprof 不是“开了就能看出问题”关键在采样方式、profile 类型选择和看懂栈帧含义。怎么快速抓到真实 CPU 热点不是 runtime.futex 占比高就去改锁runtime.futex 或 runtime.mcall 在 top 里占比高大概率不是你业务函数慢而是 Goroutine 调度太密集——比如几千个 goroutine 卡在 channel receive 上或反复抢同一把 sync.RWMutex 写锁。真正该盯的是业务函数本身耗时而不是运行时调度开销? 必须采样 ≥30 秒go tool pprof http://localhost:6060/debug/pprof/profile?seconds30时间太短容易错过间歇性热点? 进入交互后先输 top10看排第一的是否是你的 handler、codec 或循环逻辑如果不是再输 top -cum 查调用链顶端? 用 list 函数名 定位到具体行号注意区分是函数内循环没退出还是调了 json.Marshal 这类反射-heavy 操作? 如果 web 生成的火焰图里大量扁平分支都指向 time.Now() 或 log.Printf别优化算法先删日志或换 zap.Sugar() 条件包裹heap profile 看不出泄漏因为你没对比 or 没强制 GC访问 /debug/pprof/heap 默认返回的是当前堆存活对象InuseSpace但若程序刚启动、GC 还没触发或对象刚分配还没被回收InuseSpace 可能很低——这不等于没泄漏。? 要确认是否泄漏必须做两次采集并对比 ○ 先请求一次 /debug/pprof/heap?gc1强制 GC 后采记下 InuseSpace ○ 过 30 秒再请求同地址若值持续上涨且无对应业务释放动作基本可定性为泄漏? 更准的方式是看累计分配go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap然后 top如果 strings.Builder.Write 或 encoding/json.(*encodeState).marshal 排前三说明高频拼接或序列化在不断 new 对象? 注意sync.Pool 缓存的对象不会出现在 heap profile 里但若 Pool 的 New 函数本身创建大对象如 bytes.Buffer 底层切片过大仍会推高 AllocSpacegoroutine 数量暴涨却查不到泄漏点debug2 是开关/debug/pprof/goroutine 默认只返回状态为 running 或明显阻塞如 chan send的 goroutine大量“活着但卡住”的会被过滤掉。? 必须加 ?debug2curl http://localhost:6060/debug/pprof/goroutine?debug2 goroutines.log才能看到完整栈和所有 goroutine 的当前 PC 地址? 重点关注状态字段含以下关键词的 goroutine ○ chan receivechannel 没人 close或 sender 已退出但 receiver 还在等 ○ selectfor-select 循环里缺 default 分支导致永远阻塞在某个 case ○ semacquiresync.Mutex 或 sync.WaitGroup 被某处 hold 住没释放? 如果数量随 QPS 线性增长立刻检查 HTTP client 是否设了 Timeout、DB query 是否漏了 rows.Close()、WebSocket 是否忘了 conn.Close()trace.out 里看不出 GC 影响因为没关注 STW 和标记阶段go tool trace trace.out 打开后“View trace” 页面默认缩放级别太粗GC 事件容易被忽略。? 点击右上角 “Find” → 输入 STW定位每次 Stop-The-World 时间点看是否超过 1msGo 1.22 目标是 sub-millisecond? 展开下方 “Goroutines” 行拖拽缩放至 10ms 级别观察 GC 标记GC mark assist 或 GC worker是否频繁抢占你的业务 goroutine? 若发现大量 goroutine 长时间处于 Runnable 状态黄色条但没执行绿色条说明 CPU 资源不足或调度器被 GC 压制若长时间 IOWait蓝色条则问题在下游依赖不是 Go 代码本身? trace 无法替代 pprof它只告诉你“这次请求为什么慢”而 pprof 告诉你“哪个函数长期吃 CPU”——两者要配合看不能只盯一个最常被跳过的一步pprof 采集前没确认应用是否真启用了 net/http/pprofimport 了但没调 http.ListenAndServe或监听地址绑在 127.0.0.1 却从容器外 curl结果连 404 都收不到——先 curl -v http://localhost:6060/debug/pprof/ 看能否返回 HTML 列表再动手分析。 Cleanup.pictures 智能移除图片中的物体、文本、污迹、人物或任何不想要的东西