leak-check=full 是唯一实用的选择，它输出完整栈回溯以精确定位泄漏点；必须配合 --show-leak-kinds=all 才能覆盖 possibly lost 和 reachable 等关键类型；--track-origins=yes 用于甄别未初始化内存导致的误报，但会降低性能2–3倍。
leak-check=full 是唯一实用的选择
设成 yes 或 summary 基本没用——它只告诉你“有泄漏”，不告诉你哪一行、哪个函数、哪次分配漏了。full 才会输出完整的栈回溯，让你能直接定位到 malloc 或 new 那一行。省略这个参数默认是 summary，等同于白跑。
--show-leak-kinds=all 必须跟上
leak-check=full 默认只报 definitely lost 和 indirectly lost，但很多真实泄漏藏在 possibly lost 里（比如容器指针被覆盖但原始地址还在栈上），reachable 则常暴露 RAII 管理疏漏（如全局 shared_ptr 持有资源却未释放）。不加 --show-leak-kinds=all，等于主动过滤掉一半线索。
别信 --leak-check=heuristics 或 auto
Valgrind 没有 heuristics 这个合法值，输进去会报错 unrecognized option；auto 是旧版本残留，新版本已弃用，行为不可控。实测中只要写错就直接退出，连程序都不会运行。坚持用 full，别碰非文档值。
leak-check 和 track-origins 要配对看
有些“泄漏”其实是未初始化内存导致的误判（比如把野指针当有效地址传给 free），这时单看 leak-check=full 输出会误导你去查释放逻辑。必须加 --track-origins=yes，才能确认是不是 malloc 返回值根本就没初始化就被用了。不过注意：这个选项会让运行慢 2–3 倍，调试阶段开，回归测试可关。
possibly lost 就停在那里反复改代码，却没意识到那行 new 其实被一个没声明为 noexcept 的析构函数吞掉了异常——这种链路，只有 --track-origins=yes + 手动翻调用栈才能串起来。
