内存泄漏必须用工具运行时检测，valgrind和addresssanitizer是最可靠方案；valgrind需-g编译、禁用lto，关注definitely lost；asan需显式加-fsanitize=address,leak且用-o1。
直接上结论：内存泄漏不是靠“猜”或“看日志”能定位的，必须用工具跑一遍运行时行为；Valgrind 和 AddressSanitizer 是目前最可靠、开箱即用的两个方案，其他方法（如重载 new/delete）只适合极简场景或辅助验证。
Valgrind memcheck 能查什么、怎么用才不白跑
它不是“编译期检查”，而是把你的程序加载进一个虚拟执行环境，全程监控每一块堆内存的分配、释放、读写行为。关键点在于：必须带 -g 编译，否则连哪一行出的问题都看不到；不能用 strip 或启用 LTO 优化（-flto），否则符号丢失，报告变成一堆地址。
-
definitely lost是最高优先级线索——说明指针彻底丢了，比如函数返回前没delete，或者unique_ptr没被 move 出作用域就结束了 -
indirectly lost往往是definitely lost的连锁反应，先修根因，这类会自动消失 -
still reachable多数是全局/静态对象持有指针，不算泄漏，但要确认是不是本该在main结束前清理的缓存 - 如果程序一启动就卡住或报
Invalid read of size X，说明有越界访问，这比泄漏更紧急，得先 fix
AddressSanitizer 编译即带检测，但要注意链接和运行时限制
ASan 是编译器插桩实现的，速度快、误报少，且支持 macOS/Linux/Windows（MSVC 也有对应版本）。但它默认不开启内存泄漏检测——必须显式加 -fsanitize=address,leak，否则只报越界、UAF，漏掉泄漏本身。
- 编译命令示例：
g++ -fsanitize=address,leak -g -O1 your_file.cpp -o your_program（-O1是安全上限，-O2可能导致漏报） - 运行时报
LeakSanitizer: detected memory leaks才算真正触发，否则只是开了 ASan 没开 LSan - 它无法检测
malloc/free配对问题（比如new配free），这种错误归UBSan管 - 动态库中泄漏可能不显示源码行号，需确保所有 so 都用相同 Sanitizer 选项编译
为什么重载 global new/delete 容易误导人
自己实现 operator new 记录分配、用 map 存指针，在 main 结束后遍历未释放项——听起来很直观，但实际落地全是坑：
- 第三方库（如 Qt、Boost）可能绕过 global
new，走自己的分配器，你的统计完全不覆盖 - C++ 运行时自身（如
std::string内部缓冲区）也可能调用 globalnew，但你没看到调用栈，误判为“你的代码泄漏” - 多线程下没加锁，
memory_map插入/删除可能崩溃，反而引入新 bug - 它只能告诉你“有没释放”，不能告诉你“谁分配的、在哪丢的”，定位效率远低于 Valgrind 的堆栈回溯
Visual Studio CRT Debug 在 Windows 下的实操要点
Windows 上不用装额外工具，但必须用 Debug 模式编译 + 启用调试堆，否则 _CrtDumpMemoryLeaks() 什么也打不出来：
- 确保项目属性里：Configuration → “Debug”，C/C++ → “General” → “Debug Information Format” 设为
Program Database (/Zi) - 代码开头加：
#define _CRTDBG_MAP_ALLOC，然后在main开头调用_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); - 输出里的
{1234}是分配序号，配合_CrtSetBreakAlloc(1234)可让程序在第 1234 次分配时断下，精准定位源头 - 注意：Release 模式下这个机制完全失效，别指望用 Release 版做泄漏分析
最常被忽略的一点：泄漏往往不在主流程里，而在异常路径、信号处理函数、atexit 回调或子线程 detach 后——这些地方的 new 很容易被漏掉 delete，而工具报告里它们和普通泄漏一样安静，得人工逐个路径核对。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
