RAII模板类必须严格管控资源生命周期：构造时获取资源并确保异常安全，禁用拷贝、显式实现noexcept移动语义，支持可定制删除器，且仅在标准智能指针无法满足特定领域语义（如信号量、GPU内存池）时才自研。
RAII模板类必须接管原始指针的生命周期
RAII不是“加个析构函数就行”，核心是资源获取即初始化——构造函数里必须完成资源申请，且一旦失败（如new抛异常），不能留下半截对象。否则析构函数无从清理，必然泄漏。
典型错误是把资源指针作为参数传入构造函数却不做所有权转移检查：
template<typename T>
class AutoPtr {
T* ptr_;
public:
AutoPtr(T* p) : ptr_(p) {} // 危险！没声明所有权，调用者可能还在用p
~AutoPtr() { delete ptr_; }
};- 构造函数应只接受
std::unique_ptr、std::shared_ptr或明确标记为“移交”的裸指针（如用std::move语义） - 若需支持裸指针，建议强制要求使用
AutoPtr::from_raw(p)静态工厂方法，并在内部置空原指针（或用explicit构造+注释警告） - 永远不要在构造函数里捕获异常后静默返回——要么让异常穿透，要么在构造前确保申请成功（如用
nothrow new配合手动检查）
拷贝与移动语义必须严格区分所有权
RAII类默认禁用拷贝（delete拷贝构造/赋值），否则两个对象析构时会重复delete同一块内存，触发未定义行为。但移动语义必须显式提供，否则资源无法传出作用域。
常见疏漏是只删了拷贝，却忘了实现移动：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template<typename T>
class AutoPtr {
T* ptr_;
public:
AutoPtr(AutoPtr&& other) noexcept : ptr_(other.ptr_) {
other.ptr_ = nullptr; // 关键：移交后置空
}
AutoPtr& operator=(AutoPtr&& other) noexcept {
if (this != &other) {
delete ptr_;
ptr_ = other.ptr_;
other.ptr_ = nullptr;
}
return *this;
}
AutoPtr(const AutoPtr&) = delete;
AutoPtr& operator=(const AutoPtr&) = delete;
};- 移动操作必须
noexcept，否则容器（如std::vector）扩容时可能退化为拷贝 - 移动后源对象必须处于“可析构但不可用”状态（通常指针置
nullptr），否则二次析构会崩 - 若资源类型不支持
noexcept释放（如某些文件句柄关闭可能阻塞或失败），需在文档中明确标注，避免用户误用于实时场景
自定义删除器要和资源释放逻辑强绑定
不是所有资源都用delete，文件句柄用close()，Windows句柄用CloseHandle()，C库内存用free()。RAII模板若硬编码delete，就失去通用性。
正确做法是把删除器作为模板参数或构造参数传入，且必须和资源类型匹配：
template<typename T, typename Deleter = std::default_delete<T>>
class AutoResource {
T* ptr_;
Deleter del_;
public:
AutoResource(T* p, Deleter d = Deleter{})
: ptr_(p), del_(std::move(d)) {}
~AutoResource() { if (ptr_) del_(ptr_); }
// ... 移动语义等
};- 删除器类型必须满足可调用、可移动（若需存储）、且不能抛异常（析构函数内不允许异常穿透）
- 若删除器捕获了外部变量（如lambda捕获），需确认其生命周期长于
AutoResource对象本身 - 对C风格资源（如
FILE*），推荐预设常用删除器别名：using FilePtr = AutoResource<FILE, void(*)(FILE*)>
不要试图替代std::unique_ptr或std::shared_ptr
标准库的智能指针已覆盖绝大多数场景：线程安全、定制删除器、别名构造、make_unique等。自己写的RAII模板除非有明确不可替代的理由（如嵌入式环境无STL、需特定调试钩子、或封装非指针资源如锁/信号量），否则大概率引入bug且维护成本高。
真正需要自研的情况极少，比如：
- 封装POSIX信号量（
sem_t），需在构造时sem_init，析构时sem_destroy - 管理GPU内存池中的块，释放逻辑涉及异步回调和引用计数
- 带超时自动释放的网络连接句柄，析构前需发FIN包并等待ACK
这些场景的关键不是“自动释放”，而是“释放动作本身具有领域语义”，此时才值得写专用RAII类。泛泛而谈“资源管理”，90%该直接用std::unique_ptr。
