Visual Studio CRT调试堆可检测malloc等C风格内存泄漏，需在main开头调用_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)；它不捕获new/delete泄漏，除非重载operator new调用_malloc_dbg；{123}为分配序号，可用于_CrtSetBreakAlloc定位，client block多见于MFC场景；泄漏报告为空常见于非Debug配置、异常退出、多线程未同步或检查过早。
怎么用 Visual Studio CRT 调试堆检测内存泄漏
Visual Studio 的 CRT（C Runtime）调试堆在 Debug 模式下默认启用，只要程序退出时还有未释放的 malloc、calloc、realloc 或 _aligned_malloc 分配的内存，就会在输出窗口打印泄漏报告。但注意：它**不检测 new/delete 的泄漏**（除非你重载了全局 operator new 并调用 _malloc_dbg），也不捕获 STL 容器内部泄漏（如未析构导致的资源滞留）。
关键前提是：必须在程序入口（比如 main 或 WinMain）开头调用以下代码开启详细报告：
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
否则即使有泄漏，也不会自动报告。常见错误是只设了 _CRTDBG_ALLOC_MEM_DF 却漏掉 _CRTDBG_LEAK_CHECK_DF，结果什么也不输出。
为什么 new 分配没被 CRT 报告出来
CRT 调试堆只拦截 C 风格分配函数（malloc 系列），而 C++ 的 new 默认调用的是系统堆或 operator new 实现，不经过 _malloc_dbg。要让 new 也被追踪，需手动替换全局 operator new：
- 在头文件中定义：
#ifdef _DEBUG #define _CRTDBG_MAP_ALLOC #include
void* operator new(size_t size) { return _malloc_dbg(size, _NORMAL_BLOCK, __FILE__, __LINE__); } void operator delete(void* ptr) noexcept { _free_dbg(ptr, _NORMAL_BLOCK); } #endif - 必须确保所有
.cpp文件都包含该头，且定义顺序不能晚于任何new使用点 - 不建议在 Release 中保留该重载；可用
#ifdef _DEBUG严格隔离
否则会出现链接重复定义错误，或某些 new 调用绕过重载（比如模板实例化提前生成了默认 operator new）。
泄漏报告里 {123} 和 client block 是什么意思
输出类似：
Detecting memory leaks...
Dumping objects ->
{123} normal block at 0x000001A2F4F72EB0, 8 bytes long.
Data: < > CD CD CD CD CD CD CD CD
Object dump complete.
{123} 是分配序号，表示这是程序运行
_CrtSetBreakAlloc(123); // 下次分配到第 123 次时中断然后调试定位源头。
client block 表示该内存块被标记为用户数据（通过 _CLIENT_BLOCK 类型分配），常用于 MFC 或自定义内存池；若看到大量 client block 泄漏，检查是否忘了调用对应清理函数（如 AfxFreeMemory）或 MFC 对象未正确销毁。
为什么断点没停住、或者泄漏报告为空但怀疑还有泄漏
几个高频原因：
- 项目配置不是
Debug，或预处理器定义里没开_DEBUG—— CRT 调试功能仅在_DEBUG定义下编译生效 - 程序异常终止（如
abort()、访问违规、未捕获异常），导致atexit注册的泄漏检查没执行 - 使用了多线程且主线程先退出，子线程还在 malloc —— CRT 泄漏检查只在主线程退出时触发一次，此时其他线程分配可能未被统计
- 调用了
_CrtDumpMemoryLeaks()但位置太早（比如在main结束前就调了），而后续还有分配；应确保它在所有资源释放之后、程序真正退出前调用（或依赖自动检查）
真正难查的泄漏往往发生在 DLL 加载/卸载过程、静态对象构造/析构顺序中，CRT 工具对此无能为力，得换用 Application Verifier 或 VS 自带的「诊断工具 → 内存使用」实时快照比对。
