Valgrind 必须在 Linux 或 WSL2 环境运行，Sublime Text 仅能作为调用入口和日志查看器；其内存泄漏检测依赖 valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all 等命令，且编译必须带 -g 调试符号，否则无法定位源码行号。
Valgrind 必须在 Linux 下跑，Sublime 只能调用它
Valgrind 本身不支持 Windows/macOS 原生运行，哪怕你在 WSL2 或 Docker 里装了 Sublime，真正执行 valgrind 的仍是底层 Linux 环境。Sublime Text 没有内置内存分析能力，它只能作为“快捷启动器”或“日志查看器”——比如配置一个 Build System，把 g++ -g 编译和 valgrind --leak-check=full 连起来，但所有检测逻辑、堆栈追踪、泄漏分类都由 Valgrind 完成。
常见误操作是：在 Windows 主机上直接装 Valgrind for Windows（不存在），或试图让 Sublime 插件“自动分析 cpp 文件”——那只是语法高亮或 clang-tidy 静态检查，和运行时内存泄漏无关。
- 确认你的 Sublime 运行环境：必须是 Linux 或 WSL2，且已安装
valgrind（which valgrind能返回路径） - Sublime 的 Build System 中，
shell_cmd字段必须调用真实 shell，不能写成 Windows 风格路径（如C:\valgrind\...） - 若用 EasyClangComplete 插件，它默认不触发
valgrind；要检测泄漏，仍需手动终端执行或自定义 build
编译必须带 -g，否则 Valgrind 只显示地址不显示行号
没有调试符号，valgrind 输出里全是 0x484A2F3 这类地址，你根本没法定位到 main.cpp:4 的 new int[10]。这不是可选项，是硬性前提。
典型错误是：用 Release 模式编译（-O2 -DNDEBUG）后直接丢给 Valgrind，结果看到一堆“by 0x10919E”，只能靠猜。
立即学习“C++免费学习笔记（深入）”；
-
g++ -g -o myapp main.cpp—— 最小可行命令，-g不能省 - 如果用了 CMake，确保
CMAKE_BUILD_TYPE是Debug，或显式加add_compile_options(-g) - 静态库/第三方 SDK 若没提供
.debug符号，Valgrind 会显示???行号，此时需联系供应商或自己重编译带-g
--leak-check=full 和 --show-leak-kinds=all 必须同时用
只开 --leak-check=full 会漏掉间接泄漏（indirectly lost）和可能泄漏（possibly lost）。而 --show-leak-kinds=all 才能让 Valgrind 区分三类泄漏：definitely lost（明确没释放）、indirectly lost（主对象释放了但子指针没清）、possibly lost（循环引用或栈指针残留）。
例如：一个 std::vector<int*> 存了 10 个 new int，但 vector 析构时只清空容器没 delete 指针——Valgrind 会标为 indirectly lost，单看 definitely lost 会以为没问题。
- 完整命令示例：
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes ./myapp -
--track-origins=yes对未初始化内存很有用，但对纯泄漏检测非必需；开启后性能下降明显，可先不用 - 输出里出现
still reachable不代表泄漏（比如全局缓存、log buffer），但要人工确认是否合理；definitely lost才是真问题
离线排查时，--log-file 比终端输出更可靠
终端滚动太快，尤其程序跑几分钟、输出几千行时，definitely lost 往往被刷走。用 --log-file=valgrind.log 写文件，再用 Sublime 打开搜索，才是实际工作流。
别依赖 Sublime 的“Build Results”面板——它只捕获 stdout/stderr，而 Valgrind 默认把报告打到 stderr，但某些构建插件会截断或乱码。
- 推荐命令：
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --log-file=valgrind.log ./myapp 2>/dev/null -
2>/dev/null是为了屏蔽 Valgrind 自身的进度提示（如 “==12345== …”），只留泄漏报告进文件 - Sublime 中用
Ctrl+F搜definitely lost或at 0x，然后用addr2line -e myapp -f -C 0x10919E查源码行（需提前装binutils）
真正麻烦的不是找到泄漏点，而是泄漏发生在第三方库（如 FFmpeg、OpenCV）内部，或者多线程竞争导致释放时机错乱——这时 --tool=helgrind 比 memcheck 更有用，但输出解读成本高得多。
