默认不显示泄漏报告是因为CRT调试堆仅在正常退出时触发检测，若未手动调用_CrtDumpMemoryLeaks()、使用非正常退出路径、或在Release模式下均无法输出；需在main末尾显式调用并确保Debug配置。
为什么 _CrtSetDbgFlag 开启后没看到泄漏报告
默认情况下，CRT 调试堆只在程序退出时检查泄漏，但如果你用了 ExitProcess、发生未处理异常、或主线程调用 _endthreadex 等非正常退出路径，_CrtDumpMemoryLeaks 根本不会触发。更常见的是：你开了标志，但没在 main 返回前手动调用泄漏打印函数。
- 必须在
main函数末尾（或所有全局对象析构完成后）显式调用_CrtDumpMemoryLeaks()，不能只靠进程退出自动触发 - 如果用了 ATL/MFC 应用框架（比如
CWinApp），main不是你写的入口，得在InitInstance返回前、或重载ExitInstance里调用 - 多线程下，只有主线程退出时才会 dump；其他线程中分配的内存若未释放，会被算作泄漏，但堆栈信息可能不完整
_CrtSetBreakAlloc 怎么精准打断第 127 次分配
CRT 给每次 malloc/new 分配了一个递增的分配序号（allocation order），泄漏报告里会显示类似 {127} 的编号。你可以用这个编号让程序在第 127 次分配时中断，直接定位到泄漏源头。
- 在
main开头加：_CrtSetBreakAlloc(127);，然后调试运行，VS 会停在对应malloc或operator new内部 - 注意：序号是全局单调递增的，包括 CRT 内部、MFC、甚至 STL 容器的临时分配；建议先跑一次拿到泄漏报告，再复现并记下准确序号
- 如果用的是
new，确保已重载全局operator new并调用了_malloc_dbg（MSVC 默认做了，但自定义 new 时容易漏）
泄漏报告里显示 f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c(1095) 是啥意思
这是 CRT 调试堆内部文件路径，说明分配发生在 CRT 自己的代码里，不是你的源码行。常见于：STL 容器扩容（如 std::vector::push_back 触发 realloc）、std::string 隐式分配、或 CRT 对 FILE* 缓冲区的管理。
- 别急着怀疑 CRT 有 bug——大概率是你持有某个容器或对象的指针/引用，但忘了释放其底层资源（比如没 delete 一个指向
vector的裸指针） - 启用堆栈记录：
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_DELAY_FREE_MEM_DF);并配合_CrtMemCheckpoint做前后对比，缩小可疑分配范围 - VS 调试器里打开“调用栈”窗口，看中断时的上层调用链；如果堆栈顶是
std::vector::_Reallocate，就回去查哪个 vector 生命周期失控了
Release 版为啥完全看不到泄漏信息
_Crt* 系列函数仅在 Debug 模式（即定义了 _DEBUG 且链接 MTd/MDd）下有效。Release 下这些调用被预处理器直接移除，连符号都不留。
立即学习“C++免费学习笔记（深入）”；
- 不要试图在 Release 配置里加
#define _CRTDBG_MAP_ALLOC—— 它依赖 debug heap 实现，强行开启只会导致链接失败或运行时崩溃 - 真要测 Release 泄漏，得换方案：用 Windows Performance Toolkit（WPR/WPA）抓堆事件，或集成
HeapWalk+GetProcessHeap手动遍历（但无法关联源码行） - 日常开发请坚持在 Debug 下完成内存验证；把 Debug 配置当成「带内存审计的开发环境」，而不是临时开关
最常被忽略的一点：CRT 调试堆对 VirtualAlloc、HeapAlloc 等直接系统调用完全无感知——它只监控 malloc/new 及其 CRT 封装。如果你混用了 HeapAlloc 和 delete，CRT 不报错，但内存确实泄漏了。
