RAII的本质是资源生命周期与对象生命周期的严格绑定：构造函数获取资源、析构函数无条件释放，且禁止裸资源逃逸。它不是语法糖，而是需主动设计的编译期契约，依赖构造即获取、析构即释放、不可复制三大原则。
RAII 不是语法糖，也不是库函数，而是一种必须靠你主动设计才能生效的资源管理契约。 它不自动发生，也不依赖编译器特殊支持——只要你没把资源塞进对象生命周期里，就等于没用 RAII。
RAII 的本质是“生命周期绑定”，不是“自动释放”
很多人误以为写了 ~Widget() 就算 RAII，其实关键不在有没有析构函数，而在：资源获取是否只发生在构造函数中、资源释放是否只发生在析构函数中、且二者之间没有裸指针/句柄逃逸到外部。
- 构造失败必须抛异常（不能返回错误码），否则对象未完全构造，析构不会调用 → 资源泄漏
- 析构函数必须
noexcept（C++11 起默认隐式添加），否则异常途中再抛异常会直接std::terminate - 资源不能被
get()、release()等接口暴露出去，否则用户可能手动 delete 或重复 close
为什么 std::unique_ptr 和 std::lock_guard 是典型 RAII 类型
它们不是“用了智能指针就叫 RAII”，而是因为每个都严格满足三要素：构造即获取、析构即释放、无裸资源暴露。
-
std::unique_ptr<int>(new int(42))</int>：构造时接管原始指针，析构时delete；中间无法拿到裸指针（除非显式调用.release()，但那是主动放弃 RAII） -
std::lock_guard<:mutex>(m)</:mutex>：构造时调用m.lock()，析构时调用m.unlock()；连try_lock都不提供，杜绝“锁了但忘了放”的路径 - 反例：
FILE* fp = fopen("a.txt", "r")+ 手动fclose(fp)：资源生命周期由程序员脑内维护，不是对象生命周期，不属于 RAII
自定义 RAII 类最容易漏掉的两件事
写一个封装文件句柄的类时，90% 的人会在初期忽略这两点，导致在异常或提前 return 时资源未释放。
- 构造函数中打开失败（如
open()返回 -1）必须throw std::system_error，不能静默返回或设fd = -1 - 析构函数里调用
close(fd)前，必须检查fd != -1，否则对无效 fd 调用close可能触发 errno 错误，且某些系统（如嵌入式）会崩溃 - 如果类支持移动（比如要放进
std::vector），必须显式删除拷贝构造/赋值，并实现移动构造/赋值，否则浅拷贝句柄会导致 double-close
真正难的从来不是“知道 RAII 是什么”，而是每次申请资源时，都下意识问自己一句：这个资源，我敢不敢把它交给一个栈对象的生命期来兜底？如果答案是否定的，那就要重新设计接口，而不是加个注释说“记得手动清理”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
