必须开--keep-stacktraces仅当需对still reachable或possibly lost内存块做精确调用链归因时；它全程缓存完整调用栈，代价是内存翻倍、速度降15%–40%、日志暴涨，多数场景无需开启。
什么时候必须开 --keep-stacktraces
只有当你需要在程序退出后，仍能对“仍可访达（still reachable）”或“可能泄漏（possibly lost）”的内存块做**精确调用链归因**时，才需要启用它。默认关闭（即不加该参数）是绝大多数场景下的合理选择——因为 Valgrind 会在程序 main 返回后立即 dump 堆状态，此时很多栈帧已销毁，--keep-stacktraces 的作用就是让 Memcheck 在分配/释放时主动缓存完整调用栈，而非只存最后几层。
--keep-stacktraces 和 --num-callers 的关系不是叠加，而是覆盖
两者都影响调用栈深度，但行为不同：
-
--num-callers=20只控制每条错误报告里显示多少层调用（比如报错时打印 20 行 backtrace），不影响内部是否保存全栈 -
--keep-stacktraces=yes是让 Valgrind **全程记录并保留每次 malloc/free 的完整调用栈快照**，哪怕你后续没触发错误；它本身不控制显示层数，但为--num-callers提供了“有东西可显示”的前提 - 如果你开了
--keep-stacktraces=no（显式关闭），哪怕--num-callers=100，Valgrind 也只保留默认深度（通常 12 层），超出部分直接丢弃，无法还原
开它要付出什么代价
这不是一个“开了更好”的开关，而是一个明确的性能-精度权衡：
- 内存占用翻倍甚至更高：每个堆块分配记录需额外存储一份完整调用栈（含符号、偏移、源码行号），对长期运行或高频分配的程序极易触发 OOM
- 运行速度下降 15%–40%：取决于调用栈平均深度和分配频次；尤其在 Qt 或 Boost 等深度模板展开的代码中，单次 malloc 可能带出 30+ 层栈帧
- 日志体积暴涨：一个
still reachable块原本只占 3 行，开启后可能膨胀到 50+ 行，grep 和人工筛查成本陡增 - 对
definitely lost类问题几乎无帮助：这类泄漏本就因指针丢失，调用栈再深也无法告诉你“谁该负责释放”，只能帮你定位“谁分配的”
更实用的替代路径
多数真实泄漏排查不需要全局开启 --keep-stacktraces：
- 先用
--leak-check=full --show-leak-kinds=all --num-callers=20跑一次，聚焦definitely lost和indirectly lost—— 这两类才是真 bug，它们的调用栈默认就足够定位 - 对顽固的
still reachable，优先检查是否是 Qt / GTK / OpenSSL 等框架的静态资源（如QFontDatabase缓存），这类无需修复，可用--suppressions=qt.supp屏蔽 - 若确需深挖某类分配，改用
--malloc-backtrace=yes（Valgrind 3.19+）配合--gen-suppressions=all，按需生成特定 malloc site 的栈捕获，比全局开--keep-stacktraces精准且轻量
真正需要它的时候极少：通常是调试一个第三方库的初始化逻辑，且该库在 main 之前做了大量 malloc，又没走 atexit 清理——这种 case 本身就该先怀疑设计合理性，而不是急着加开关硬扛。
