Valgrind 能可靠检测 return 前未 free/delete 的内存泄漏，前提是编译时加 -g -O0、运行时启用 --leak-check=full；它通过追踪堆内存生命周期，将退出时不可达的分配标记为 “definitely lost”。
直接说结论：Valgrind 能可靠发现 return 前忘记 free 或 delete 的内存，但前提是程序运行到那个 return、且编译时带 -g -O0、运行时启用 --leak-check=full。
为什么 return 前没 free 会被 Valgrind 抓到
Valgrind 的 memcheck 不关心“你写没写 free”，它只监控所有堆内存的生命周期：从 malloc/new 分配开始，到对应 free/delete 结束。如果程序退出时某块堆内存仍被分配、且没有任何指针能访问到它（即“definitely lost”），那就说明它在 return 前被遗弃了。
注意：不是所有 return 遗忘都会报 definitely lost。比如局部指针变量指向堆内存，函数 return 后该指针销毁，但若没有其他全局/静态/传入的指针持有它，这块内存就真丢了。
-
definitely lost：最典型场景，比如int* p = new int[100]; return;，无任何其他指针引用，Valgrind 必报 -
still reachable：比如static std::vector，* v = new std::vector ; return前没删，但static指针还活着 —— 这不算 bug，可忽略 -
possibly lost：指针被部分覆盖或移位（如数组下标算错），Valgrind 不确定是否还能访问，需人工核查
必须加的编译和运行参数
漏掉任一参数，return 前的泄漏可能不显示行号、甚至完全不报。
- 编译必须用
g++ -g -O0 -std=c++17：缺-g就只显示???；开-O2可能让new被优化掉，或让栈帧混乱，导致泄漏“消失” - 运行必须用
valgrind --leak-check=full --show-leak-kinds=all ./a.out：默认--leak-check=summary只告诉你“有泄漏”，不列调用栈 - 如果程序有命令行参数，直接跟在
./a.out后面，比如valgrind ... ./a.out --mode test
常见误判和绕过陷阱
不是所有“没 free”都该修，也不是所有报告都可信。
- 第三方库内部分配（如 Qt 的
QTimer::singleShot、Boost.Asio 的 handler）常触发still reachable或假possibly lost，加--suppressions=/usr/lib/valgrind/default.supp可过滤 - 用
std::unique_ptr或std::vector管理堆内存时，return前不手动delete是正确的 —— Valgrind 不会报泄漏，因为析构函数自动清理了 - 如果函数提前
return在多个分支（比如if/else或异常路径），只在一个分支里delete，其他分支就真漏了 —— Valgrind 会如实报告每个执行路径的结果
一个能复现的最小例子
写这个代码并保存为 leak.cpp：
#include <iostream>
void leaky_func() {
int* p = new int[5];
// 忘记 delete[] p;
return; // 就在这里退出
}
int main() {
leaky_func();
return 0;
}
</iostream>
编译运行：
g++ -g -O0 -std=c++17 leak.cpp -o leak valgrind --leak-check=full ./leak
输出里你会看到类似：
==12345== 20 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==12345== at 0x...: operator new[](unsigned long) (in /usr/lib/...) ==12345== by 0x...: leaky_func() (leak.cpp:3) ==12345== by 0x...: main (leak.cpp:8)
关键点是最后一行明确指向 leak.cpp:3 —— 这就是 new int[5] 的位置，也是 return 前没清理的根源。
真正容易被忽略的是：Valgrind 只能告诉你“哪块内存漏了”，但不会自动指出“该在哪一行 delete”。如果函数逻辑复杂、多处 return、或有异常路径，得靠你顺着调用栈反推清理点，而不是依赖工具补全。
