cpu高时runtime.futex或runtime.mcall占比高，说明是goroutine调度密集或锁争用，而非业务代码慢；确认纯cpu密集需main.yourcomputefunc超80%且无runtime.gopark、gcmarkworker等干扰符号。
cpu 飙高时，pprof 抓到的 runtime.futex 或 runtime.mcall 占比高，基本不是你业务代码慢，而是 goroutine 调度或锁争用太猛——得先查 goroutine 数量和阻塞点，别急着优化函数。
怎么确认是真 CPU 密集，而不是被调度/IO/GC 伪装了
火焰图里如果 main.yourComputeFunc 占比 超过 80%，且几乎看不到 runtime.gopark、net/http.readRequest、gcMarkWorker 这类符号，才算纯计算瓶颈；否则大概率是假象：
-
runtime.gopark高 → goroutine 卡在 channel receive、mutex write、time.Sleep 等阻塞点 -
gcMarkWorker高 → GC 正在疯狂标记，看GODEBUG=gctrace=1日志里是否每秒多次gc 123 @45.67s -
net/http.readRequest高 → 真实瓶颈在 HTTP 解析或 TLS 握手，不是你 handler 逻辑
采样时间设多少才靠谱
别迷信“必须 30 秒”——关键看场景：
- 线上服务波动大：用
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30，但得确保这 30 秒内业务真实处于高峰 - 测试阶段更干净：直接
go test -cpuprofile cpu.out .，只抓测试执行期间的 CPU，没干扰 - 想抓瞬时峰值：在 handler 开头加
pprof.StartCPUProfile(f)，结尾pprof.StopCPUProfile()，手动控制边界 - 采 5 秒太短 → 容易漏掉周期性热点（比如每 10 秒跑一次的定时任务）
- 采 60 秒太长 → 可能混入空闲期，把真实热点稀释掉
top10 看到的不是业务函数，接下来怎么查
交互式分析里输 top10，结果全是 runtime.futex、runtime.mallocgc？说明问题不在单个函数耗时，而在调用模式或资源竞争：
- 先输
top -cum，看调用链顶端是谁触发了大量调度或分配 - 如果顶端是
http.HandlerFunc或你自己的 worker loop，再用list 函数名查具体哪行在反复调json.Marshal、strings.ReplaceAll或time.Now() - 火焰图里宽条集中在某一层？重点不是顶部函数，而是它被谁调了多少次——比如
processItem单次 0.1ms，但被for range items调了 10 万次，那瓶颈在循环结构本身 - 看到大量
log.Printf或fmt.Sprintf→ 别改算法，先删日志或换成zap.Sugar().Debugw(...)加条件包裹
goroutine 泄漏导致 CPU 飙高，怎么一眼识别
大量 goroutine 卡住不动，但仍在被调度器轮询，CPU 就会白耗在上下文切换上：
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2——debug=2是开关，不加默认只返回 running 或明显阻塞的 goroutine，漏掉大量“活着但卡死”的 - 看输出里有没有成百上千个 goroutine 堆在同一个位置：比如全卡在
select { case 、<code>sync.RWMutex.Lock或database/sql.(*DB).QueryRow - HTTP 客户端没设超时、for-select 漏写
default或case 、<code>sync.WaitGroup忘记wg.Done()，都是高频泄漏点 - 对比两次采集：
curl "http://localhost:6060/debug/pprof/goroutine?debug=2" > g1.txt，等 30 秒再抓一次g2.txt，diff g1.txt g2.txt看新增了哪些固定栈帧
真正难的是区分“CPU 高是因为算得多”，还是“因为调度太忙、锁太挤、GC 太勤、日志太多”——pprof 不是读数工具，是推理工具。火焰图里那一片扁平的 time.Now()，比任何算法优化都更值得先砍掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
