RAII核心是资源与对象生命周期严格绑定：构造时获取资源并异常安全失败即终止，析构时无异常释放，禁用拷贝、显式移动，支持自定义删除器管理任意资源。
自己写 RAII 模板类不是为了替代 std::unique_ptr 或 std::lock_guard，而是当标准组件不适用时（比如封装 POSIX 文件描述符、Windows HANDLE、自定义内存池句柄、或需要精确控制释放时机的硬件资源），必须确保构造即获取、析构即释放、失败即终止——否则对象半初始化或析构时访问无效资源，就是未定义行为。
构造函数里资源申请失败必须抛异常，不能设空状态
RAII 的核心是“对象存在 ⇔ 资源已成功获取”。如果 fopen() 返回 nullptr、open() 返回 -1、new 抛 std::bad_alloc，构造函数就该让对象根本建不起来。
- 禁止在构造函数里给句柄字段赋默认值（如
fd_ = -1）再“带病运行”，这会让析构函数面对无效状态，容易触发close(-1)或空指针解引用 - POSIX 系统调用需显式检查返回值并转为异常：
if (fd == -1) throw std::system_error(errno, std::generic_category()); - 不要在构造中做多步申请（比如先
malloc再setsockopt），除非每一步都立刻包装进已有 RAII 对象；否则中间失败会导致前序资源泄漏 - 构造函数声明为
explicit，避免隐式转换引发意外资源申请
析构函数必须 noexcept 且只做安全释放
析构函数里调用 fclose()、close()、delete 等操作，即使失败也绝不能抛异常——否则栈展开期间二次抛异常会直接触发 std::terminate()。
- 所有释放逻辑必须包裹在
noexcept析构函数中：~MyResource() noexcept -
close()或fclose()失败时忽略返回值，或记录errno到日志，但绝不throw - 禁止在析构中调用可能抛异常的函数：比如
std::string构造、std::vector::push_back、网络 I/O - 若有释放依赖顺序（如先
fflush()再fclose()），必须在析构体内显式编码，不能依赖成员变量销毁顺序
拷贝必须 delete，移动必须置空原资源句柄
资源具有独占性。允许拷贝等于默许 double-free 或 double-close；不实现移动则无法与 std::vector、工厂函数等现代 C++ 模式协作。
立即学习“C++免费学习笔记（深入）”；
- 显式禁用拷贝：
MyRAII(const MyRAII&) = delete;和MyRAII& operator=(const MyRAII&) = delete; - 移动构造中只移交句柄，不调用释放函数：
fd_(other.fd_) { other.fd_ = -1; } - 移动赋值前必须先释放当前资源（如有），再移交新句柄，并将源置空
- 移动后原对象处于 “valid but empty” 状态：析构时仍会检查
fd_ != -1才调用close()，避免重复释放
支持自定义删除器才能管住非堆资源
硬编码 delete ptr_ 只能管 new 出来的内存，而 RAII 的真正价值在于统一管理文件、锁、GPU buffer、注册表句柄等——这些释放方式各不相同。
- 模板参数应支持仿函数或函数指针作为
Deleter，例如：template<typename t typename deleter="std::default_delete<T">></typename> - 构造时传入释放逻辑：
UniqueResource<int void>(ptr, [](int* p) { my_free_pool(p); })</int> - 避免把删除器存为
std::function（有虚调用开销和堆分配），优先用模板参数或函数指针 - 若底层 API 释放失败会设置全局
errno，删除器内可读取但不应抛异常
最易被忽略的一点：RAII 类不是万能胶。它不解决资源申请本身是否阻塞（比如 connect()）、不处理跨线程共享（那得用 std::shared_ptr + 引用计数）、也不代替业务层重试逻辑。它的职责非常窄——仅保证“一旦构造成功，就一定有且仅有一次安全释放”。越想包揽更多，越容易在异常路径或移动边界上翻车。
