valgrind 通过 memcheck 拦截内存分配/释放调用并追踪堆块生命周期，若 new 分配的内存未被 delete（包括析构函数中遗漏），则标记为 definitely lost；需编译加 -g 且对象为堆分配或跨作用域栈对象才能准确定位析构问题。
Valgrind 本身不直接“发现析构函数没写好”，但它能暴露因析构函数缺失或错误导致的内存泄漏——只要你用 new 分配了资源，又没在析构中 delete，Memcheck 就会报出来。
为什么 Valgrind 能揪出析构遗漏？
Memcheck 拦截所有 malloc/new 和 free/delete 调用，并记录每块堆内存的分配栈。如果某次 new 后，程序退出前没有任何对应的 delete（包括通过析构函数触发的），这块内存就被标记为 definitely lost。而类对象的析构函数，正是最常被遗漏的 delete 入口。
典型场景：构造函数里用 new int[100] 分配缓冲区，但析构函数为空或没写 delete[] a —— Valgrind 会把泄漏源头精准定位到那行 new，并显示调用栈经过构造函数。
必须满足的两个前提条件
Valgrind 才能有效关联析构失败和泄漏：
- 编译时加
-g：否则输出里看不到函数名和行号，只剩地址，无法判断是不是析构漏写了 - 对象必须是堆上创建的（
new）或栈对象生命周期跨函数边界：栈对象在作用域结束时自动调用析构，但如果析构本身没释放资源，泄漏依然存在；而全局/静态对象的析构发生在main返回后，Valgrind 默认能覆盖到这个阶段
看懂 Valgrind 输出里的关键线索
运行 valgrind --tool=memcheck --leak-check=full ./a.out 后，重点盯这些字段：
definitely lost: 400 bytes in 1 blocks → 确认泄漏存在
下面的 by 0x...: base::base(int) (test.cpp:8) → 泄漏发生在 base 类构造函数第 8 行，说明资源是在那里分配的
但输出里找不到任何 base::~base() 的调用痕迹，更没有 delete 相关的栈帧 → 基本可断定析构函数没做清理，或者根本没定义
如果基类指针指向子类对象，且基类析构不是 virtual，Valgrind 还可能只报告基类成员泄漏，而子类额外分配的内存彻底“消失”——这时泄漏量会比预期少，但 still reachable 可能异常高，是虚析构遗漏的间接信号。
容易被忽略的 C++ 特殊情况
Valgrind 对以下情况“无能为力”，但它们同样属于“析构没释放干净”：
- 资源不是堆内存：比如打开的文件描述符、
pthread_mutex_t、GPU 显存等，Valgrind 不监控这些，得靠其他工具（如lsof或 ASan 的 UBSan 扩展） - 循环引用 +
shared_ptr：两个对象互相持有对方的shared_ptr，析构永远不会触发，Valgrind 会报告整块对象内存为definitely lost，但调用栈停在make_shared，而不是析构函数——这时候要怀疑智能指针设计，而非手写析构 - 析构函数抛异常：C++ 标准规定析构中抛异常会导致
std::terminate，程序提前崩溃，Valgrind 来不及报告泄漏；此时应检查崩溃前最后几行日志或用gdb配合
真正难定位的，从来不是“有没有析构”，而是“析构里该释放什么、怎么释放”。Valgrind 给你的是结果证据，不是设计说明书。
