内存泄漏大概是C++程序员踩过最多的坑之一。一个典型的场景是这样的：函数开头用new分配了一块内存，中间经过十几行逻辑，某条分支提前return了，或者某个调用抛出了异常，最后那行delete就永远执行不到。资源就这样悄悄泄漏了，而且编译器不会给出任何警告。C++给出的标准答案是RAII（Resource Acquisition Is Initialization，资源获取即初始化），它是这门语言最核心的编程思想之一，也是标准库智能指针、锁_guard等组件的设计基石。
RAII的核心原理：把资源生命周期绑定到对象生命周期
RAII的思想说起来很简单：资源的获取和释放，由类的构造函数和析构函数负责。构造对象时获取资源，对象离开作用域时，C++保证析构函数一定会被调用，资源也就一定会被释放。这里的“资源”不仅指内存，还包括文件句柄、数据库连接、互斥锁、网络套接字等一切需要显式释放的东西。
这个机制之所以可靠，是因为C++语言层面保证了栈对象在作用域结束时会自动析构——无论是正常执行到结尾、提前return，还是中途抛出异常，栈展开（stack unwinding）的过程中每个局部对象都会被正确析构。换句话说，我们把“记得释放资源”这个容易出错的程序员职责，转移给了编译器强制保证的语言机制。
一个最小的RAII封装大概长这样：
class FileGuard {
public:
// 构造时获取资源
explicit FileGuard(const char* path) : fp_(std::fopen(path, "r")) {
if (fp_ == nullptr) {
throw std::runtime_error("无法打开文件");
}
}
// 析构时释放资源， noexcept保证析构不抛异常
~FileGuard() {
if (fp_ != nullptr) {
std::fclose(fp_);
}
}
// 禁止拷贝，避免双重释放
FileGuard(const FileGuard&) = delete;
FileGuard& operator=(const FileGuard&) = delete;
FILE* get() const { return fp_; }
private:
FILE* fp_;
};
void readFile() {
FileGuard file("data.txt"); // 无论后续发生什么，文件一定会被关闭
// ... 读取逻辑，中途抛异常也没问题
} // 作用域结束，析构函数自动执行
注意上面代码中的细节：构造函数用了explicit防止隐式转换，拷贝构造和拷贝赋值被删除——这一点非常关键，如果不禁止拷贝，两个对象持有同一个指针，析构时就会对同一块资源释放两次，直接导致未定义行为。
智能指针：标准库提供的RAII武器库
自己写RAII类固然可行，但对于最常见的内存管理场景，标准库<memory>头文件早就准备好了现成的方案。三种智能指针各有分工，理解它们的差异是用好RAII的前提。
unique_ptr是首选。它表达独占所有权，同一时刻只有一个unique_ptr可以指向某个对象，不能拷贝只能移动。它几乎没有运行时开销，大小和裸指针一样（默认情况下），行为最接近手写的RAII类。任何情况下，只要资源有明确唯一的主人，就应该先用unique_ptr：
#include <memory>
#include <iostream>
struct Task {
Task() { std::cout << "Task构造\n"; }
~Task() { std::cout << "Task析构\n"; }
void run() { std::cout << "任务执行\n"; }
};
void process() {
auto task = std::make_unique<Task>();
task->run();
} // task离开作用域，Task自动析构
这里推荐用std::make_unique而不是直接new，因为它能保证异常安全（避免new成功但智能指针构造前抛异常的窗口），代码也更简洁。
shared_ptr处理共享所有权。当资源的确需要被多个对象共同持有、最后一个使用者离开时才释放，就用shared_ptr。它内部维护一个引用计数，每次拷贝计数加一，每次析构计数减一，归零时释放资源。代价是拷贝有原子操作的开销，且控制块会带来额外的内存占用。要特别警惕循环引用问题：A持有B的shared_ptr，B又持有A的shared_ptr，两者计数永远无法归零，资源照样泄漏。
weak_ptr打破循环。weak_ptr指向shared_ptr管理的对象但不增加引用计数，它是观察者而非所有者。使用时需要通过lock()临时提升为shared_ptr，如果对象已经释放，lock()返回空指针：
#include <memory>
struct Node {
std::shared_ptr<Node> next;
std::weak_ptr<Node> prev; // 用weak_ptr避免循环引用
~Node() { }
};
void buildList() {
auto a = std::make_shared<Node>();
auto b = std::make_shared<Node>();
a->next = b;
b->prev = a; // 不增加引用计数
// a、b离开作用域后都能正确析构
}
三者的选型可以总结为一句话：默认用unique_ptr，确实需要共享再用shared_ptr，需要观察但不拥有就用weak_ptr。所有权语义越明确，代码越不容易出错。
RAII的进阶应用与常见误区
RAII的应用远不止内存。std::lock_guard和std::unique_lock就是典型的RAII锁——构造时加锁，析构时解锁，彻底告别手动调用unlock的噩梦。数据库连接、线程、事务等资源也都可以用同样的模式封装。理解了这一点，你会发现RAII其实是一种通用的资源管理哲学。
实际使用中有几个容易踩的坑。第一，不要用裸指针初始化多个智能指针，下面的代码会导致双重释放：
int* p = new int(42); std::shared_ptr<int> a(p); std::shared_ptr<int> b(p); // 错误！两套独立引用计数，析构时delete两次
正确做法是从一开始就用make_shared创建，或者通过拷贝已有智能指针来传播所有权。
第二，析构函数不应该抛出异常。栈展开过程中如果析构函数抛出异常且未被捕获，程序会直接调用std::terminate终止。设计RAII类时应把析构函数标记为noexcept，并在内部吞掉或记录可能的错误。
第三，注意智能指针与C API边界的处理。很多第三方库返回裸指针，接手时可以用自定义删除器包装成unique_ptr：
// 包装C风格的资源，比如closesocket、SDL_FreeSurface等
auto resource = std::unique_ptr<SomeHandle, decltype(&closeHandle)>(
openHandle(), &closeHandle);
// resource离开作用域时自动调用closeHandle
最后要提醒的是，RAII解决的是“释放时机”问题，但不代表可以忽略对象生命周期的设计。悬垂指针、返回局部对象引用等问题依然存在，此时weak_ptr配合lock()检查是比裸指针安全得多的做法。把RAII内化成习惯，用对象生命周期思考资源管理，写出来的C++代码自然既高效又健壮。