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