直接回答：CPU profile 基于信号采样：runtime 注册 SIGPROF 定时器（默认 100Hz），信号处理里记录当前 goroutine 的栈回溯，聚合 30 秒（默认窗口）输出调用栈频次表——频次即时间占比的无偏估计。开销约 1%~5%，线上常开 net/http/pprof 端点按需采集是标准实践。

展开解析：采集流程：服务 import _ "net/http/pprof" 后访问 /debug/pprof/profile?seconds=30 拿 .pb.gz，go tool pprof 分析；连续剖析用 Parca/Pyroscope 按实例周期采集入库。分析路径：top 看自耗时（flat）最高的函数定位热点，list 看源码级分布，web/火焰图看调用链归因——flat 高但 cum 不高的叶子是真热点，cum 高的是入口。原理细节决定解读边界：采样在 STW 与系统调用阻塞时不触发，所以 CPU profile 看不见 IO 等待与锁等待——等待类问题要看 goroutine/block/mutex profile；100Hz 采样对极短函数有盲区，热点判定以占比 1% 以上为准。线上纪律：采样窗口避开流量尖刺的特殊时刻（否则结论以偏概全），多实例部署要跨实例对比排除单机异常；优化前后用相同窗口与流量特征采集对比，pprof -base 做差分看增量。别忘 GOMAXPROCS 与容器 CPU 限额的错配是常见“伪热点”（大量时间在调度自旋），先确认 runtime 配置再深挖代码。

追问方向：为什么 goroutine 泄露会扭曲 CPU profile 结论？采样频率提高有什么代价？

（约 480 字）