结论：检测靠工具+调试堆，避免靠智能指针+RAII，两者缺一不可；_CrtDumpMemoryLeaks是Visual Studio自带、零依赖、编译即用的Windows内存泄漏检测方式，需严格完成三步：定义_CRTDBG_MAP_ALLOC（置于所有头文件前）、包含和、调用_CrtDumpMemoryLeaks()或_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)，输出含文件名与行号，仅限MSVC调试版。
直接说结论：检测靠工具+调试堆，避免靠智能指针+RAII，两者缺一不可。只靠检测是被动挨打，只靠编码规范又容易漏掉边界情况。
用 _CrtDumpMemoryLeaks 快速定位 Windows 下的泄漏点
这是 Visual Studio 自带、零依赖、编译即用的检测方式，适合开发阶段日常自查。它不依赖外部工具，也不需要改构建流程，但仅限于 MSVC 调试版本。
关键三步必须全做，缺一不可：
-
#define _CRTDBG_MAP_ALLOC必须放在所有头文件之前（常见坑：放到了#include <crtdbg.h></crtdbg.h>之后） -
#include <crtdbg.h></crtdbg.h>和#include <stdlib.h></stdlib.h>都要包含（少一个就看不到行号） - 在
main函数末尾或程序退出前调用_CrtDumpMemoryLeaks()；更稳妥的做法是开头加_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);，让它自动触发
输出示例中会带具体文件名和行号：D:\proj\test.cpp(42) : {123} normal block at 0x00A7F5C8, 4 bytes long.——这比 Valgrind 在 Windows 上配置失败强太多。
立即学习“C++免费学习笔记（深入）”；
用 AddressSanitizer 捕获 new/delete 不配对和 use-after-free
AddressSanitizer（ASan）不是只查内存泄漏，它更擅长发现“泄漏的前置条件”：比如 new 后被覆盖、异常路径跳过 delete、delete 多次、访问已释放内存。这些才是真实项目里最常导致泄漏的根因。
启用方式极简（Clang/GCC/MSVC 均支持）：
- Clang/GCC：
clang++ -fsanitize=address -g test.cpp - MSVC（2019+）：
cl /fsanitize=address /Zi test.cpp
运行时一旦触发问题，会直接打印出栈帧、分配位置、释放位置、甚至变量名（如有调试信息）。注意：ASan 会显著拖慢运行速度、增大内存占用，**切勿在 Release 构建中开启**。
为什么 std::unique_ptr 比裸指针更安全，但不能乱用 std::shared_ptr
裸指针泄漏的本质是“所有权模糊”：谁该 delete？什么时候 delete？std::unique_ptr 用移动语义明确划清界限——资源只能有一个主人，离开作用域自动销毁，连 return 提前退出都不怕。
但 std::shared_ptr 容易埋雷：
- 循环引用：A 持有 B 的
shared_ptr，B 也持有 A 的shared_ptr→ 引用计数永远不为 0 → 对象永不析构 - 从裸指针构造：
shared_ptr<t>(new T)</t>是双倍危险：先new再包进智能指针，中间若抛异常就泄漏；正确写法永远是make_shared<t>()</t> - 跨线程传递时未加锁或未用原子操作，可能引发竞态释放
简单规则：默认选 std::unique_ptr；只有明确需要共享所有权且能保证无环时，才升级为 std::shared_ptr；环存在时，断环必须用 std::weak_ptr。
RAII 不是概念，是每个资源类都该写的构造/析构逻辑
很多人以为 RAII 就是“用智能指针”，其实它更底层：任何需要手动释放的资源（文件句柄、socket、mutex、GPU buffer），都该封装成一个类，把获取放构造函数、释放放析构函数。
典型错误写法：
FILE* f = fopen("data.txt", "r");
// ...处理
fclose(f); // 如果中间 throw exception，这行就跳过了
正确写法：
struct FileGuard {
FILE* f;
FileGuard(const char* name) : f(fopen(name, "r")) {}
~FileGuard() { if (f) fclose(f); }
FileGuard(const FileGuard&) = delete;
FileGuard& operator=(const FileGuard&) = delete;
};
这样哪怕 fread 抛异常，~FileGuard 仍会被调用。RAII 的威力不在语法糖，而在它把“一定会发生”的事，绑定到 C++ 最确定的机制上：对象生命周期。
真正难的不是学会 unique_ptr 或 _CrtDumpMemoryLeaks，而是把“谁负责释放”这个判断，变成写每一行代码时的肌肉记忆。比如看到 new，下意识停顿半秒问自己：它会被谁 delete？有没有异常路径？有没有多线程竞争？这种条件反射，比任何工具都管用。
