RAII类必须显式禁用拷贝以避免双重释放，应使用=delete；需实现移动语义并置空原资源；析构函数不可抛异常；资源句柄须私有封装；优先使用std::unique_ptr，仅在管理特殊资源或需复杂逻辑时手写RAII类；务必验证析构是否实际执行。
RAII类必须显式禁用拷贝，否则资源会重复释放
RAII的核心是“资源生命周期绑定对象生命周期”，一旦允许拷贝，两个对象就可能指向同一块资源，析构时触发两次delete或close()，直接导致未定义行为（如 double free 错误）。C++11 起应使用= delete明确禁用：
MyResource(const MyResource&) = delete;MyResource& operator=(const MyResource&) = delete;
如果需要转移语义（比如把文件句柄从一个对象移到另一个），必须实现移动构造和移动赋值，并将原对象的资源指针置为nullptr或无效值——否则移动后原对象析构仍会释放已转出的资源。
析构函数里不能抛异常，否则可能终止程序
当栈展开（stack unwinding）过程中有另一个异常正在传播时，若析构函数再抛异常，std::terminate()会被立即调用。而 RAII 类的析构函数常要调用fclose()、munmap()、pthread_mutex_destroy()等可能失败的系统接口。
正确做法是：在析构函数内检查错误但不抛异常；必要时记录日志或调用assert()（仅调试），生产环境通常忽略释放失败（因为资源已无法挽回，继续运行比崩溃更可控）：
立即学习“C++免费学习笔记（深入）”；
~FileGuard() {
if (fp_ && std::fclose(fp_) != 0) {
// 不 throw；可选：warn("fclose failed");
}
}原始指针裸露会破坏RAII契约，务必封装访问接口
用户若能直接拿到FILE*或int fd并手动fclose()或close()，RAII 就形同虚设。所有资源句柄都应设为private，只提供安全访问方式：
- 只读访问：
const FILE* get() const { return fp_; } - 带检查的解引用：
FILE* operator->() { assert(fp_); return fp_; } - 避免返回裸指针：
FILE* release() { FILE* tmp = fp_; fp_ = nullptr; return tmp; }（仅当明确要移交所有权时）
尤其注意：不要提供get()返回非const指针，也不要在类外用static_cast绕过封装——这等于主动撕毁 RAII 协议。
std::unique_ptr 已覆盖大部分场景，手写 RAII 类需明确理由
除非你要管理的是pthread_mutex_t、sem_t、mmap区域、CUDA context 等std::unique_ptr默认删除器不支持的资源，否则优先用标准库：
auto file = std::unique_ptr<FILE, decltype(&std::fclose)>(
std::fopen("log.txt", "w"), &std::fclose
);手写 RAII 类真正有价值的场景是：需要在构造时做复杂校验（如验证文件权限）、需要多资源协同（打开文件+加锁+记录日志）、或需与 legacy C API 深度耦合（比如某些硬件 SDK 要求资源必须按特定顺序初始化/销毁）。这时候，把逻辑收拢在一个类里，比堆砌多个unique_ptr更清晰、更难出错。
最易被忽略的一点：RAII 类的析构函数是否真的执行了？别只靠逻辑推导——加一句std::cerr 验证，尤其在异常路径、<code>return提前退出、或 longjmp 场景下。C++ 不保证析构一定发生，只有对象生命周期正常结束时才确定调用。
