最可靠路径是 perf record -g 配合 -g -O2 -fno-omit-frame-pointer 编译：-g 提供符号避免 [unknown]，-O2 平衡内联与热点真实性，-fno-omit-frame-pointer 保障调用栈完整展开，缺一不可。
直接用 perf record -g 配合正确编译参数，是 Linux 下定位 C++ CPU 瓶颈最可靠、开销最低的路径。其他工具要么精度不足（如 gprof 漏掉模板和内联函数），要么运行太慢（如 valgrind --tool=callgrind），都不适合快速验证。
编译必须加 -g -O2 -fno-omit-frame-pointer
缺一不可——不是“建议”，是 perf report 能显示真实调用栈的硬性前提：
-
-g提供调试符号，否则函数名全是[unknown]或地址 -
-O2保持合理优化：-O0 会禁用内联，让std::vector::push_back这类高频小函数“膨胀”成多层调用，掩盖真实热点；-O3 则过度内联，导致调用链断裂、函数名变成??? -
-fno-omit-frame-pointer强制保留帧指针，否则即使有-g，perf record -g也会展不开模板实例化或 inlined 函数的调用栈
验证是否生效：file your_program 输出里要有 not stripped；readelf -S your_program | grep debug 应看到调试节存在。
perf record -g 不能只写命令就跑
常见错误是漏掉关键选项，导致采样无效或覆盖不全：
- 短时程序（-F 99（或更高），默认 4KHz 对这类程序太稀疏，容易错过热点
- 多线程程序默认只采主线程，要覆盖所有线程，加
-a（全系统）或-p PID（指定进程） - 别在容器里直接跑：
cgroup限制可能干扰硬件计数器，优先在宿主机或特权容器中执行 - 别用
perf top -p $(pidof app)替代perf record：前者是实时视图，关掉就丢数据，且不记录完整调用栈，看到的__libc_start_main占比高只是假象
perf report -n --no-children 才看得清真正瓶颈
perf report 默认显示 “Children” 总耗时（含子函数），容易误判——比如 main 占 90%，但它只是调度入口，实际干活的是它调用的 process_request。用 --no-children 才能聚焦 “Self” 列，即函数自身代码执行时间：
- 重点关注
Overhead > 5%且不是系统调用（如epoll_wait、read）的 C++ 函数 - 若某函数 Self 很低但 Children 高，说明它是胶水层，瓶颈在子函数里，按
Enter展开调用栈继续下钻 - 火焰图里顶部宽但颜色浅？大概率是
futex_wait或pthread_cond_wait——这是 Off-CPU 等待，不是 CPU 瓶颈，该换offcpu工具分析
火焰图比文本报告更容易发现高频小函数
文本 perf report 容易忽略那些单次耗时低、但被高频调用的函数，比如循环里反复触发的 std::string::c_str() 或 std::vector::emplace_back()。它们在文本里可能只占 1%～2%，总和却达 30%+
- 生成命令：
perf script | ~/FlameGraph/stackcollapse-perf.pl | ~/FlameGraph/flamegraph.pl > flame.svg - 必须包含
stackcollapse-perf.pl：它是把原始栈格式转成火焰图可读格式的关键步骤，漏了就出不来图 - 火焰图横向宽度 = 时间占比，纵向深度 = 调用栈；一眼就能看出哪一层“胖得异常”，比如某个
std::unordered_map::find在某条路径上意外变宽，就是优化突破口
真正难的不是跑通命令，而是理解：为什么 -fno-omit-frame-pointer 在 -O2 下不是默认开启？因为 GCC 为省一点栈空间默认关它，而这一省，就让 perf 的调用栈断在第一层。这个细节，90% 的人第一次都踩坑。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
