VSCode不检测内存泄漏，需用Valgrind等外部工具；Valgrind需g++ -g -O0编译，配合--leak-check=full --show-leak-kinds=all等参数，并导出日志在VSCode中正则搜索定位泄漏源头。
VSCode 本身不检测内存泄漏，必须靠外部工具；Valgrind 是 Linux 下最可靠的选择，但不能直接集成进 VSCode 调试器——它得在终端里独立运行，再把输出导入 VSCode 查看。
Valgrind 必须用 g++ -g -O0 编译才能准确定位
编译时漏掉 -g，Valgrind 报错只会显示 ???:???；用 -O2 或更高优化等级，new 可能被内联、变量被消除，泄漏栈回溯会断在 operator new 底层，根本看不到你自己的函数名和行号。
-
-g是硬性前提：没有它，所有“哪一行分配的”信息全失效 -
-O0比-O1更稳妥：尤其涉及异常路径、早期 return、多分支时，-O1仍可能抹掉关键帧 - 别信
cmake -DCMAKE_BUILD_TYPE=Debug就够了——它默认不加-O0，得显式补上：set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0")
valgrind --leak-check=full --show-leak-kinds=all 才算真正开全
只写 --leak-check=full 会漏掉 still reachable 和 indirectly lost 类型。这些未必是 bug，但得人工确认：比如全局 std::vector 末尾还活着的内存，可能是缓存设计，也可能是忘了 .clear()。
-
definitely lost：优先修，100% 是泄漏（new/malloc 后没配对 delete/free） -
possibly lost：大概率是 RAII 对象析构晚于 main 结束，或 STL 临时对象未清理，先别急着改代码 -
still reachable：检查是否为预期行为（如日志缓冲区、单例对象），不是所有“没释放”都等于 bug - 加
--track-origins=yes会显著拖慢速度，只在怀疑未初始化内存导致间接泄漏时启用
VSCode 里查 Valgrind 输出，别只盯着终端滚动条
Valgrind 输出动辄几百行，直接扫终端容易漏关键栈。更高效的做法是把输出导出成文件，在 VSCode 里用搜索和折叠功能定位：
- 运行：
valgrind --leak-check=full --show-leak-kinds=all ./myapp 2> valgrind.log（注意重定向 stderr） - 在 VSCode 中打开
valgrind.log，搜索at 0x.*:.* (.*\.cpp:\d+)这类模式（可用正则搜索） - 点开带
by 0x.*: main (main.cpp:42)的块，这行才是你该去修的源头 - 别被
malloc或operator new的底层调用栈迷惑——重点看倒数第二三级，那是你的业务代码入口
Valgrind 不报错 ≠ 没泄漏，尤其当程序用 fork()、多线程、或加载了未用 ASan 编译的第三方库时，检测盲区真实存在；真要覆盖全场景，得配合 AddressSanitizer（加 -fsanitize=address,leak）和代码静态扫描一起看。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
