17370845950

RAII的本质是“作用域绑定生命周期”，即资源生命周期严格绑定到栈对象生存期；构造函数不应抛异常，析构函数必须noexcept，且应避免手动管理资源而优先使用标准RAII工具。

RAII 的本质不是“构造获取 + 析构释放”，而是“作用域绑定生命周期”

RAII（Resource Acquisition Is Initialization）常被误解为“在构造函数里 new，在析构函数里 delete”。这不对——真正关键的是：**资源的生命周期必须严格绑定到某个栈对象的生存期上**。构造函数是否真的“获取”资源、析构函数是否真的“释放”，取决于资源类型和使用意图。比如 std::lock_guard 构造时加锁、析构时解锁；std::unique_ptr 构造时接管裸指针、析构时调用 delete；但 std::string 构造时分配内存，析构时释放，你甚至不感知它用了堆——它仍是 RAII。

构造函数里不能抛异常，否则析构函数不会被调用

这是 RAII 最容易翻车的地方。如果构造函数中途抛出异常，对象未完全构造成功，C++ 标准规定：**该对象的析构函数绝不会执行**。此时若你在构造中已手动 new 了资源（比如文件句柄、内存、socket），就彻底泄漏了。

• 永远不要在构造函数里做可能失败的资源获取操作（如打开文件、连接网络、malloc 失败）
• 若必须处理可能失败的初始化，改用工厂函数 + std::optional 或返回 std::expected（C++23）
• 更稳妥的做法是把资源获取延迟到一个独立的 init() 成员函数，并由用户显式调用（但这就脱离 RAII 了）

class BadRAII {
    FILE* fp;
public:
    BadRAII(const char* name) {
        fp = std::fopen(name, "r");
        if (!fp) throw std::runtime_error("open failed"); // ❌ 析构不执行，fp 泄漏
    }
    ~BadRAII() { if (fp) std::fclose(fp); } // 永远不会被调用
};

析构函数必须是 noexcept，否则栈展开会直接终止程序

C++ 要求析构函数默认为 noexcept（除非显式声明 noexcept(false)）。如果析构函数意外抛出异常（比如 fclose() 失败且你写了 throw），而此时程序已在栈展开过程中（例如另一个异常正在传播），std::terminate() 会被立即调用——进程静默退出，无日志、无调试线索。

• 所有 RAII 类的析构函数应避免任何可能抛异常的操作
• 系统调用如 close()、fclose()、pthread_mutex_destroy() 等失败时只设 errno，不应转为异常
• 若需报告析构期错误（极少见），应记录日志或写入全局状态，而非抛出

class SafeFile {
    FILE* fp;
public:
    SafeFile(const char* name) : fp(std::fopen(name, "w")) {}
    ~SafeFile() noexcept { // ✅ 显式标记
        if (fp) std::fclose(fp);
    }
};

别用裸指针 + 手动 new/delete 模拟 RAII

有人写这样的“伪 RAII”：

class ManualPtr {
    int* p;
public:
    ManualPtr() : p(new int(42)) {}
    ~ManualPtr() { delete p; }
    int* get() { return p; }
};

问题在于：它不满足 RAII 的三大支柱——没有移动语义（C++11 后必须支持）、没有禁止拷贝（导致双重释放）、无法组合（比如放进 std::vector 就崩）。正确做法是直接用标准工具：

• 动态内存 → std::unique_ptr 或 std::shared_ptr
• 文件描述符 → std::filesystem::path 配合 RAII 封装类，或 folly::File 等第三方
• 互斥锁 → std::lock_guard / std::unique_lock
• 自定义资源 → 继承 std::unique_ptr 的删除器，或写最小化封装类（含移动构造/赋值，禁拷贝）

自己手写 RAII 类不是不行，但得完整实现移动语义、noexcept 析构、异常安全构造——多数时候，复用标准库更可靠。