确认纯CPU密集需看pprof火焰图中main.yourComputeFunc占比＞80%，且runtime.futex、net/http.readRequest几乎不出现；若runtime.gopark或gcMarkWorker频繁出现，则非真CPU瓶颈，需排查阻塞或GC问题。
怎么确认是纯CPU密集，而不是被IO或GC伪装了？
直接看 pprof 火焰图里 main.yourComputeFunc 占比是否压倒性（＞80%），同时 runtime.futex 和 net/http.readRequest 几乎不出现；如果 runtime.gopark 或 gcMarkWorker 频繁现身，说明不是真CPU瓶颈——前者暗示 channel 阻塞或锁等待，后者说明 GC 在抢时间。用 GODEBUG=gctrace=1 启动程序，看日志里有没有密集的 gc 123 @45.67s 0%: ...，有就先调 GOGC 或检查对象逃逸。
pprof采集必须等30秒？不一定，但别贪快
采样时间太短（比如 ?seconds=5）容易漏掉周期性热点；太长（＞60秒）又可能混入空闲期噪声。真实场景中，更稳妥的做法是：在业务逻辑刚进入计算高峰时手动触发采集——比如在 HTTP handler 开头加 pprof.StartCPUProfile(f)，处理完立刻 StopCPUProfile()。测试阶段则优先用 go test -cpuprofile cpu.out .，它只抓测试执行期间的 CPU，干净利落。
火焰图里看到宽条，下一步不是改代码，而是查调用链深度
常见错误是盯着顶部函数猛优化，结果发现它只是被上层循环反复调用。重点看纵轴：从 main 往下，哪一层开始“突然变宽”？比如 processItem 单次不慢，但被 for range items 调了 10 万次，那问题在循环结构，不在函数本身。用 list processItem 进入交互模式，看是不是某行 json.Marshal 或 strings.ReplaceAll 在每一迭代都分配新内存——这种就该提出来做缓存或复用。
worker pool不是万能解药，核心数设错反而更慢
盲目设 runtime.GOMAXPROCS(100) 或开 1000 个 goroutine 处理 1000 个任务，调度器开销会吃掉一半算力。正确姿势是：runtime.GOMAXPROCS(runtime.NumCPU())（禁用超线程逻辑核），再配固定数量 worker（如 runtime.NumCPU() 个），每个 worker 从 chan 拿一批任务（比如每批 1000 个 item），避免频繁 channel 切换。别忘了复用缓冲区：sync.Pool 里预分配 []byte，而不是每次循环都 make([]byte, n)。
立即学习“go语言免费学习笔记（深入）”；
最容易被忽略的是：CPU 密集型任务里，string 转 []byte 的零拷贝写法（unsafe.String + unsafe.Slice）和浮点运算用 float64 而非 big.Float 这类细节，单看不显眼，百万次循环下来就是几百毫秒差距。
