编译需加-g且禁用优化：g++ -g -O0确保调试信息完整、执行流清晰；Valgrind须用–leak-check=full –show-leak-kinds=all –track-origins=yes定位泄漏；definitely lost必须修复，still reachable通常非bug；避免exit()绕过析构，慎用shared_ptr防循环引用。
编译时必须加 -g 且禁用优化
Valgrind 依赖调试信息定位泄漏源头，不加 -g 会导致报告里只有 ???，完全无法回溯到源码行。同时，-O2 或更高优化等级会让变量生命周期、内联、寄存器分配失真，造成误报（如把未初始化值当泄漏）或漏报（如提前释放被优化掉）。实操建议：
- 用
g++ -g -O0 -o myapp myapp.cpp编译，确保符号完整、执行流清晰 - 若项目用 CMake，加
set(CMAKE_BUILD_TYPE Debug)并确认CMAKE_CXX_FLAGS_DEBUG包含-g -O0 - 避免链接 strip 后的库；第三方库也尽量用带调试符号的版本（如 ubuntu 的
*-dbg包）
运行 Valgrind 时启用完整内存检查参数
默认 valgrind ./myapp 只做基础错误检测，对内存泄漏需显式开启 --leak-check=full 并配合其他关键选项。常见遗漏点：
-
--leak-check=full：显示每块泄漏内存的分配栈，缺它就只告诉你“有泄漏”，不告诉你在哪 -
--show-leak-kinds=all：覆盖definitely lost、indirectly lost、possibly lost、still reachable四类，尤其possibly lost常被忽略但可能指向悬空指针或边界越界 -
--track-origins=yes：对Use of uninitialised value类错误，能追溯未初始化内存的来源（代价是慢 2–3 倍，但值得） - 完整命令示例：
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --log-file=valgrind-out.txt ./myapp
区分 definitely lost 和 still reachable 的真实含义
Valgrind 报告里的分类直接决定修复优先级，但很多人误判：
-
definitely lost：指针已丢失（比如局部指针变量出作用域，且无其他引用），内存彻底不可达 → 必须修复 -
still reachable：程序退出时仍有指针指向该内存（如全局std::vector缓存、单例对象成员），通常不是 bug，但若量大或持续增长，说明资源未按需释放 -
indirectly lost：父块泄漏导致子指针失效，先修父块即可，不用单独处理 - 注意：c++ 中
std::String、std::vector等容器内部 new 的内存，若容器本身是栈对象且未 move/转移，其析构会自动释放，不会报 leak —— 所以泄漏基本来自裸new未配delete，或new[]配了delete
处理 C++ RaiI 与第三方库干扰
Valgrind 本身不理解 C++ 析构语义，某些 RAII 模式或库（如 Boost、qt）会在主函数结束后才释放资源，造成假阳性。应对方式：
立即学习“C++免费学习笔记（深入）”；
- 在程序末尾主动调用清理逻辑，例如 Qt 中加
QApplication::processEvents(); qApp->quit();，再等几毫秒 - 用
--suppressions=mysupp.supp屏蔽已知良性泄漏，例如 GLIBC 的__libc_freeres调用前的缓存（生成模板见valgrind --gen-suppressions=all） - 避免在
main()返回前用exit()—— 它绕过栈展开和析构，会让所有 RAII 失效，把本可自动释放的内存变成definitely lost - 若用
shared_ptr却仍泄漏，检查是否形成循环引用（如父子对象互相持shared_ptr），此时应改用weak_ptr打断环
Valgrind 的 Memcheck 对裸指针管理问题极其敏感，但对现代 C++（智能指针、容器）的误报率其实很低；真正难的是从几十页报告里快速定位那个少写了一行 delete 或多写了一个 std::move 的地方——这时候 --num-callers=20 和日志文件里搜索 at 0x 对应的源码行，比任何技巧都管用。