raii是构造函数和析构函数的强制约定，需手动绑定资源获取与释放、确保生命周期可控、禁用拷贝、正确实现移动语义及异常安全。
RAII不是语法糖，是构造函数和析构函数的强制约定
RAII（Resource Acquisition Is Initialization）在c++里根本不是某种“开启自动管理”的开关，它靠的是你主动把资源获取写进构造函数、释放写进析构函数，并确保这个对象生命周期可控。编译器不帮你检查你有没有漏写析构逻辑，也不会替你判断该不该用std::unique_ptr还是裸指针。
- 资源必须绑定到栈对象或智能指针管理的对象上——堆上new出来的裸指针+手动delete不算RAII
- 析构函数必须是
noexcept（至少逻辑上不能抛异常），否则栈展开时可能调用std::terminate - 拷贝构造/赋值要显式禁止（
= delete）或深拷贝，否则两个对象析构时重复释放同一块内存
std::unique_ptr比手写RAII类更安全，但别乱用release()
多数场景下，直接用std::unique_ptr比自己写一个带FILE*或int fd的RAII包装类更快更稳。它的移动语义天然支持所有权转移，且默认析构行为可定制。
- 用
std::unique_ptr<file int></file>包装fopen/fclose时，删除器必须是函数指针或Lambda（捕获为空），不能是普通函数对象（会增大对象尺寸） -
release()会交出裸指针并置空内部指针——之后若忘记手动fclose，资源就泄露了；这是唯一需要你“手动干预”的破口 - 不要对
std::unique_ptr取地址传给C API：它不保证和裸指针二进制兼容（虽然通常兼容，但标准没保证）
std::lock_guard和std::shared_lock不是万能锁，嵌套加锁会死锁
RAII用于线程同步时，std::lock_guard和std::shared_lock确实能避免忘记unlock，但它们只管“当前作用域结束”，不管业务逻辑是否真的需要长期持锁。
- 同一个线程对同一
std::mutex重复加锁（比如递归调用中再次进入std::lock_guard）会导致未定义行为——std::recursive_mutex才支持 -
std::shared_lock配合std::shared_mutex时，写锁会被所有读锁阻塞，但多个读锁之间不互斥；误把读锁当写锁用，数据就脏了 - 跨函数传递锁对象没意义：
std::lock_guard不可复制、不可移动，传参只能靠引用，但生命周期一结束锁就释放
自定义RAII类最容易漏掉移动语义和异常安全
自己封装文件句柄、OpenGL纹理ID、windows HANDLE这类资源时，最常踩的坑不是构造/析构写错，而是移动操作没处理好，或者析构里调用了可能抛异常的函数。
立即学习“C++免费学习笔记（深入）”；
- 移动构造函数必须把源对象的资源句柄置为无效值（如
-1、nullptr），否则源对象析构时会二次释放 - 析构函数里调用
close()或glDeleteTextures()前，先检查句柄是否有效——系统调用对无效句柄的行为未必是静默忽略 - 如果构造函数里分配失败（比如
malloc返回nullptr），必须立刻抛异常；否则对象处于半构造状态，析构函数可能被调用，而成员变量未初始化
RAII真正的复杂点不在语法，而在你得对每个资源的生命周期边界有明确判断：它该活多久？谁负责释放？能否共享？这些一旦模糊，再规范的构造/析构也救不了。