先用 top -p 或 htop 确认高 CPU 是真实负载（%CPU 接近 100%×GOMAXPROCS 且 %WAIT 低），再通过 HTTP pprof 安全采样分析火焰图，重点关注 mallocgc、mapaccess1、cgocall、Mutex.Lock 等典型瓶颈特征。
怎么看 Go 程序是不是真在 CPU 上卡住了
先别急着开 pprof，确认高 CPU 是真实负载还是误判。用 top -p 或 htop 查看该进程的 %CPU 和 %WAIT：如果 %CPU 持续接近 100% × GOMAXPROCS（比如 8 核机器跑满就是 ~800%），且 %WAIT 很低，才说明是 CPU 密集型问题；若 %WAIT 高，更可能是 I/O 或锁竞争，该看 trace 或 mutex profile。
怎么安全采集 CPU Profile（避免线上抖动）
直接调 runtime/pprof.StartCPUProfile 会阻塞所有 goroutine，线上慎用。推荐走 HTTP pprof 接口，启动时加一行：
import _ "net/http/pprof"
然后用 curl 抓取 30 秒 profile：
curl -o cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=30"
- 不要设超过 60 秒，长采样会拖慢服务响应
- 确保
GOROOT和GOPATH环境变量在目标机器上可用，否则go tool pprof解析符号失败 - 若程序启用了
GOEXPERIMENT=nogc或自定义调度器，profile 可能漏掉部分 goroutine 栈
pprof 分析时重点关注哪几类火焰图特征
用 go tool pprof -http=:8080 cpu.pprof 启服务后，在浏览器看火焰图。以下模式意味着典型瓶颈：
立即学习“go语言免费学习笔记（深入）”；
-
runtime.mallocgc占比高 → 频繁小对象分配，检查是否在循环里构造 struct/slice/map -
runtime.mapaccess1或runtime.mapassign宽而深 → map 并发读写未加锁，或 key 类型导致哈希冲突严重 - 某业务函数栈顶连续多层
runtime.cgocall→ CGO 调用阻塞了 GPM 调度，考虑用runtime.LockOSThread或改纯 Go 实现 - 大量
sync.(*Mutex).Lock出现在非预期位置 → 锁粒度太粗，比如整个 handler 共用一个 mutex
常见误优化：盲目加 goroutine 或减少 defer
看到 CPU 高就加 go fn()，反而可能因调度开销和 channel 争用让情况更糟。defer 在 Go 1.14+ 已优化为近乎零成本，除非 profiler 明确指出 runtime.deferproc 占比 >5%，否则不值得动。真正有效的优化点通常是：
- 把
for range []byte改成索引遍历，避免每次迭代拷贝子 slice - 用
strings.Builder替代+=拼接字符串 - 对高频访问的 map，预估容量并用
make(map[T]V, N)初始化 - 检查是否有
time.Sleep(1 * time.Nanosecond)这类空转逻辑（尤其在重试循环中）
profile 不会告诉你“该用什么算法”，但能准确定位“哪一行代码正在吃 CPU”。最常被忽略的是：没对比 baseline —— 优化前先跑一次 profile 记下总耗时，改完再跑，否则无法判断改动是否真有效。
