必须加 -pg 且禁用优化（如 -o0），否则无法插桩或导致调用栈失真；需先运行程序生成 gmon.out，再用 gprof 分析，其在多线程、fork、短时程序等场景不可靠。
编译时必须加 -pg 且禁用优化
不加 -pg 就根本不会插桩，生成的可执行文件里没有性能采集逻辑；加了但用了 -O2 或 -O3，会导致函数内联、调用栈失真，gprof 输出的调用关系和时间占比严重失准。稳妥做法是：g++ -pg -O0 -g main.cpp -o main。注意 -g 不是必须，但加上后能显示函数名和行号，否则只看到地址。
运行一次程序才会生成 gmon.out
gprof 不是实时监控工具，它依赖程序退出时自动写入的 gmon.out 文件。没运行、运行崩溃、或被 kill -9 强杀，都不会生成该文件。常见错误：编译完直接跑 gprof ./main，报错 gmon.out: No such file or directory。正确流程是：./main（确保正常退出）→ 当前目录出现 gmon.out → 再执行 gprof ./main。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
gprof 默认只分析 flat profile 和 call graph，关键字段要看懂
输出分两块：flat profile 按函数耗时排序，call graph 显示函数间调用路径。重点关注三列：%time（该函数自身耗时占总采样时间比），self（毫秒级自身耗时），children（子函数耗时）。若某个函数 %time 高但 children 接近 0，说明热点在它内部；若 children 高，则要顺藤摸瓜看下层函数。示例命令：gprof ./main gmon.out -q（只输出 call graph）或 gprof ./main gmon.out | head -20 快速扫 top 耗时函数。
多线程、信号、fork 场景下 gmon.out 不可靠
gprof 基于单线程计数器 + 时钟信号（ITIMER_PROF）采样，遇到多线程时只统计主线程，子线程的耗时全丢失；fork 后子进程会覆盖同一份 gmon.out；频繁发信号（如 SIGALRM）可能干扰采样精度。这时候别硬扛，换 perf record -g ./main 或 valgrind --tool=callgrind 更靠谱。另外，gprof 对短生命周期程序（如运行不到 100ms）采样不准，因为定时器最小分辨率有限。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
