Valgrind 有效使用需编译加 -g 且禁用优化（-O0），运行时用 --leak-check=full --show-leak-kinds=all 分析泄漏，重点关注 definitely lost 和 indirectly lost；C++ 中 new/delete 必须配对，多线程可用 helgrind。
Valgrind 是 Linux 下最常用的内存调试工具之一，尤其擅长检测 C/C++ 程序中的内存泄漏、非法内存访问、使用未初始化内存等问题。要让它有效工作，关键不是“装上就用”，而是编译、运行、分析三步都得对。
编译时必须加 -g 并禁用优化
Valgrind 需要符号信息才能定位到具体哪一行出问题，所以编译时一定要加 -g；同时，开启优化（如 -O2）会让代码重排、内联、变量被优化掉，导致报告位置不准甚至漏报。推荐的编译命令是：
- g++ -g -O0 -Wall your_code.cpp -o your_program
- 如果用了 CMake，确保
CMAKE_BUILD_TYPE=Debug，并检查是否启用了 -O2（需手动关掉）
用 valgrind --leak-check=full 运行程序
基础命令格式：
- valgrind --leak-check=full --show-leak-kinds=all ./your_program
-
--leak-check=full启用详细泄漏分析 -
--show-leak-kinds=all显示 definitely lost / indirectly lost / possibly lost / still reachable 四类结果 - 加
--track-origins=yes可追查未初始化值的来源（对“Conditional jump or move depends on uninitialised value”这类错误很有用）
看懂关键泄漏分类和常见原因
Valgrind 报告里最值得关注的是前两类：
立即学习“C++免费学习笔记（深入）”；
- definitely lost：堆内存分配后，指针丢失（比如没 free/delete，或指针被覆盖），这是真正的内存泄漏
- indirectly lost：因 definitely lost 的块所引用的其他块连带丢失，通常跟着上面一起修复
- still reachable：程序退出时仍有指针指向该内存（如全局/静态指针、main 中未 delete 的对象），不一定是 bug，但需确认是否合理
- suppressed：被 suppress 文件过滤掉的已知系统库误报，一般不用管
注意：C++ 中 new[] 必须配 delete[]，new 配 delete；混用会导致未定义行为，Valgrind 可能报 mismatched free/delete 或直接崩溃。
实战小技巧：快速定位 + 避坑
实际用起来容易卡在几个地方：
- 程序一运行就崩？先试
valgrind --tool=memcheck --leak-check=no ./your_program关掉泄漏检查，确认是不是段错误本身的问题 - 输出太长看不过来？加
--log-file=valgrind-out.txt把结果存文件，再用 grep 筛选，例如：grep "definitely lost" valgrind-out.txt - 用了第三方库（如 Qt、Boost）报一堆 still reachable？可创建 suppress 文件过滤，或加
--suppressions=my.supp跳过已知安全的库泄漏 - 多线程程序？Valgrind 支持，但默认会变慢很多；若怀疑线程间释放竞争，可加
--tool=helgrind（专门检竞态）
基本上就这些。不复杂但容易忽略细节——尤其是编译选项和泄漏分类含义。跑通一次，后面每次改完关键内存操作，顺手 valgrind 一下，能省下大量排查时间。
