RAII是C++异常安全的唯一可靠基础，核心是将资源绑定到栈对象生命周期，靠noexcept析构函数自动释放；需用智能指针、标准容器和RAII封装类型替代裸资源操作，避免析构中抛异常。
异常发生时资源没释放，C++里怎么保证不泄露
RAII（Resource Acquisition Is Initialization）不是语法糖，是C++里唯一靠谱的异常安全基础。核心就一条：把资源绑定到栈对象生命周期上，靠析构函数兜底释放。别指望 try/catch 去手动清理——一旦中间抛异常，catch 之前那段代码就断了，资源早悬空了。
常见错误现象：new 出来指针存在局部变量里，没配 std::unique_ptr；文件句柄用 fopen 打开后，中间计算出错直接 return，忘了 fclose；锁用了 pthread_mutex_lock 却没配 pthread_mutex_unlock 在所有出口写一遍。
- 用
std::unique_ptr替代裸new/delete，构造即接管，析构即释放 - 标准库容器（
std::vector、std::string）和智能指针本身都是异常安全的，它们的移动/拷贝若失败会抛异常，但不会导致已有资源泄漏 - 自定义 RAII 类必须确保析构函数
noexcept（默认就是），否则在栈展开过程中析构抛异常，程序直接调用std::terminate
std::vector::push_back 抛异常，前面元素还安全吗
安全。只要 std::vector 的元素类型满足“异常安全强保证”（比如内置类型、std::string、std::unique_ptr），push_back 在扩容失败或元素构造失败时，会回滚到调用前状态——已有的元素不变，size() 不变，内存也不乱。
但前提是：你没自己写过带异常的移动构造函数，也没在元素类型里搞非 noexcept 的资源操作。例如，如果自定义类的移动构造函数里偷偷 new 了一块内存又没处理好异常，那整个 vector 的强异常安全就破了。
立即学习“C++免费学习笔记（深入）”；
- 检查元素类型的移动构造/赋值是否标记为
noexcept，可用std::is_nothrow_move_constructible_v<t></t>静态断言 - 避免在容器元素内部管理裸资源（如 FILE*、int fd），改用封装好的 RAII 类型（
std::fstream、std::shared_ptr<file decltype></file>） - 不要依赖
reserve()来“预防”异常——它只预分配内存，不改变逻辑正确性，且预分配失败也会抛std::bad_alloc
函数返回前抛异常，局部 std::lock_guard 还能解锁吗
能。这是 RAII 最典型的用例。std::lock_guard 构造时加锁，析构时自动解锁，而析构发生在作用域结束时——不管是自然退出、return，还是中途抛异常，都逃不过栈展开（stack unwinding）触发的析构。
容易踩的坑是误用 std::mutex::lock() + unlock() 手动配对。一旦中间有分支、提前 return 或异常，unlock() 就可能被跳过，导致死锁。
-
std::lock_guard和std::unique_lock都是noexcept析构，可放心用于异常路径 - 别在
lock_guard作用域内调用可能抛异常的用户函数，除非你确认这些函数不会破坏锁的状态（比如不递归锁同一把 mutex） - 多个锁要按固定顺序获取，否则即使用了
lock_guard，仍可能因竞争顺序不同引发死锁——RAII 管不了逻辑顺序
自定义类怎么写才算异常安全的析构函数
析构函数必须不抛异常，这是铁律。C++ 标准规定：如果析构函数抛异常且未被捕获，会立即调用 std::terminate。所以哪怕你内部调用的 API 可能抛异常（比如 close() 返回 -1 且你想 throw），也得吞掉或转成日志。
典型错误是写这样的析构函数：~MyFile() { if (fd != -1) ::close(fd); } ——看起来没问题，但 ::close() 在某些情况下（如 NFS 挂载点失效）可能阻塞或失败，而你无法在这里 throw，也不能让程序崩。
- 所有系统调用（
close、munmap、pthread_mutex_destroy）在析构中必须检查返回值，失败时记录日志或忽略，绝不 throw - 如果资源释放逻辑复杂、可能失败且你真需要反馈，把它拆成一个显式的
close()成员函数，让用户主动调用并处理异常，析构函数只做最简兜底 - 用
static_assert(noexcept(std::declval<myclass>().~MyClass()))</myclass>在编译期确认析构函数不抛异常
异常安全不是靠 try/catch 补漏，而是靠资源绑定到对象生命周期。最常被忽略的是：析构函数里调用的任何函数，都必须是 noexcept 友好的——哪怕它文档没写，你也得实测或查实现。否则看似稳的 RAII，会在某次系统调用失败时突然崩掉。
