_CrtDumpMemoryLeaks无输出最常见原因是未在程序正常退出前调用或未启用CRT调试堆；必须包含头文件、启用调试堆标志、避免exit()强制终止。
为什么 _CrtDumpMemoryLeaks 没输出泄漏信息？
最常见原因是没在程序退出前调用，或者没启用 CRT 调试堆。它只在程序正常退出（比如 main 返回）时检查堆状态，若进程被强制终止（如 exit(0)、崩溃、IDE 中点击停止）、或未初始化调试堆，就完全静默。
必须确保以下三点同时满足：
- 包含头文件：
#include <crtdbg.h></crtdbg.h> - 在
main开头启用调试堆：调用_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); - 不手动调用
exit()，让控制流自然落到main末尾（否则泄漏检测被跳过）
_CrtDumpMemoryLeaks 输出的“{123}”编号怎么对应代码？
这个数字是内存块的分配序号，不是行号，但可以配合 _CrtSetBreakAlloc(123) 在第 123 次分配时中断调试。前提是程序每次运行分配顺序一致（无多线程干扰、无随机容器重排等）。
实用技巧：
立即学习“C++免费学习笔记（深入）”；
- 把
_CrtSetBreakAlloc(123);放在main开头，然后 F5 启动，VS 会停在分配该内存的new或malloc调用处 - 如果序号每次不同，说明有非确定性分配（比如 STL 容器预分配、全局对象构造顺序），此时应结合
_CrtMemState做快照比对
多线程下 _CrtDumpMemoryLeaks 为什么不准？
CRT 调试堆本身不是线程安全的 —— 多线程同时 new/delete 可能导致内部计数错乱，甚至触发断言失败。它只适合单线程调试场景。
替代方案更可靠：
- 用 VS 自带的「诊断工具 → 内存使用」实时采样（无需改代码，支持多线程）
- Windows 平台可启用
_CRTDBG_MAP_ALLOC宏 +_set_new_handler自定义分配器做线程安全标记 - 跨平台项目建议直接切换到
AddressSanitizer（Clang/GCC/MSVC 均支持），它不依赖 CRT，且能精确定位释放后使用、越界等更多问题
Release 版本能用 _CrtDumpMemoryLeaks 吗？
不能。CRT 调试堆功能（包括所有 _Crt* 系列函数）仅在 Debug 版本链接 libcmtd.lib 时可用；Release 链接的是 libcmt.lib，调用 _CrtDumpMemoryLeaks 会链接失败或静默忽略。
如果必须在 Release 测试内存行为：
- 保持 Debug 和 Release 使用同一套内存管理逻辑，优先在 Debug 下复现并修复
- 用
VirtualQuery+HeapWalk手动遍历进程堆（Windows）或mallinfo/malloc_stats（Linux），但无法关联源码位置 - 真正要上线验证，应依赖 ASan 编译的 Release 版本（需关闭优化或用
-O1，否则行号可能错位）
别指望靠 Release 下加个 #define _CRTDBG_MAP_ALLOC 就能生效 —— 底层函数根本没编译进去。
