RAII的核心是“对象存在即资源已就绪”，构造函数必须完成资源获取并失败即抛异常，析构函数禁止抛异常且须安全释放，拷贝禁用、移动置空、资源私有封装。
构造函数必须完成资源获取，失败就抛异常
RAII 的核心不是“有析构函数”，而是“对象存在即资源已就绪”。如果 open() 返回 -1、fopen() 返回 nullptr、new 抛 std::bad_alloc，构造函数就不能让对象“半成品”地活下来——否则析构时面对无效句柄，close() 或 delete 会触发未定义行为。
实操建议：
- 构造函数声明为
explicit，避免隐式转换导致意外申请 - 资源获取失败时直接
throw（如std::system_error(errno, std::generic_category())），不设is_valid_标志位去“容忍失败” - 若底层 API 返回错误码（如 POSIX
open()），必须显式判断并转为异常；不能靠返回值“带病运行” - 多步申请（比如先
mmap再mlock）要拆成多个 RAII 对象，或用私有 static 工厂函数封装，确保每一步失败都能回滚
析构函数禁止抛异常，释放失败只能忽略或记录
std::terminate() 是析构中抛异常的唯一归宿——尤其当它发生在栈展开期间（比如另一个异常正在传播）。所以 fclose()、close()、pthread_mutex_destroy() 这些可能失败的调用，绝不能在析构里 throw。
实操建议：
- 所有释放操作前加有效性检查：
if (fd_ != -1) ::close(fd_); - 忽略系统调用返回值是常规做法；若需感知失败，仅限调试期用
assert()或写日志，生产环境不阻塞、不重试 - 禁止在析构中调用
malloc、printf、std::cout、网络 I/O 等非异步信号安全函数 - 资源释放若有依赖顺序（如先
fflush()再fclose()），必须在析构函数内显式编码，不能依赖成员变量销毁顺序
拷贝必须 delete，移动必须置空原资源
文件描述符、堆内存指针、互斥锁这些资源不具备可复制性。允许拷贝等于给 double-free 或重复 close 埋雷；不置空移动源对象，则析构时仍会释放已被转移的资源。
实操建议：
- 显式禁用：
MyRAII(const MyRAII&) = delete;和MyRAII& operator=(const MyRAII&) = delete; - 移动构造/赋值中，必须将原对象句柄设为无效值：
other.fd_ = -1;或other.ptr_ = nullptr; - 移动后原对象需保持“有效但无资源”状态，析构时仍要检查句柄有效性，避免重复释放
- 别写
= default——编译器生成的是浅拷贝，等同于没禁用
资源句柄必须私有封装，不暴露裸指针
一旦用户能拿到 FILE* 或 int fd 并手动 fclose() 或 close()，RAII 就彻底失效。悬垂指针、资源泄漏、二次释放全由此而起。
实操建议：
- 资源成员声明为
private，不提供get()返回非 const 指针 - 只读访问用
const T* get() const noexcept；解引用用T* operator->()并附带断言 -
release()是危险接口，仅在与 C API 交互且明确移交所有权时才提供，并文档注明“调用后原对象不再管理该资源” - 避免用
static_cast绕过封装——这等于主动撕毁 RAII 协议
真正难的不是写一个能编译的 RAII 类，而是确保它在异常路径下不泄漏、在移动后不崩溃、在析构时不拖垮整个程序。很多 bug 都藏在“我以为它没问题”的边界场景里：比如信号中断时析构、线程被强制终止时清理、或者资源释放本身依赖尚未初始化的全局状态——这些地方，标准库的 std::unique_ptr 和 std::lock_guard 已经踩过足够多坑；手写 RAII，得比它们更谨慎才行。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
