raii的本质是用构造函数获取、析构函数释放资源，确保资源生命周期与对象生命周期严格绑定。核心要求：资源必须在构造中获取并失败时异常/置无效，析构中无异常释放，禁用拷贝，移动需转移所有权并置空原对象。
RAII的本质不是“写个类”，而是构造函数获取、析构函数释放
RAII（Resource Acquisition Is Initialization）不是语法特性，是C++里用对象生命周期绑定资源生命周期的设计模式。核心就一条：std::unique_ptr 为什么安全？因为它在构造时接管裸指针，在析构时自动 delete——没手动调用，也没遗漏可能。
常见错误是把 RAII 当成“加个析构函数就行”：比如写了 ~FileHandler() 却没在构造函数里真正打开文件，或者忘了禁止拷贝导致双重关闭。
- 资源必须在构造函数中完成获取（
fopen、new、pthread_mutex_init等），失败则抛异常或置无效状态 - 析构函数必须无异常地释放（
fclose、delete、pthread_mutex_destroy），且不能依赖成员变量是否“已初始化” - 禁用拷贝（
FileHandler(const FileHandler&) = delete），移动语义按需实现（FileHandler(FileHandler&&)要转移资源所有权，原对象置空）
std::unique_ptr 和 std::shared_ptr 已覆盖绝大多数场景
手写 RAII 类只在极少数情况必要：封装系统级资源（如文件描述符、GPU句柄）、需要定制释放逻辑（如释放前先 flush）、或性能敏感到不能接受虚函数/引用计数开销。
std::unique_ptr 默认用 delete，但你可以传自定义删除器：
立即学习“C++免费学习笔记（深入）”；
auto close_file = [](FILE* f) { if (f) fclose(f); };
std::unique_ptr<FILE, decltype(close_file)> fp(fopen("log.txt", "w"), close_file);
注意：删除器类型是模板参数一部分，std::unique_ptr<file void></file> 和上面那个类型不兼容；用 decltype 最稳妥。
-
std::shared_ptr适合多所有者场景，但要注意循环引用——用std::weak_ptr打断 - 不要对栈对象或全局对象用
std::unique_ptr，它默认调用delete，会崩 - 用
std::make_unique替代new，避免异常安全问题（如构造参数里有 new，可能泄漏）
std::lock_guard 和 std::scoped_lock 是锁的 RAII 标准解法
手写一个“带锁的类”很容易出错：忘记 unlock、异常跳过 unlock、重复 unlock、或锁顺序不一致导致死锁。
std::lock_guard 在构造时加锁，析构时解锁，哪怕中间 throw 异常也保证释放；std::scoped_lock（C++17）还能同时锁多个互斥量并自动规避死锁顺序问题。
- 别在作用域外保留
std::lock_guard对象（比如存成员变量），它不是“锁的状态”，只是 RAII 代理 - 需要延迟加锁？用
std::defer_lock构造std::unique_lock，再显式调用lock()——但这时已脱离纯 RAII，得自己负责配对 -
std::mutex不可拷贝不可移动，所以所有 RAII 锁类都禁用拷贝，移动也仅限于std::unique_lock
自定义 RAII 类最容易漏掉的三件事
很多人写了构造/析构，跑起来似乎没问题，上线后 crash 或资源泄漏。往往栽在这三个地方：
- 没处理构造失败：比如
socket()返回 -1，但构造函数没 throw 也没标记对象为无效，后续析构仍尝试close(-1) - 析构函数里调用了可能抛异常的函数（如
std::cout ），而 C++ 要求析构函数默认 <code>noexcept；一旦抛出，程序直接 terminate - 成员中有原始指针或句柄，但没实现移动语义——当对象被 move 后，原对象析构时仍试图释放已被转移走的资源
最稳妥的做法：所有资源句柄用 int 或 void* 存储，初始化为 -1 或 nullptr；析构前先判空；移动构造/赋值后立即将源对象的句柄置为无效值。
