Valgrind默认memcheck全程监控堆内存操作，但需加--leak-check=full和--show-leak-kinds=all才能精准定位泄漏类型，-g编译确保行号可读；massif仅分析堆用量而非检测泄漏。
Valgrind 本身不“重点检查堆内存问题”，它默认的 memcheck 工具就已经在全程监控堆内存——只要用 malloc、calloc、realloc、free 或 C++ 的 new/delete，就逃不过它的盯梢。真正需要你主动干预的，是让报告聚焦、可读、能定位，而不是被默认行为淹没。
为什么 memcheck 默认就能抓堆问题，但你还得调参数？
memcheck 在程序运行时拦截所有堆操作，但它默认只报告“严重错误”（比如越界写、use-after-free），对内存泄漏只做简略统计。如果你只跑 valgrind ./a.out，很可能漏掉泄漏细节，甚至误以为没泄漏。
-
--leak-check=full是必须加的：否则HEAP SUMMARY里只显示“in use at exit”字节数，不告诉你哪行代码分配的 -
--show-leak-kinds=all要配合使用：区分definitely lost（真泄漏）、possibly lost（可能泄漏，比如指针藏在结构体里没被扫到）、still reachable（退出前还持有指针，未必是 Bug） - 不加
-g编译，报错里只会显示vg_replace_malloc.c:309，看不到你的main.c:12
massif 不是泄漏检测工具，别指望它报错行号
massif 是堆空间“用量快照仪”，不是“Bug扫描仪”。它记录每次 malloc/free 后的堆峰值和分布，适合回答“为什么 RSS 持续上涨”或“某段逻辑是否造成碎片”，但不会告诉你“第 42 行忘了 free”。
- 它生成的
massif.out.文件需用ms_print解析，或用massif-visualizer看曲线图 - 只有在分配后没被释放的内存块，才会在快照中持续存在；但 massif 不跟踪“谁持有指针”，所以无法判定是否泄漏
- 若你怀疑是频繁小对象导致碎片，用
--pages-as-heap=yes让 massif 把整个页表当堆看，能暴露更底层的分配模式
遇到“泄漏疑似但报告模糊”，先查这三处
Valgrind 报告里出现 still reachable 或 suppressed 并不等于安全，往往是掩盖点。
- 全局/静态指针持有堆内存：比如
static char* cache = NULL;在初始化时malloc但从未free，退出时算still reachable，实际是设计泄漏 - 第三方库内部缓存：某些库（如 glibc 的
printf实现）会预分配缓冲区且不释放，这类需用--gen-suppressions=all生成抑制规则，再人工审核是否合理 - C++ 异常路径绕过
delete：如果new后抛异常，且没用 RAII 封装，memcheck会标记为definitely lost，但调用栈可能停在__cxa_throw，得结合源码看异常是否未被捕获
堆问题最麻烦的从来不是发现不了，而是 Valgrind 报了一堆信息，你不确定哪条该修、哪条是干扰项。关键不在工具多强大，而在你能否用对参数把噪音滤掉，再盯着调用栈往回推——尤其是那些看似“无害”的 still reachable 和第三方库调用。
