RAII是C++资源管理的唯一确定性手段：对象构造成功则资源归属确定，析构执行则资源必然释放；析构函数必须声明为noexcept，否则栈展开中抛异常将导致程序终止；构造失败必须抛异常，禁止半初始化状态；优先复用std::unique_ptr等标准RAII类型。
RAII 不是“可选技巧”，而是 C++ 中资源管理的唯一确定性手段——只要对象构造成功，资源就已归属；只要对象析构执行，资源就必然释放。异常、提前 return、goto、甚至栈展开过程，都不影响这一保证。
为什么析构函数必须声明为 noexcept
当异常正在传播（即栈正在展开）时，若某个析构函数又抛出新异常，C++ 会直接调用 std::terminate() 终止程序。这是不可恢复的崩溃，且无法捕获。
常见错误现象：
- 在
~FileHandle()里调用close()后检查返回值并 throw，导致二次异常 - 析构中做日志打印（依赖未初始化的全局 logger）、网络请求或磁盘 I/O
正确做法：
- 所有 RAII 类的析构函数显式加
noexcept（C++11 起默认不隐式添加） -
close()、fclose()、pthread_mutex_destroy()等失败仅记录 errno，不 throw - 避免在析构中触发任何可能抛异常的操作
拷贝与移动语义必须明确区分所有权
两个对象指向同一份资源（如裸指针、文件描述符），析构时重复释放，轻则 double free，重则段错误或静默损坏。
使用场景：
- 你封装了一个
int*或FILE*，但没禁用拷贝 → 多个对象析构时都调delete或fclose - 移动后原对象仍持有有效句柄，未置为无效状态（如
-1或nullptr）
实操建议：
- 显式删除拷贝构造和拷贝赋值：
FileHandle(const FileHandle&) = delete; - 移动构造/赋值中，把源对象的资源句柄转移走，并立即置为无效值（如
fd_ = -1） - 析构前检查句柄有效性（
if (fd_ != -1) close(fd_);），避免对无效句柄操作
构造函数失败必须抛异常，不能留“半初始化”对象
如果构造函数中资源获取失败（如 open() 返回 -1、fopen() 返回 nullptr），而你选择默默设为无效状态（如 fd_ = -1），后续用户调用 *this 的任何方法都可能崩溃或行为未定义。
典型错误：
- 构造函数里
new失败却返回nullptr而不 throw → 用户拿到一个“看似正常”的对象，但内部为空 - 打开文件失败，不 throw，只打印 warning → 调用方无法感知失败，继续读取，触发未定义行为
正确做法：
- 资源获取失败时，立刻 throw 异常（推荐
std::system_error封装errno） - 确保构造函数要么完全成功，要么彻底失败（无中间态）
- 不要在构造函数里做非资源相关的复杂逻辑（比如解析配置、启动线程）
优先复用标准库 RAII 类型，而非手写
手写 RAII 容易踩坑，而 std::unique_ptr、std::fstream、std::lock_guard 等已通过多年工程验证，接口清晰、行为确定。
性能与兼容性影响：
-
std::unique_ptr支持自定义删除器，但Deleter必须是无状态的（否则无法满足unique_ptr的大小和移动要求） - 用
std::fstream管理文件比手写FileHandle更安全：它内部已处理close()失败、noexcept、移动语义等细节 - 自定义 RAII 类若需跨 DLL 边界传递，注意 ABI 兼容性（虚函数、异常规范、模板实例化）
示例（安全的自定义删除器用法）：
std::unique_ptr<file decltype> fp{fopen("data.txt", "r"), &fclose};
if (!fp) throw std::runtime_error("cannot open file");</file>
这行代码已涵盖资源获取、异常安全、自动释放三重保障 —— 手写类除非有特殊需求（如需要额外状态、调试钩子、资源池集成），否则没必要重复造轮子。
最易被忽略的一点：RAII 的可靠性完全依赖于对象生命周期的“确定性”。这意味着你不能把 RAII 对象放在 malloc 分配的内存上、不能用 placement new 构造却不显式调用析构、也不能把它作为 union 成员——这些都会破坏析构时机的可预测性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
