raii模板类必须在构造函数初始化列表中完成资源申请和释放函数绑定，禁止在构造函数体内分配；析构函数需判空且noexcept，内部释放逻辑须捕获异常；禁用拷贝，移动后原对象指针置空；优先使用std::unique_ptr自定义删除器，仅在需额外校验、状态依赖或非指针资源时自定义。
RAII模板类必须把资源指针和释放函数绑定在构造函数里
RAII的核心不是“有析构函数”，而是“资源获取即初始化”——构造函数必须完成资源申请，且失败时不能留下半初始化对象。C++中常见错误是把资源指针设为nullptr再在构造函数体里new或fopen，这会导致异常安全问题：若申请失败抛出异常，对象未构造完成，析构函数根本不会调用，资源泄漏风险仍在。
正确做法是用成员初始化列表直接申请，并把释放逻辑（函数指针或lambda）一并传入：
template<typename t typename deleter="void(*)(T*)">
class RAIIHandle {
T* ptr_;
Deleter deleter_;
public:
explicit RAIIHandle(T* p, Deleter d) : ptr_(p), deleter_(d) {
if (!ptr_) throw std::runtime_error("resource allocation failed");
}
~RAIIHandle() { if (ptr_) deleter_(ptr_); }
// 禁用拷贝，只允许移动
RAIIHandle(const RAIIHandle&) = delete;
RAIIHandle& operator=(const RAIIHandle&) = delete;
RAIIHandle(RAIIHandle&& other) noexcept : ptr_(other.ptr_), deleter_(other.deleter_) {
other.ptr_ = nullptr;
}
};</typename>
- 释放函数类型
Deleter必须能匹配实际调用，比如fclose接受FILE*，就不能传void(*)(int*) - 构造失败时必须抛异常，不能返回错误码——否则用户可能忽略检查，违背RAII契约
- 不提供拷贝构造，避免两个对象同时持有同一资源；移动后原对象的
ptr_必须置为nullptr，防止重复释放
std::unique_ptr已经覆盖大部分场景，自定义RAII类只应在特殊需求下出现
很多人写自定义RAII模板，其实是没意识到std::unique_ptr的定制能力。它支持自定义删除器，且语法简洁、经过充分测试：
auto file = std::unique_ptr<file int>(fopen("log.txt", "w"), &fclose);
auto buf = std::unique_ptr<char void>(new char[4096], [](void* p) { delete[] p; });</char></file>
只有当以下情况存在时，才值得自己实现：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 需要在构造时做额外状态校验（如检查文件权限、验证socket地址格式）
- 释放逻辑依赖对象内部状态（如需先调用
shutdown()再close()） - 要封装非指针资源（如POSIX信号量
sem_t，需用sem_init/sem_destroy） - 目标平台无标准库（嵌入式），或禁用异常，需用
std::error_code替代抛异常
析构函数里调用释放函数前必须判空，且禁止抛异常
C++规定析构函数默认为noexcept，若在其中抛出未捕获异常，程序直接调用std::terminate。而资源释放函数（如fclose、munmap）本身可能失败并设置errno，但绝不能让它传播为C++异常。
所以所有释放逻辑必须包裹在try-catch内，或确保释放函数本身不抛异常：
~RAIIHandle() noexcept {
if (ptr_) {
try {
deleter_(ptr_);
} catch (...) { /* 忽略或记录日志，绝不能让异常逃逸 */ }
}
}
-
noexcept要显式声明，避免编译器隐式推导出noexcept(false) - 不要在析构里做复杂逻辑（如重试释放、网络请求），它应该快、确定、无副作用
- 对
malloc/free这类无状态释放，判空足够；但对sqlite3_close等可能返回SQLITE_BUSY的接口，需考虑是否真要忽略失败
移动语义必须保证原始对象进入有效但未拥有的状态
移动构造/赋值后，原对象仍可能被析构，因此它的析构函数必须能安全运行——最简单的方式就是把资源指针清零。但容易忽略的是：如果删除器本身是捕获了局部变量的lambda，移动后原对象携带的deleter_可能引用已销毁的栈内存。
- 删除器类型应满足可复制或可移动（
std::function可，但带引用捕获的lambda不可移动） - 推荐用函数指针或无捕获lambda作为默认删除器，复杂逻辑抽到静态函数里
- 测试移动后原对象析构是否真的不触发释放：打印日志、用
valgrind检查double-free
RAII真正难的不是写个模板，而是让每个构造、移动、析构路径都经得起异常、多线程和资源竞争的考验。别为了“模式”而模式，先确认std::unique_ptr或std::shared_ptr加自定义删除器能不能解决，再决定是否亲手造轮子。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
