RAII的本质是“生命周期绑定”，即资源获取与栈对象构造绑定、释放与析构绑定，确保异常安全下的必然释放。
RAII 的本质不是“自动释放”，而是“生命周期绑定”
RAII（Resource Acquisition Is Initialization）不靠垃圾回收，也不靠手动 delete 或 close() 调用；它把资源的生命周期强行和栈上对象的构造/析构绑定。只要对象进入作用域就获取资源，离开作用域就必然释放——这个“必然”来自 C++ 标准对栈对象析构的强制保证，哪怕发生异常、提前 return、或 throw，析构函数都一定会被调用。
常见错误是以为 RAII = 智能指针。其实 std::unique_ptr 和 std::shared_ptr 是 RAII 的*应用*，但 RAII 本身更底层：一个自定义类只要在构造函数里申请资源（如 fopen()、new、pthread_mutex_init()），在析构函数里释放（fclose()、delete、pthread_mutex_destroy()），它就是 RAII 类。
- 资源必须在构造函数中完成获取，且失败时抛异常（不能静默失败）；否则对象处于“半构造”状态，析构不会执行
- 析构函数必须
noexcept（C++11 起默认隐式为noexcept），否则异常途中又抛异常会直接std::terminate - 禁止在 RAII 对象内部裸存指针并交由外部管理——那等于把责任又推回去了
为什么 std::fstream 不关文件就退出也不会泄漏？
因为 std::fstream 是标准库实现的 RAII 类：构造时调用 open()（或通过参数隐式打开），析构时自动 close()。你甚至不用显式调用 close()，哪怕忘记写、或中间 throw 了，文件描述符照样归还给系统。
对比裸用 fopen()/fclose()：一旦某条路径漏掉 fclose()（比如 if 分支没覆盖、异常跳过），文件描述符就卡住。而 RAII 把这个检查从“人脑逻辑”转成“编译器和运行时规则”。
立即学习“C++免费学习笔记（深入）”；
-
std::fstream析构前若文件仍打开，会隐式调用close()；如果close()失败（如磁盘满），错误被吞掉（不抛异常），但资源本身已释放 - 不要在 RAII 对象析构期间做重试或日志——它可能发生在栈展开中，此时异常安全难以保障
- 自定义 RAII 类若需报告关闭失败，应提供
close()方法供显式调用，并让析构只做“尽力释放”
move 语义下 RAII 还安全吗？
安全，但前提是正确实现移动构造/赋值。默认生成的移动操作只是位拷贝，对含裸指针或文件描述符的 RAII 类是灾难性的——两个对象指向同一资源，析构时重复释放。
典型修复方式：移动后将源对象的资源句柄置为无效态（如指针设 nullptr，fd 设 -1），确保只有新对象负责释放。
- 移动构造函数中，原对象资源所有权转移，原对象析构时检查句柄是否有效，无效则跳过释放
- 若类含
std::mutex或std::thread，它们不可复制也不可移动，必须显式禁用移动（= delete）或改用std::shared_ptr包装 - 用
std::move()转移 RAII 对象时，原变量变成“有效但未指定状态”，不能再访问其资源，也不能再次移动
RAII 在多线程里容易被忽略的坑
RAII 本身线程安全，但资源本身的使用未必。比如一个 RAII 封装的 std::mutex，它的构造/析构是线程安全的，但锁的加/解锁操作仍需程序员控制临界区。
更隐蔽的问题是：多个 RAII 对象嵌套持有同一资源（比如两个 std::lock_guard 锁同一个 std::mutex），会导致死锁或未定义行为——RAII 不解决逻辑错误，只解决“忘了释放”。
- 避免在析构函数里调用虚函数或依赖其他全局对象，因为析构顺序不确定，可能已被销毁
- 全局或静态 RAII 对象的构造/析构顺序跨编译单元未定义，若相互依赖，可能 crash
- 信号处理函数中不应触发 RAII 析构（如 longjmp、siglongjmp），因栈展开被绕过，资源不释放
