在C++编程实践中，RAII（资源获取即初始化）是确保资源安全管理的核心范式。其设计哲学在于将资源的生命周期与对象的生命周期紧密绑定：对象构造时获取资源，对象析构时自动释放资源。这种机制有效避免了资源泄漏，但要在实际项目中正确应用RAII，避免常见陷阱，需要深入理解并遵循一系列关键准则。

RAII类必须显式禁用拷贝，否则资源会重复释放

RAII的核心在于维护资源与对象之间“一对一”的独占关系。如果允许拷贝操作，多个对象可能共享同一份底层资源，导致在析构时发生重复释放（例如 double free 错误），引发程序崩溃。自C++11起，最清晰的做法是使用= delete明确禁止拷贝语义：

• MyResource(const MyResource&) = delete;
• MyResource& operator=(const MyResource&) = delete;

当需要转移资源所有权而非复制时，应实现移动语义（移动构造函数和移动赋值运算符）。关键在于，移动操作完成后，必须将源对象内部的资源句柄置为nullptr或其它无效状态。否则，源对象析构时仍会尝试释放已转移的资源，导致未定义行为。

析构函数里不能抛异常，否则可能终止程序

这是一条必须严格遵守的C++最佳实践。当程序因异常而进行栈展开（stack unwinding）时，会依次调用局部对象的析构函数。若某个析构函数在此期间再次抛出异常，C++运行时会直接调用std::terminate()终止程序。然而，RAII类的析构函数中常需调用如fclose()、munmap()等可能失败的系统API。

解决方案是：在析构函数中捕获并处理可能的错误，但绝不向外抛出异常。常见的做法是记录错误日志，或在调试版本中使用assert()进行提示。在生产环境中，对于释放操作失败的情况，通常选择静默忽略——因为此时资源已无法有效管理，确保程序继续运行往往比直接崩溃更为可控。

~FileGuard() {
    if (fp_ && std::fclose(fp_) != 0) {
        // 切勿在此处 throw；可记录一条警告日志
    }
}

原始指针裸露会破坏RAII契约，务必封装访问接口

若将内部资源句柄（如FILE*或int fd）以原始指针形式直接暴露，用户可能绕过RAII类直接进行释放操作（如调用fclose()），导致资源管理失效。因此，所有资源句柄都应声明为private，并通过安全的成员函数提供访问：

• 只读访问：const FILE* get() const { return fp_; }
• 带检查的解引用：FILE* operator->() { assert(fp_); return fp_; }
• 所有权移交：FILE* release() { FILE* tmp = fp_; fp_ = nullptr; return tmp; }（仅在需要明确转移控制权时使用）

特别注意：应避免提供返回非const裸指针的get()函数，并防止用户通过强制类型转换等手段破坏封装。这等同于主动放弃了RAII提供的安全保障。

优先使用 std::unique_ptr，手写 RAII 类需有充分理由

在动手实现自定义RAII类之前，应首先评估其必要性。对于绝大多数标准资源（如动态内存、文件句柄），使用std::unique_ptr配合自定义删除器（deleter）已是高效且安全的方案：

auto file = std::unique_ptr(
    std::fopen("log.txt", "w"), &std::fclose);

那么，何时才需要手动编写RAII类呢？典型场景包括：管理特殊系统资源（如pthread_mutex_t、sem_t、mmap内存区域、CUDA上下文等），这些资源通常没有标准的删除器；或者资源的获取与释放逻辑异常复杂，需要在构造时进行多重状态校验，或协调多种关联资源（如同时处理文件打开、锁获取与日志记录）；亦或是需要与特定C语言API深度集成，遵循其严格的初始化和销毁序列。将这些复杂逻辑封装在单一类中，远比分散管理更为清晰和健壮。

最后，一个极易被忽视的实践是：实际验证你的析构函数是否被正确调用。不要仅依赖逻辑推断，尤其是在涉及异常、提前return或longjmp的复杂控制流中。C++仅保证对象在其生命周期正常结束时调用析构函数。在关键RAII类的析构函数中添加简单的日志输出（如std::cerr << "dtor called\n";）进行验证，这个习惯能帮助你发现许多潜在的逻辑漏洞。