raii类应专用于标准组件不适用的场景，构造函数必须成功获取资源并失败即抛异常，析构函数须无异常释放资源，禁用拷贝、谨慎实现移动，且仅在封装非内存资源时才需手写。
直接说结论：自己写 RAII 类不是为了替代 std::unique_ptr 或 std::lock_guard，而是为了在标准组件不适用时（比如封装自定义资源、控制加锁时机、嵌入式环境无 STL）能快速构建安全、异常安全的资源守卫。
构造函数里必须完成资源获取，且失败就抛异常
RAII 的“初始化即获取”不是可选行为——如果构造函数没拿到资源，对象就不该存在。否则析构函数会面对一个无效状态，容易崩溃或静默失败。
- 构造函数中调用
fopen、pthread_mutex_init、new等，必须检查返回值；失败立即抛std::runtime_error，不能设默认空值后留到析构再判断 - 不要在构造函数里做“尽力而为”的事，比如尝试连接三次数据库；那是业务逻辑，不属于 RAII 职责
- 若资源获取本身可能阻塞（如网络连接），需明确文档说明，因为栈对象构造卡住会影响整个作用域进入
析构函数必须无异常地释放资源
析构函数是 RAII 的最终防线，但它不能抛异常——C++ 标准规定：若析构函数在栈展开期间（即处理另一个异常时）抛出异常，程序直接调用 std::terminate。所以释放逻辑必须 100% 安全。
- 对
FILE*，先判空再fclose；对int*，先判非空再delete - 避免在析构里调用可能抛异常的函数，比如
std::string构造、std::vector::push_back - 如果释放操作本身可能失败（如
close()返回 -1），记录日志或忽略，但绝不能 throw
拷贝必须禁用，移动需谨慎实现
资源所有权必须唯一，否则两个对象析构时都去 delete 同一块内存，就是未定义行为。
- 显式删除拷贝构造和拷贝赋值：
MyRAII(const MyRAII&) = delete;、MyRAII& operator=(const MyRAII&) = delete; - 移动语义不是必需的，但若需要转移所有权（比如从工厂函数返回），必须同步置空源对象的资源指针，并把
owns_标记设为false，否则移动后源对象析构仍会释放已转出的资源 - 移动构造中不要调用
delete或fclose，只做指针/句柄移交
std::unique_ptr 已覆盖绝大多数动态内存场景
除非你在写底层库、嵌入式驱动、或需要定制释放行为（比如用 VirtualFree 而非 delete），否则别手写内存 RAII 类。直接用 std::unique_ptr 更安全、更高效、还支持自定义 deleter。
- 管理数组：
std::unique_ptr<int> arr(new int[100]);</int> - 自定义释放：
std::unique_ptr<handle void> h(CreateEvent(...), [](HANDLE h) { CloseHandle(h); });</handle> - 手写类真正有价值的地方是：封装非内存资源（文件、锁、GPU buffer、硬件寄存器映射），这些标准库不内置，但 RAII 原则完全适用
最易被忽略的一点：RAII 类的成员变量本身也得是 RAII 友好的。比如你存了一个 std::string 成员，它内部有堆内存；若你的析构函数因异常提前退出，这个 std::string 仍会正常析构——这是 C++ 的保证。但如果你手动管理裸指针并忘了初始化为 nullptr，析构时判空就失效了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
