启动内存诊断前须确认：Debug配置、启用本机代码调试、诊断工具窗口已打开；否则无法显示时间线或捕获快照。
启动内存使用情况诊断工具前必须确认的三件事
不满足这三项，诊断工具窗口不会显示内存时间线，更不会捕获快照：
— 必须在 Debug 配置下运行（Release 默认禁用堆分配跟踪）；
— 项目属性中需启用“启用本机代码调试”（即使纯 C++ 项目也要勾选，否则 CRT 调试堆不生效）；
— 启动前确保“调试 > Windows > 显示诊断工具”已打开，且未被手动关闭过。常见错误是只点了“开始调试”却没留意右下角是否弹出诊断窗口——它默认只在首次调试时自动浮现，之后若关闭就再也不会自己回来。
_CrtSetDbgFlag + _CRTDBG_MAP_ALLOC 是泄漏报告能定位到行号的前提
仅靠 Visual Studio 图形化工具无法告诉你 new 发生在哪一行；真正让泄漏报告带出文件名和行号的，是这两样东西：
— #define _CRTDBG_MAP_ALLOC 必须放在所有 #include 之前（尤其不能在 stdafx.h 或 pch.h 之后）；
— #include <crtdbg.h></crtdbg.h> 必须存在，且不能被预编译头屏蔽；
— _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF) 要在 main() 或 WinMain() 开头立即调用，晚于任何 new 都会导致该次分配不被记录。
漏掉任一条件，泄漏报告只会显示类似 {1234} normal block at 0x000002A1F1C8E750, 4 bytes long，毫无调试价值。
快照对比不是看“总内存”，而是盯住“托管/本机堆差异项”
在诊断工具窗口点击“拍摄快照”后，不要直接看顶部数字——那只是当前总占用。真正暴露问题的是两次快照之间的对象增减列表：
— 展开“本机堆”节点，重点找 new、malloc、HeapAlloc 对应的类型（如 int[]、char*、自定义类名）；
— 如果某类型在第二次快照中“新增实例数”为正且“已释放实例数”为 0，基本就是泄漏点；
— 注意“大小”列单位是字节，但“计数”列才是关键：一个 std::vector 占几 MB 不可怕，但若它下面的 char* 实例数持续+1，说明底层 buffer 没释放；
— 右键某行选择“转到源”可能失败（尤其内联函数或模板），此时要结合 CRT 报告里的分配序号，用 _CrtSetBreakAlloc(1234) 在对应分配处打断点。
内存时间线峰值不代表泄漏，但“不回落”就是强信号
图中尖峰本身无害——比如加载一张大图、解析一个 JSON，内存冲高后回落属正常；真正危险的是平台型抬升：
— 连续操作三次（如打开→关闭→再打开同一窗口），内存曲线每次都在前一次基础上抬高一段；
— 或单次操作后，内存长时间（>5 秒）不回落，且“诊断工具”窗口底部显示“正在收集 GC 数据…”卡住；
— 此时别急着看快照，先暂停调试器，打开“调试 > 窗口 > 内存 > 内存1”，输入疑似泄漏对象的指针地址（如从监视窗口复制的 pBuffer 值），直接观察其内容是否仍被写入或引用；
— 若地址内容已乱码但指针仍非空，大概率是野指针误用而非泄漏；若内容完好但无人访问，才进入快照比对流程。
立即学习“C++免费学习笔记（深入）”；
实际排查中，最难缠的不是找不到泄漏，而是泄漏点藏在第三方库或 STL 容器内部（比如std::map 的红黑树节点）。这时候 CRT 报告的文件名会显示 xtree 或 xmemory，需要回溯到你最后一次插入/构造该容器的业务代码行——而不是盯着系统头文件改。 
