内存泄漏指未释放动态分配的内存或资源，导致堆内存持续增长；RAII通过将资源绑定到对象生命周期来预防，但对全局对象、线程局部存储、dlopen插件及longjmp等场景无效。
内存泄漏在 C++ 里到底意味着什么
它不是程序崩溃，而是你 new 了内存却没 delete，或者 malloc 了却没 free，导致进程的堆内存持续增长、最终耗尽。更隐蔽的是：对象构造时申请资源（比如文件句柄、socket），但析构函数没释放——这也算内存泄漏的“远亲”。RAII 不是银弹，但它能让你在 95% 的日常场景里，根本写不出泄漏代码。
RAII 的核心不是“用智能指针”，而是“资源即对象”
关键在于：把资源生命周期绑定到栈对象的构造/析构上。不是所有资源都适合用 std::shared_ptr，也不是所有对象都该被“智能指针化”。真正起作用的是——
- 资源获取即初始化：构造函数里申请，失败就抛异常，不留下半成品对象
- 资源释放即销毁：析构函数里无条件释放，哪怕提前 return 或 throw 也保证执行
- 禁止裸指针跨作用域传递：一旦出现
new后赋给非 RAII 对象（比如普通int*成员），RAII 就失效
例如打开文件：
class FileGuard {
int fd_;
public:
FileGuard(const char* path) : fd_(open(path, O_RDONLY)) {
if (fd_ == -1) throw std::runtime_error("open failed");
}
~FileGuard() { if (fd_ != -1) close(fd_); }
// 禁用拷贝，允许移动（可选）
FileGuard(const FileGuard&) = delete;
FileGuard& operator=(const FileGuard&) = delete;
};std::unique_ptr 和 std::shared_ptr 哪个更容易踩坑
std::unique_ptr 安全边界清晰：独占所有权、不可拷贝、移动后原指针变空。但常见错误是——
立即学习“C++免费学习笔记（深入）”；
- 用
get()拿到裸指针后存到别处（比如传给 C API 并长期持有），忘了自己仍是所有者 - 循环引用：两个
std::shared_ptr互相持有时，引用计数永远不为 0，导致泄漏 - 自定义删除器写错：比如
std::shared_ptr<int>(new int, [](int* p){ delete p; })</int>看似正常，但如果传入的是数组，delete就 UB
真要管理动态数组，请用 std::unique_ptr<int></int>，它会自动调用 delete[]。
哪些地方 RAII 压根不起作用
RAII 依赖对象生命周期可控。以下场景它管不了——
- 全局或静态对象的构造函数里分配资源：如果构造失败，C++ 标准不保证其析构会被调用
- 线程局部存储（
thread_local）对象，若线程异常终止，析构可能被跳过 - 通过
dlopen加载的插件中分配的资源，主程序卸载时无法触发其 RAII 对象析构 - 用
longjmp跳出作用域：栈展开被绕过，析构函数不执行（C++ 中应避免setjmp/longjmp）
这些地方得靠人工检查 + 工具辅助（比如 ASan、Valgrind），RAII 只负责它能管的那一块。
最难防的泄漏，往往藏在“看起来很安全”的封装里：比如一个类内部用 std::vector 存数据，但忘了重写移动构造函数，导致浅拷贝后原始对象析构时清空了本该移交的数据——这种 bug 不报错，只悄悄泄漏。
