RAII是C++中通过对象生命周期自动管理资源的唯一可靠方式，构造获取资源、析构释放资源，确保异常安全；需禁用拷贝、实现移动语义、析构函数noexcept。
RAII 是什么，为什么不能靠 try-catch 或手动 free
RAII 不是语法糖，也不是可选技巧——它是 C++ 管理资源的**唯一可靠方式**。你写 new 之后手动 delete，或在 try 块末尾调用 close()，本质上都在赌：程序不会提前 return、不会抛异常、不会被 longjmp 跳过。而现实里，一次未捕获的异常、一个提前 return、甚至一个 goto，就能让资源泄漏变成常态。
RAII 把资源生命周期绑定到对象生命周期上：构造函数获取资源，析构函数释放资源。只要对象离开作用域（无论是否异常），~T() 必然执行。这才是确定性资源管理的根基。
怎么写一个 RAII 封装类（以文件句柄为例）
别直接封装裸指针；优先用标准库已有类型（如 std::unique_ptr、std::fstream）。但理解底层封装逻辑，才能避开自定义时的坑：
- 构造函数必须完成资源获取，失败则抛异常（不能留“半初始化”对象）
- 析构函数必须无异常（
noexcept），否则栈展开时二次崩溃 - 禁用拷贝（防止两个对象管同一份资源），移动语义要明确转移所有权
- 不要在析构里做复杂逻辑（比如重试 close、日志打印），它可能在信号处理上下文中被调用
示例（简化版）：
立即学习“C++免费学习笔记（深入）”；
class FileHandle {
int fd_ = -1;
public:
explicit FileHandle(const char* path) {
fd_ = open(path, O_RDONLY);
if (fd_ == -1) throw std::system_error{errno, std::generic_category()};
}
~FileHandle() noexcept { if (fd_ != -1) close(fd_); }
FileHandle(const FileHandle&) = delete;
FileHandle& operator=(const FileHandle&) = delete;
FileHandle(FileHandle&& other) noexcept : fd_(other.fd_) { other.fd_ = -1; }
FileHandle& operator=(FileHandle&& other) noexcept {
if (this != &other) {
if (fd_ != -1) close(fd_);
fd_ = other.fd_;
other.fd_ = -1;
}
return *this;
}
};std::unique_ptr 和 std::shared_ptr 怎么用才算 RAII 合规
它们本身是 RAII 容器，但用法错一步，就等于放弃 RAII 保障：
-
std::unique_ptr的自定义删除器必须是无状态的（或可默认构造），否则无法隐式转换；常用写法：std::unique_ptr<file decltype> fp{fopen("x", "r"), &fclose}</file> -
std::shared_ptr的控制块会延长资源生命周期——如果把shared_ptr存进全局容器或循环引用，资源可能永远不释放 - 绝不要用
get()拿裸指针去传给 C API 并期望自己 laterdelete；那等于绕开 RAII - 对 C 风格资源（如
pthread_mutex_t*），删除器里必须先pthread_mutex_destroy再free，顺序反了会 UB
哪些资源不能靠 RAII 自动管理
RAII 管不了所有事。以下情况需额外设计或接受限制：
- 跨线程共享的资源（如全局锁），RAII 对象只管本线程的持有状态，不解决竞态
- 需要显式“提前释放”的场景（如缓存淘汰），RAII 的“离开作用域才释放”太被动；这时得配合
reset()或显式release() - 操作系统级资源配额（如进程打开文件数上限），RAII 能防泄漏，但不能防滥用；得结合池化或限流
- 某些硬件资源（如 GPU 显存）的释放可能异步，析构函数里只能发回收请求，不能等完成
真正难的不是写个 ~MyGuard()，而是想清楚：这个资源的“生命周期边界”到底由谁定义？作用域？引用计数？业务状态机？一旦边界模糊，RAII 就会失效。
