RAII模板类必须显式删除拷贝操作以防止资源重复释放，同时需正确实现移动语义、状态管理与自定义删除器，并确保构造失败时无泄漏。
RAII 模板类必须显式禁止拷贝，否则资源会重复释放
RAII 的核心是“资源生命周期绑定到对象生命周期”，一旦允许拷贝，两个对象可能持有同一份裸指针或句柄，析构时就会 double-free 或 close 无效句柄。C++ 默认生成的拷贝构造函数和拷贝赋值运算符不感知资源语义，直接禁用最安全。
- 在模板类中用
= delete明确删除：ResourceGuard(const ResourceGuard&) = delete;和ResourceGuard& operator=(const ResourceGuard&) = delete; - 若需转移所有权（如 std::unique_ptr），必须显式支持移动语义：
ResourceGuard(ResourceGuard&&)和operator=(ResourceGuard&&)，并在移动后将原对象的资源句柄置为无效值（如nullptr、-1） - 常见错误：只删拷贝但没实现移动——导致
return ResourceGuard{fd}编译失败；或移动后未清空源对象——后续析构仍尝试释放已转出的资源
释放逻辑必须区分“主动释放”和“异常路径下的析构释放”
RAII 类不是万能保险丝。如果用户在对象存活期间手动调用 release() 或 reset()，之后析构不能再释放同一资源；反之，若未手动释放，析构必须确保释放。两者不能共存于同一状态。
- 典型做法是维护一个标记字段（如
bool owned_）或检查资源句柄是否有效（如handle_ != -1） - 释放函数（如
reset()）应先执行释放动作，再将句柄置为无效值，并设置owned_ = false - 析构函数只需判断句柄是否有效，有效则调用释放逻辑——避免加锁、避免二次检查，否则可能掩盖资源泄漏或引发竞态
- 注意：系统调用如
close()或fclose()本身可安全重复调用（POSIX 规定 close 无效 fd 返回 -1），但不建议依赖该行为，因为 Windows HANDLE、OpenGL texture ID 等不保证幂等
模板参数要支持自定义删除器，且删除器类型必须参与模板推导
不同资源对应不同释放方式：文件描述符用 close()，FILE* 用 fclose()，malloc 内存用 free()，Windows HANDLE 用 CloseHandle()。硬编码释放逻辑会让模板失去通用性。
- 推荐签名：
template<typename t typename deleter="default_deleter<T">> class ResourceGuard</typename>，其中default_deleter是函数对象或函数指针类型 - 删除器实例应作为成员变量存储（而非仅类型参数），以便支持状态化删除器（如带日志的 deleter）
- 关键细节：若使用函数指针作默认模板参数（如
using Deleter = void(*)(T)），需确保它能被推导出来；更稳妥的是用std::function或仿函数，但要注意其大小开销 - 实操示例：
ResourceGuard<int decltype> fd_guard{open("x.txt", O_RDONLY), &close};</int>—— 这里&close的类型参与了Deleter推导，编译器才能实例化正确版本
构造失败时必须确保不泄漏资源，且不触发未定义行为
RAII 类的构造函数里申请资源（如 open、malloc、CreateFile），一旦失败（返回 -1、nullptr、INVALID_HANDLE_VALUE），必须立即处理，否则对象处于半构造状态，析构函数可能访问未初始化成员。
立即学习“C++免费学习笔记（深入）”；
- 构造函数体中资源申请失败 → 立即抛异常（如
throw std::system_error{errno, std::generic_category()}），此时对象未完成构造，析构函数不会调用，无泄漏风险 - 但注意：若资源申请前已有其他可能抛异常的操作（如分配内部管理结构），需用 try-catch 包裹并手动清理已申请资源，或改用两阶段初始化（不推荐）
- 更稳健的做法是：把资源申请逻辑放在初始化列表中，用委托构造函数封装；或使用
noexcept构造函数 + 返回错误码（适合嵌入式或禁用异常场景），此时必须把句柄初始化为无效值（如handle_(invalid_value)），并在构造体内检查失败后不修改句柄 - 常见坑：在构造函数体中申请资源后，忘记把失败句柄赋给成员变量，导致析构时读取未初始化内存（UB）
RAII 模板真正难的不是写个 ~ResourceGuard()，而是每个分支路径下资源状态是否明确、每个接口调用前后对象是否处于一致的有效/无效态——尤其在移动、异常、手动释放混用时，稍有疏忽就变成静默崩溃或资源泄露。
