Valgrind必须在终端独立运行，VSCode不提供原生集成；需用g++ -g -O0编译，配合--leak-check=full --show-leak-kinds=all运行并重定向输出至valgrind.log，在VSCode中用正则搜索定位泄漏源头。
Valgrind 必须在终端独立运行，VSCode 不提供原生集成
VSCode 本身不执行内存检测，valgrind 是一个外部命令行工具，它运行时会接管整个进程的执行环境——这和 GDB 调试器的 attach 模式完全不同。你无法在 VSCode 的 launch.json 里加个配置就“启动带 Valgrind 的调试会话”。所有试图把 valgrind 塞进 gdb 或 cppvsdbg 启动流程的做法，最终都会卡在进程控制权冲突上。
正确做法只有一种：在 VSCode 内置终端（或系统终端）中手动运行 valgrind 命令，再把输出导入编辑器分析。这不是妥协，而是工具链分工决定的——VSCode 负责代码呈现与文本处理，valgrind 负责底层内存 instrumentation。
编译必须带 -g -O0，缺一不可
漏掉 -g，valgrind 输出全是 ???:???；用了 -O2 或更高优化等级，栈帧会被裁剪、内联展开，泄漏点直接跳到 operator new 底层，根本看不到你自己的 main.cpp:42。
-
g++ -g -O0 -o myapp main.cpp是最低安全要求 - CMake 用户别只信
-DCMAKE_BUILD_TYPE=Debug—— 它默认不加-O0，得显式补：set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0") - 如果项目用 Ninja 或 Make，检查实际执行的编译命令是否真含
-g -O0，别被缓存误导
--leak-check=full --show-leak-kinds=all 才算开全检测
只写 --leak-check=full 会漏掉 still reachable 和 indirectly lost 类型。这些不是“错误”，但必须人工判断：
-
definitely lost：优先修，100% 是new/malloc后没配对delete/free -
possibly lost：大概率是 RAII 对象析构晚于main结束，或 STL 临时对象残留，先别急着改 -
still reachable：检查是否为预期行为（如全局缓存、单例），不是所有“没释放”都等于 bug
加 --track-origins=yes 仅在怀疑未初始化内存导致间接泄漏时启用——它会让速度下降 5–10 倍，日常扫描没必要。
在 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的底层调用栈迷惑，倒数第二三级才是你的业务代码入口
真正难的不是跑出报告，而是区分哪些 still reachable 是设计使然、哪些 possibly lost 实际已构成资源滞留。这需要结合代码生命周期理解，没法靠工具自动判定。
