RAII是C++管理资源的底层契约，要求资源在构造时获取、析构时无条件释放，依赖栈对象生命周期自动保证，不靠手动调用或try/finally。
RAII 不是语法糖，也不是可选技巧，而是 C++ 管理资源（内存、文件、锁、句柄等）的底层契约。它要求：资源必须在对象构造时获取，在析构时无条件释放——靠栈对象生命周期自动保证，不依赖程序员手动调用 close() 或 delete。
为什么不用 try/finally 或手动 free？
C++ 没有 finally，异常可能在任意位置抛出；手动管理极易漏掉释放点，尤其在多分支或早期返回场景下。RAII 把“获取-释放”绑定到对象生存期，由编译器保证析构执行（除非 std::terminate 被触发）。
常见错误现象：
• 函数中途 return 导致 fclose(fp) 未执行
• 异常传播跳过 delete ptr
• 多线程中忘记 pthread_mutex_unlock()
- RAII 对象必须是栈分配（或智能指针托管），堆上裸
new的对象无法自动析构 - 析构函数不能抛异常（否则栈展开时二次崩溃），需用
noexcept显式标注 - 移动语义下，资源所有权应转移而非复制（如
std::unique_ptr的move构造）
典型 RAII 类怎么写？
以封装文件描述符为例，关键在于：构造函数负责 open()，析构函数负责 close()，且禁止拷贝（避免双重关闭）：
立即学习“C++免费学习笔记（深入）”；
class FileDescriptor {
int fd_;
public:
explicit FileDescriptor(const char* path) : fd_(open(path, O_RDONLY)) {
if (fd_ == -1) throw std::runtime_error("open failed");
}
~FileDescriptor() noexcept {
if (fd_ != -1) close(fd_);
}
FileDescriptor(const FileDescriptor&) = delete;
FileDescriptor& operator=(const FileDescriptor&) = delete;
FileDescriptor(FileDescriptor&& other) noexcept : fd_(other.fd_) {
other.fd_ = -1;
}
FileDescriptor& operator=(FileDescriptor&& other) noexcept {
if (this != &other) {
if (fd_ != -1) close(fd_);
fd_ = other.fd_;
other.fd_ = -1;
}
return *this;
}
};使用时：FileDescriptor f("/etc/passwd"); —— 出作用域自动关 fd，无需关心 return 或异常路径。
标准库里哪些是 RAII？
几乎所有带“自动管理”语义的类都是 RAII 实现：
-
std::vector：构造时分配内存，析构时delete[] -
std::lock_guard：构造时加锁，析构时解锁（即使临界区 throw 也安全） -
std::unique_ptr：构造时接管裸指针，析构时delete -
std::fstream：构造时可打开文件，析构时自动close()
注意：std::shared_ptr 是 RAII，但它的析构只减少引用计数；真正释放资源发生在最后一个引用消失时——这仍是 RAII，只是延迟了释放时机。
容易被忽略的坑
RAII 的可靠性高度依赖正确实现。几个隐蔽陷阱：
- 析构函数里调用虚函数：此时虚表已部分销毁，行为未定义
- 在构造函数中抛异常：对象未完全构造，析构函数不会被调用（但已构造的成员会析构）
- 把 RAII 对象存进容器后又用
std::move：原对象状态必须置为“无效但可析构”（如 fd 设为 -1） - 跨 DLL 边界传递 RAII 对象：若两边 STL 版本/ABI 不一致，析构可能崩溃
最常被低估的一点：RAII 解决的是“何时释放”，不是“是否该释放”。如果资源本身不该被自动释放（比如全局 OpenGL 上下文），强行套 RAII 反而引入错误语义。
