RAII类必须显式禁用拷贝，否则两个对象析构时会重复释放同一资源，导致未定义行为；正确做法是用= delete删除拷贝构造与赋值，并根据需要实现移动语义、封装原始指针、确保异常安全及定制化资源释放逻辑。
RAII类必须显式禁用拷贝，否则资源会重复释放
RAII的核心是“资源生命周期绑定对象生命周期”，一旦允许拷贝，两个对象会持有同一份资源指针，析构时触发两次delete或fclose，导致未定义行为。C++11起应直接删除拷贝构造和拷贝赋值：
class FileHandle {
FILE* fp_;
public:
explicit FileHandle(const char* path) : fp_(fopen(path, "r")) {}
~FileHandle() { if (fp_) fclose(fp_); }
<pre class="brush:php;toolbar:false;">FileHandle(const FileHandle&) = delete;
FileHandle& operator=(const FileHandle&) = delete;
// 移动语义可选但推荐
FileHandle(FileHandle&& other) noexcept : fp_(other.fp_) { other.fp_ = nullptr; }
FileHandle& operator=(FileHandle&& other) noexcept {
if (this != &other) {
if (fp_) fclose(fp_);
fp_ = other.fp_;
other.fp_ = nullptr;
}
return *this;
}};
常见错误是只删拷贝、忘了移动——结果无法传入临时对象或std::vector等容器；更隐蔽的是误写成= default，编译器会自动生成浅拷贝版本。
原始指针裸露会导致资源泄漏或悬空指针
RAII类内部若暴露get()返回原始指针，用户可能忘记检查空值、手动调用delete，或在对象析构后继续使用该指针。正确做法是：提供安全访问接口，且不暴露底层资源句柄。
立即学习“C++免费学习笔记（深入）”；
- 用
operator bool()支持条件判断：if (file) { ... } - 用
get()仅作只读访问，且文档注明“不转移所有权” - 避免提供
release()，除非明确设计为“移交资源控制权”的场景（如与C API交互）
例如std::unique_ptr的release()是特例，它清空内部指针并返回原值，后续对象不再管理该资源——这种操作必须由使用者完全承担责任，不应作为默认能力开放。
异常安全要求构造函数中申请失败必须不泄露资源
如果构造函数里做了多步资源申请（比如先malloc内存、再fopen文件），其中一步失败，前面已分配的资源必须被清理，否则泄漏。C++中唯一可靠方式是：每步申请后立即包装进一个已验证的RAII对象。
典型反例：
// ❌ 危险：new成功但fopen失败，buf泄漏
MyResource::MyResource(size_t sz) {
buf_ = new char[sz]; // 可能抛bad_alloc
fp_ = fopen("data.bin", "r"); // 可能为nullptr
if (!fp_) throw std::runtime_error("open failed");
}正确写法是分步构造，或用辅助RAII类型（如std::vector<char></char>替代裸new[]）：
// ✅ 先确保vector构造完成（不会抛异常），再打开文件
MyResource::MyResource(size_t sz) : buf_(sz), fp_(fopen("data.bin", "r")) {
if (!fp_) throw std::runtime_error("open failed");
}关键点：所有可能抛异常的操作，必须发生在资源已由其他RAII对象接管之后；否则就得在构造函数里写try/catch做手动回滚——这违背RAII初衷，也极易遗漏。
std::unique_ptr和std::shared_ptr不是万能替代方案
内置智能指针适合堆内存管理，但对文件描述符、互斥锁、GPU纹理、数据库连接等非内存资源，它们默认的delete或reset行为完全不适用。必须传入自定义删除器。
例如管理FILE*：
auto file = std::unique_ptr<FILE, decltype(&fclose)>(
fopen("log.txt", "w"),
&fclose
);注意三点：
- 删除器类型必须作为模板参数显式写出，否则编译失败
- 删除器必须是可调用对象（函数指针、lambda、functor），且不能捕获局部变量（lambda需
[=]或[]） - 若删除器有状态（如需要记录关闭日志），得用
std::function或自定义类型，但会带来小开销
自定义RAII类反而更轻量、意图更清晰，尤其当资源释放逻辑复杂（如需重试、需等待句柄关闭完成）时，硬塞进std::unique_ptr反而增加理解成本。
真正难的不是写个~MyRAII()，而是想清楚资源的所有权边界、生命周期交叠场景、以及谁该负责处理失败路径。这些细节不会报错，但会在某个凌晨三点的生产环境里突然浮现。
