RAII是C++资源管理的唯一正解，要求资源生命周期严格绑定对象生命周期；裸指针或手动释放易致异常泄漏；所有需显式释放资源均应RAII封装。
RAII不是语法糖，是C++资源管理的唯一正解
RAII（Resource Acquisition Is Initialization）不是可选技巧，而是C++里绕不开的底层契约：资源生命周期必须绑定到对象生命周期。一旦你用裸指针、手动new/delete或fopen/fclose混搭，就等于主动放弃编译器帮你兜底的能力——异常一抛，资源就漏了。
关键判断：所有需要显式释放的资源（内存、文件句柄、互斥锁、socket、GPU buffer），都该用RAII封装。没封装？那不是“还没来得及”，是已经埋了bug。
std::unique_ptr和std::shared_ptr怎么选
选错智能指针类型，轻则性能浪费，重则循环引用或意外延长生命周期。
-
std::unique_ptr：资源只归一个所有者管，移动语义安全，零开销。适合绝大多数场景，比如函数内局部资源、容器里存对象所有权 -
std::shared_ptr：多个地方需要共享所有权时才用。但要注意：std::shared_ptr构造/拷贝/析构都有原子计数开销；std::weak_ptr必须配对用，否则容易std::shared_ptr循环引用导致内存泄漏 - 别用
std::auto_ptr（已弃用），也别自己写“智能指针”——标准库的实现经过严苛压测，自研大概率踩坑
示例：读配置文件后返回独占资源，用std::unique_ptr：
立即学习“C++免费学习笔记（深入）”；
std::unique_ptr<Config> load_config(const std::string& path) {
auto fp = std::fopen(path.c_str(), "r");
if (!fp) throw std::runtime_error("can't open config");
return std::unique_ptr<Config>(new Config(fp)); // 构造即接管
}
自定义RAII类最容易漏掉的三件事
手写RAII类（比如FileGuard、LockGuard）时，90%的问题出在特殊成员函数没写全。
- 必须显式删除拷贝构造和拷贝赋值：
FileGuard(const FileGuard&) = delete;、FileGuard& operator=(const FileGuard&) = delete;——否则复制对象会触发两次fclose - 移动构造和移动赋值要正确转移资源，并把原对象置为“空状态”（比如
fd = -1），否则析构时可能重复关闭 - 析构函数不能抛异常。如果
close()可能失败，就用[[maybe_unused]] int ret = close(fd);忽略，或记录日志但不throw——C++禁止析构中异常逃逸
错误现象：terminate called without an active exception，八成是析构里throw了。
RAII在异常路径下是否真可靠
可靠，但前提是：你没绕过它。
- 栈展开（stack unwinding）保证局部对象按构造逆序析构，所以
std::lock_guard在异常时照样释放锁，std::ofstream照样关闭文件 - 陷阱在于“半途而废”：比如在构造函数里分配了资源但中途throw，而析构函数没写成noexcept且没处理好清理逻辑，就会导致资源泄漏
- 更隐蔽的坑：lambda捕获了裸指针，然后在异步回调里用——RAII对象早已析构，指针悬空。这种不属于RAII失效，而是误用了RAII的边界
复杂点在于：RAII只管“自动存储期”对象。全局对象、static局部变量、堆上new出来的RAII对象，它们的析构时机受程序生命周期影响，不是异常能触发的。
