pprof 启动后访问 /debug/pprof/profile 返回空或超时，因该端点需主动触发采样且依赖运行中的 HTTP 服务；必须确保 _ "net/http/pprof" 已导入、HTTP server 正常监听、采样请求带 seconds 参数（如 ?seconds=30），或改用 pprof.StartCPUProfile 手动控制。
pprof 启动后访问 /debug/pprof/profile 返回空或超时
这是最常见的起步卡点：默认情况下，net/http/pprof 只注册路由，但不会自动启动 HTTP 服务；而且 /debug/pprof/profile 是一个需要主动触发的采样端点，不是静态页面。
必须确保：
-
import _ "net/http/pprof"已添加（下划线导入触发 init 注册） - HTTP server 正在运行，且监听地址可被
go tool pprof访问（本地开发常用localhost:6060） - 采样请求带参数，例如：
curl "http://localhost:6060/debug/pprof/profile?seconds=30"，否则默认只采 30 秒，且无参数时可能因无活跃 goroutine 而返回空
如果程序本身不启 HTTP 服务，可用 pprof.StartCPUProfile 手动控制：
file, _ := os.Create("cpu.pprof")
pprof.StartCPUProfile(file)
// ... 运行待测逻辑 ...
pprof.StopCPUProfile()
用 go tool pprof 查看火焰图却看不到函数名或显示 ???
根本原因是二进制缺少调试符号（DWARF info），常见于用 -ldflags="-s -w" 构建的发布版程序——这些 flag 会剥离符号表和调试信息，导致 pprof 无法映射到源码函数。
定位 CPU 瓶颈必须保留符号信息：
- 开发/分析阶段禁用
-s（strip symbol table）和-w（omit DWARF symbol table） - 构建命令应为：
go build -o app main.go（不加 -ldflags） - 若已用 strip 构建，
pprof只能显示地址，无法关联函数名或行号
验证是否含符号：readelf -S ./app | grep debug 或 file ./app 中含 with debug_info 即可。
top 显示高耗时函数，但实际代码里它只是个简单循环或调用转发
pprof 的采样基于 OS 信号（SIGPROF），按固定频率中断并记录当前调用栈。这意味着“热点”反映的是 CPU 时间在栈顶函数的累积占比，而非该函数自身运算量 —— 它可能是被频繁调用的胶水函数，也可能是内联失败后暴露出来的底层调用。
关键判断点：
- 看
top -cum（累计时间）：如果某函数在 top 列表靠前但cum%接近 100%，说明它是调用链入口，瓶颈大概率在它内部或其直接子调用 - 看
web或svg输出：火焰图中宽而高的函数块才真正值得深挖；窄条可能是高频小开销，未必是优化重点 - 注意编译器内联：
go build -gcflags="-l"关闭内联后重新采样，可暴露原本被折叠的中间层函数
在容器或生产环境无法开 HTTP 端口，又想抓 CPU profile
HTTP 模式依赖网络暴露，生产环境常受限。更稳妥的方式是通过信号 + 文件落地：
- 程序中监听
SIGUSR1（Linux/macOS）或SIGQUIT（Windows），收到后调用pprof.Lookup("cpu").WriteTo(...) - 或使用
runtime.SetBlockProfileRate/SetMutexProfileFraction配合定期 dump，但 CPU profile 必须主动 Start/Stop - 推荐模式：启动时用
os.Signal监听SIGUSR1，触发后写入/tmp/cpu-$(date +%s).pprof，再scp出来本地分析
注意：不要在高负载时长期开启 CPU profile，它本身有 ~1%~2% 性能开销；采样 10–30 秒足够定位稳态热点。
最易被忽略的一点：pprof 分析结果严重依赖运行时上下文 —— 同一段代码，在不同数据规模、GC 压力、锁竞争下热点可能完全不同。务必在贴近真实流量的场景下采样，而不是仅跑单元测试。
