真被CPU卡住需先验证：若%CPU持续接近100%×GOMAXPROCS且%WAIT低，才是CPU密集型；否则多为I/O等待或锁竞争，应查trace或mutex profile而非CPU profile。
确认是不是真被CPU卡住，别被假象骗了
很多同学一看到top里 Go 进程 %CPU 高就慌着开 pprof，结果发现是 I/O 等待或锁竞争——%CPU 高但实际不是 CPU 密集型问题。先用 top -p 或 htop 看两个关键指标：%CPU 和 %WAIT（在 htop 中按 F5 切换树状视图可看到）。
- 如果
%CPU持续接近100% × GOMAXPROCS（比如 8 核机器跑满≈800%），且%WAIT很低（ - 如果
%WAIT明显偏高（>20%），说明 goroutine 大量阻塞在系统调用（如文件读写、网络收发、锁等待），该去看go tool pprof http://localhost:6060/debug/pprof/trace或mutexprofile，而不是 CPU profile - 注意：某些容器环境或 cgroup 限制下，
%CPU可能被 cap 住（比如限制为 200%），此时即使业务已满载，显示值也上不去，需结合runtime.NumGoroutine()和/debug/pprof/goroutine?debug=1综合判断
安全采样 CPU Profile，线上别硬刚 runtime.StartCPUProfile
直接调 runtime/pprof.StartCPUProfile 会全局暂停所有 goroutine，线上绝对禁用。正确姿势是走 HTTP pprof 接口，它基于信号采样，对服务影响极小。
- 代码里加一行：
import _ "net/http/pprof"，再起个 goroutine：go http.ListenAndServe("localhost:6060", nil) - 采集命令用
curl -o cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=30"，30 秒是黄金时长；超过 60 秒易拖慢响应，低于 15 秒可能漏掉偶发热点 - 解析时确保目标机器有
GOROOT和GOPATH（或启用 Go modules），否则go tool pprof无法还原符号，火焰图里全是??? - 若程序启用了
GOEXPERIMENT=nogc或自定义调度器，profile 可能缺失部分栈帧，这时得结合trace+ 手动日志打点交叉验证
看火焰图时盯死这四类 runtime 调用
启动 go tool pprof -http=:8080 cpu.pprof 后，在浏览器打开火焰图，别只看业务函数名——真正的问题往往藏在 runtime 底层调用的宽度和深度里。
-
runtime.mallocgc占比高 → 不是 GC 慢，而是分配太猛。检查是否在循环里反复make([]byte, N)、构造 struct 或 map；优先预分配容量或用sync.Pool复用 -
runtime.mapaccess1或runtime.mapassign宽而深 → 不是 map 本身慢，而是并发读写未加锁（触发哈希表扩容+重哈希），或 key 是小切片/结构体导致哈希冲突严重；改用sync.Map或加sync.RWMutex，key 尽量用 int/string - 大量
runtime.cgocall堆叠在业务函数顶上 → CGO 调用阻塞了 M，G 无法调度。避免在 hot path 调 C 函数；必须调的话，加runtime.LockOSThread()并确保成对解锁 -
sync.(*Mutex).Lock出现在非预期位置（比如 handler 入口、数据库查询前）→ 锁粒度太粗。不要用一个 mutex 保护整个请求生命周期，拆成字段级或资源 ID 级锁
别瞎优化：defer 几乎零成本，goroutine 不是万能解药
看到 CPU 高就删 defer、狂加 go fn()，大概率让问题更糟。
立即学习“go语言免费学习笔记（深入）”；
-
defer在 Go 1.14+ 已深度优化，只要不出现runtime.deferproc占比 >5%，就不用动；盲目删除反而破坏资源清理逻辑 - 无节制起 goroutine 会放大调度开销，尤其当 channel 操作频繁或锁争用时，
go fn()可能比同步执行还慢；用带缓冲的 channel 控制并发数，比如semaphore := make(chan struct{}, 10) - 真正有效的优化往往很朴素：把
for _, b := range data改成索引遍历避免子 slice 拷贝；用strings.Builder替代+=；删掉time.Sleep(1 * time.Nanosecond)这种空转逻辑
火焰图宽条背后，90% 的 CPU 问题都出在“高频路径上的低效操作”，而不是算法理论复杂度。先抓 top3 函数，再逐行看 list 输出里的汇编耗时，比猜更可靠。
