用pprof定位Go高CPU问题需采样30–60秒，优先看火焰图顶部宽高函数：若runtime.futex/mcall占比高，说明调度争抢，疑goroutine泄漏或锁竞争；若strings.Builder.WriteString/json.decodeState.object高频出现，则是热路径低效，应缓存或预分配；泄漏指goroutine卡在select{}、无缓冲channel等而未退出，持续占调度资源。
Go并发编程CPU占用高，大概率不是“并发太多”本身的问题，而是并发失控、调度失衡或计算逻辑卡在某个低效循环里——先别急着加机器或调 GOMAXPROCS，得看清楚是哪类 goroutine 在吃 CPU。
怎么用 pprof 快速锁定真凶函数
pprof 不是“看看就行”的工具，它必须配合足够长的采样窗口和正确的分析视角才能暴露问题。很多开发者只跑 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=5，结果什么都没抓到，因为 5 秒太短，热点还没稳定出现。
- 采集时间至少设为
30秒，高负载下可延长到60秒；避免用默认的 30 秒但程序刚启动就采——等业务流量上来再触发 - 进交互模式后，别只看
top，优先执行web命令打开火焰图，重点盯住顶部又宽又高的函数条：如果runtime.futex或runtime.mcall占比异常高，说明调度器在疯狂抢资源，大概率是 goroutine 泄漏或锁竞争 - 如果火焰图里反复出现
strings.Builder.WriteString或json.(*decodeState).object，那不是并发问题，是字符串拼接或 JSON 解析被塞进了热路径，该缓存就缓存，该预分配就预分配
goroutine 泄漏比你想象中更常见
泄漏不等于“没退出”，而是“卡住了却还活着”。一个 goroutine 卡在 select {} 或无缓冲 channel 的发送端，它不会释放栈内存，也不会被 GC 回收，只会持续占用调度器时间片——1000 个这样的 goroutine，就能轻松拉满一个核。
- 检查
/debug/pprof/goroutine?debug=2输出，搜索重复出现的堆栈，尤其是带chan send、chan recv、select或time.Sleep的行 - 典型陷阱：
for { ch 没有接收者；<code>http.Client超时未设，导致 goroutine 卡在连接建立；第三方 SDK 启动了后台心跳但没提供关闭接口 - 别依赖
runtime.NumGoroutine()做告警阈值——它只返回数量，不区分“活跃”和“僵尸”。要结合goroutine?debug=1的状态字段（如runnable、waiting）判断是否异常
高频循环必须主动让出 CPU
Go 调度器不会强制抢占没有阻塞点的 goroutine。写个空 for {} 或密集轮询，它就会霸占 P 直到被系统信号打断——这不是 bug，是设计使然。
- 错误写法：
for { if flag { doWork() } }—— 没休眠，没阻塞，CPU 100% - 正确做法：加
time.Sleep(1 * time.Millisecond)，或改用select { case ，或在循环内插入 <code>runtime.Gosched()（仅限极轻量、确定能快速完成的场景） - 注意：
time.Sleep(0)无效，它不会触发调度；runtime.Gosched()也不解决根本问题，只是临时缓解——得回到业务逻辑，问一句：“这个轮询真的必要吗？”
真正难排查的 CPU 高问题，往往藏在“看起来很合理”的地方：比如一个用 sync.Pool 缓存 bytes.Buffer 的服务，却在每次请求里都调用 buf.Reset() 后又立刻 buf.String()，导致底层字节数组反复扩容；或者一个用 map 做本地缓存的服务，键是含时间戳的字符串，缓存永远不命中……这些都不是并发模型的问题，而是对 Go 内存模型和运行时行为的理解偏差。
