RAII模板类必须显式删除拷贝构造和赋值以避免双重释放；析构函数不得抛异常；应使用双模板参数支持任意资源类型和释放逻辑；优先使用std::unique_ptr，仅特殊需求才手写。
RAII 模板类必须显式禁止拷贝，否则资源会双重释放
RAII 的核心是“资源生命周期绑定到对象生命周期”，一旦允许拷贝，两个对象可能持有同一份裸指针或句柄，析构时重复释放导致 double free 或 close on invalid fd。C++11 起应直接删除拷贝构造和拷贝赋值：
MyResource(const MyResource&) = delete;MyResource& operator=(const MyResource&) = delete;
移动语义可选但推荐支持——否则无法用于容器或返回局部对象。若支持移动，需确保原对象资源置为无效状态（如指针设为 nullptr，fd 设为 -1），否则移动后析构仍会误操作。
析构函数里不能抛异常，否则可能引发 std::terminate
C++ 标准规定：若析构函数在栈展开过程中（即另一个异常尚未处理完时）又抛出异常，程序直接调用 std::terminate。而 RAII 类的析构常涉及系统调用（如 fclose、munmap、pthread_mutex_destroy），这些调用可能失败并需要错误反馈——但绝不能用异常。
- 改用返回码或日志记录错误（如
if (fclose(fp) != 0) log_error("fclose failed");） - 避免在析构中做任何可能抛异常的操作（比如调用
std::string构造、new、或任何未标注noexcept的函数） - 若必须检查关键释放结果（如数据库连接关闭是否成功），应在业务逻辑中提前显式调用
close()并处理异常，而非依赖析构
模板参数需区分“获取”与“释放”行为，不能硬编码为指针
RAII 模板类常被误写成只适配 T*，但实际资源类型五花八门：文件描述符（int）、Windows HANDLE（void*）、POSIX mutex（pthread_mutex_t*）、甚至自定义句柄结构体。正确做法是把资源类型 ResourceT 和释放函数 DeleterT 都作为模板参数：
立即学习“C++免费学习笔记（深入）”；
template<typename ResourceT, typename DeleterT = std::default_delete<ResourceT>>
class ScopedResource {
ResourceT res_;
DeleterT deleter_;
public:
explicit ScopedResource(ResourceT r, DeleterT d = {}) : res_(r), deleter_(d) {}
~ScopedResource() { if (res_) deleter_(res_); }
// ... 移动、get()、release() 等
};
这样既能传 FILE* + [](FILE* f) { fclose(f); }，也能传 int + [](int fd) { close(fd); }，还能传 sqlite3* + 自定义清理逻辑。
std::unique_ptr 已覆盖绝大多数场景，手写 RAII 类仅在特殊需求时必要
除非遇到以下情况，否则优先用 std::unique_ptr 或 std::shared_ptr（配合自定义 deleter）：
- 资源类型不是指针（如
int fd、pthread_t tid），且不想包一层结构体 - 需要在构造时做复杂初始化（如 open 失败就 throw，且需原子性保证），而
std::unique_ptr的构造不支持带异常的工厂函数 - 性能敏感路径，需避免虚函数调用（自定义 deleter 若用函数对象而非函数指针，
std::unique_ptr可零开销，但手写类更可控）
手写 RAII 类真正难的不是语法，而是厘清资源语义：它是否可共享？是否可重入释放？失败是否可忽略？这些决定了模板接口的设计粒度——一个没想清楚的 DeleterT 参数，比多写十行代码更容易埋雷。
