手写RAII模板类必须确保资源生命周期与对象生命周期严格一致：构造失败即抛异常、析构函数noexcept且安全释放、禁止拷贝、移动后置空、资源私有化。
手写 RAII 模板类不是“加个析构函数就行”，而是必须让对象存在即资源就绪、销毁即资源释放——构造失败时对象根本不能存在，析构中任何异常都会直接终止程序。
构造函数里必须完成资源申请，失败就 throw
RAII 的核心是“对象生命周期 = 资源生命周期”。如果 fopen 返回 nullptr、open 返回 -1、new 抛 std::bad_alloc，构造函数就不能让对象“半成品”地活下来。否则析构时面对无效句柄，fclose 或 close 会触发未定义行为。
- 资源申请必须放在成员初始化列表中（如
: fd_(open(path, flags))），而非构造函数体内；否则异常抛出时，对象未完全构造，析构函数不会调用，已分配的其他资源（如前面的malloc）就泄漏了 - 失败判断必须紧随申请之后：对
FILE*判== nullptr，对int fd判== -1，对 WindowsHANDLE判== INVALID_HANDLE_VALUE - 必须用
throw终止构造，不能设is_valid_标志位或返回错误码——用户大概率忽略检查，RAII 契约即失效 - 多步申请（如先
mmap再mlock）应拆成多个 RAII 对象，或用私有static工厂函数封装并确保可回滚
析构函数必须 noexcept 且只做安全释放
~MyRAII() 里调用 fclose、close、pthread_mutex_destroy 等，哪怕失败也不能 throw。C++ 标准规定：析构函数默认 noexcept，若此时抛出未捕获异常（尤其在栈展开期间），程序立即调用 std::terminate。
- 所有释放操作前必须判空：
if (fd_ != -1) close(fd_);，释放后立即将句柄置为无效值（fd_ = -1;） - 禁止在析构中调用可能抛异常的函数：
std::cout、std::string::c_str()、malloc、网络 I/O 等都不行 - 释放失败通常静默处理；调试期可用
assert或写日志，但绝不能阻塞或重试 - 若有依赖顺序（如先
fflush再fclose），必须显式编码在析构函数内，不能依赖成员变量销毁顺序
拷贝必须 delete，移动必须置空原对象
资源不具备可复制性。允许拷贝等于给 double-free 或重复 close 埋雷；不置空移动源对象，析构时仍会释放已被转移的资源。
立即学习“C++免费学习笔记（深入）”；
- 显式删除：
MyRAII(const MyRAII&) = delete;和MyRAII& operator=(const MyRAII&) = delete; - 移动构造/赋值中，必须将原对象句柄设为无效值：
other.ptr_ = nullptr;或other.fd_ = -1; - 移动后原对象进入“有效但无资源”状态，其析构函数仍需检查句柄有效性再决定是否释放
- 切勿写
= default——编译器生成的是浅拷贝，等同于没禁用
什么时候真该自己写，而不是用 std::unique_ptr
std::unique_ptr 只覆盖堆内存管理场景。它无法适配文件描述符、互斥锁、OpenGL texture ID、Windows HANDLE 等非 new 出来的资源，也不支持带上下文的释放逻辑（如 curl_easy_cleanup）或不可移动资源（如 pthread_mutex_t）。
- 优先用
std::unique_ptr+ 自定义删除器：如std::unique_ptr<FILE, int(*)(FILE*)>(fopen(...), &fclose) - 仅当以下情况存在时才手写模板：
std::unique_ptr的删除器类型不匹配（如close(int)vsvoid(*)(int*)）、资源不可移动、需要release()移交控制权、或释放前必须执行额外校验/日志/广播 - 自定义删除器必须是无状态的（如无捕获 lambda 或函数指针），不能抛异常，且满足可复制/移动要求；避免用
std::function——它引入堆分配和虚调用开销 - 手写模板必须把资源句柄完全私有化，不暴露裸指针；提供
get()仅作只读访问，并文档注明“不转移所有权”
最易被忽略的点是：构造函数里多步初始化的中间状态污染、析构中误调可能抛异常的辅助函数、以及移动后忘记置空导致二次释放——这些都不是“小问题”，而是未定义行为的确定入口。
