callgrind生成的是文本格式计数数据，非直接可视调用图；需用kcachegrind加载或gprof2dot+graphviz渲染才能获得可交互/静态调用图，编译必须加-g且建议-o0以保留符号与调用链。
Callgrind 生成的原始输出是文本格式的计数数据，不是调用图；真正能“看”调用图的，是 KCacheGrind 或配合 gprof2dot + graphviz 的可视化流程。直接打开 callgrind.out.PID 文件只会看到一堆指令计数和函数嵌套标记，没人靠肉眼读它。
怎么把 callgrind.out.PID 变成可交互的调用图
核心路径只有一条：生成数据 → 加载进 KCacheGrind（推荐）或转 dot → 渲染图像。别试图手动解析文本文件。
-
KCacheGrind是官方亲儿子，支持展开/折叠、热点过滤、调用关系跳转、时间占比排序，还能点进某个函数看它调用了谁、被谁调用 - 如果没装
KCacheGrind，用gprof2dot.py -f callgrind callgrind.out.12345 | dot -Tpng -o callgraph.png能出静态图，但丢失交互能力，且多线程时容易混掉线程上下文 - 注意：默认生成的
callgrind.out.PID不含符号信息（比如函数名），编译时必须加-g，否则 KCacheGrind 里全是???或地址
callgrind --separate-threads=yes 到底要不要开
开不开取决于你是否关心线程间调用隔离。不加的话，所有线程的调用堆栈会揉在一起统计，KCacheGrind 里看不到哪个函数是哪个线程执行的；加了之后会生成多个文件（如 callgrind.out.12345-01、-02），每个对应一个线程，方便单独分析。
- 多线程程序调试竞态或负载不均时，必须加
--separate-threads=yes - 但
KCacheGrind一次只能加载一个文件，不能自动合并查看全局调用流 - 如果你用
gprof2dot，它默认只处理单个文件，对多文件需循环转换再手动拼图——实际很麻烦
为什么 KCacheGrind 里看不到 std::thread 或 lambda 的调用链
因为 C++ 模板实例化、内联函数、RAII 包装器（比如 std::lock_guard）在 Callgrind 默认模式下可能被折叠或未记录。这不是 bug，是工具行为限制。
- 确保编译时禁用优化：
g++ -O0 -g，否则std::thread::invoke这类间接调用会被内联掉，Callgrind 就抓不到中间层 - 加
--collect-jumps=yes可增强跳转跟踪，对 lambda 和 functor 调用链有帮助，但会显著增加输出体积和运行开销 - 某些 STL 实现（如 libstdc++）的内部函数名带
__前缀，在 KCacheGrind 中默认隐藏，需右键菜单勾选 “Show hidden functions” 才能看到
Callgrind 的调用图本质是采样+插桩的结果，不是 100% 精确的控制流图；它反映的是“哪些函数被频繁调用及嵌套深度”，而不是“每一条执行路径”。想看完整路径，得结合源码和 valgrind --tool=callgrind --dump-instr=yes 配合反汇编，但那已经超出常规性能分析范畴了。
