能，但只在 linux 下有效；valgrind 通过拦截内存操作跟踪分配与释放，需 -g 编译、正常退出，并用 –leak-check=full 和 –show-leak-kinds=all 参数检测 c++ 内存泄漏。
Valgrind 能检测 C++ 内存泄漏吗？能，但只在 Linux 下有效
Valgrind 是目前最可靠的动态内存泄漏检测工具之一，但它本身不支持 windows 或 macos。如果你在 macOS 上看到 valgrind 命令报错或提示“not supported”，不是配置问题，是平台限制。必须在 Linux（如 ubuntu、centos）环境运行。
它通过拦截 malloc、new、delete、free 等底层调用，跟踪每一块堆内存的分配与释放状态。C++ 中未配对的 new/delete 或 new[]/delete[] 都会被捕获。
- 编译时需加
-g保留调试信息，否则报告中看不到源码行号 - 避免使用
-O2或更高优化等级，部分内联可能绕过检测 - 程序需正常退出（非
abort()、kill -9或崩溃），否则 Valgrind 无法完成最终统计
怎么用 valgrind 检查 C++ 内存泄漏？关键参数不能漏
基础命令是：valgrind --leak-check=full --show-leak-kinds=all ./your_program。其中两个参数缺一不可：
-
--leak-check=full：启用完整泄漏分析（默认是 summary，会漏细节） -
--show-leak-kinds=all：显示definitely lost、indirectly lost、possibly lost、still reachable四类结果 - 加上
--track-origins=yes可追溯未初始化内存的来源（对野指针排查有帮助） - 若程序带参数，直接跟在可执行文件后，例如：
./your_program arg1 arg2
注意：still reachable 不算泄漏（通常是全局/静态指针持有内存），但 definitely lost 和 indirectly lost 必须修复。
立即学习“C++免费学习笔记（深入）”；
C++ 常见导致 valgrind 报告泄漏的写法
Valgrind 不会误报堆内存未释放，但有些 C++ 习惯会让它“看起来像泄漏”：
- 用
new分配，却用free()释放（或反之）——行为未定义，Valgrind 通常标记为definitely lost - 用
new[]分配数组，却用delete（不带方括号）释放——析构函数不调用，内存不归还 - 智能指针管理不一致：比如
std::shared_ptr循环引用，或裸指针和智能指针混用导致提前释放/悬空 - 全局
std::map或std::vector持有 new 出来的对象，但程序结束前没显式清理——Valgrind 会标为still reachable，但实际是设计缺陷
valgrind 报告里 “suppressed” 是什么？别忽略它
Valgrind 启动时会加载系统库的 suppress 文件（如 /usr/lib/valgrind/default.supp），把已知的、无害的库内部泄漏（如 glibc 初始化内存）过滤掉。但如果看到大量 suppressed: X bytes in Y blocks，说明：
- 你的程序链接了某些未适配 Valgrind 的第三方库（如旧版 qt、opencv 动态链接版本）
- 你用了自定义的内存分配器（如 tcmalloc、jemalloc），而没提供对应 suppress 规则
- 不是“没问题”，而是“被隐藏了”——建议临时用
--suppressions=指向空文件测试，确认是否真有新增泄漏
真正难定位的泄漏，往往藏在间接路径里：比如一个 new 出的对象被多个容器反复转移所有权，最后某处忘了 reset() 或 clear()。这时候得结合 --track-origins=yes 和源码逐层回溯。