RAII模板类需通过可调用对象传入自定义释放逻辑以支持各类资源，禁止硬编码删除器；必须显式实现noexcept移动语义并置空源指针，禁用拷贝；构造函数内不得混合资源申请与初始化，推荐工厂函数保障异常安全；优先使用std::unique_ptr而非自研。
RAII 模板类必须接收自定义释放函数才能通用
裸指针 + delete 或 free 无法覆盖所有资源类型，比如文件描述符、GPU 显存句柄、Windows HANDLE、POSIX 信号量等。硬编码释放逻辑会让模板失去泛用性。
正确做法是把释放行为作为可调用对象（函数指针、lambda、functor）传入构造函数，并用 std::function 或函数指针类型擦除存储：
template<typename t>
class ScopedResource {
T* ptr_;
std::function<void> deleter_;
<p>public:
template<typename d>
ScopedResource(T* p, D&& d) : ptr<em>(p), deleter</em>(std::forward<d>(d)) {}</d></typename></p>
<pre class="brush:php;toolbar:false;">~ScopedResource() { if (ptr_) deleter_(ptr_); }
// ... 省略移动/禁用拷贝等必要操作
};
- 不要用模板参数固定删除器类型（如
template<typename t typename deleter></typename>），否则每次不同释放逻辑都要实例化新类型，增加编译膨胀 - 若追求零开销，可用
Deleter作为第二模板参数 + 特化operator()，但需用户显式指定，灵活性下降 - 注意：
deleter_必须能处理nullptr，或在析构前手动置空ptr_，否则重复释放易触发未定义行为
移动语义必须显式实现，否则资源会意外泄漏
默认生成的移动构造函数和移动赋值运算符只是 bitwise 拷贝指针，导致两个对象指向同一资源，析构时 double-free。
必须显式定义移动操作，并将源对象的 ptr_ 置为 nullptr：
ScopedResource(ScopedResource&& other) noexcept
: ptr_(other.ptr_), deleter_(std::move(other.deleter_)) {
other.ptr_ = nullptr;
}
<p>ScopedResource& operator=(ScopedResource&& other) noexcept {
if (this != &other) {
reset(); // 先释放当前资源
ptr<em> = other.ptr</em>;
deleter<em> = std::move(other.deleter</em>);
other.ptr_ = nullptr;
}
return *this;
}</p>
- 不加
noexcept可能导致std::vector扩容时退化为拷贝，破坏 RAII 安全边界 -
reset()必须检查ptr_ != nullptr再调用deleter_，否则释放空指针可能崩溃（尤其 WindowsCloseHandle） - 禁止提供拷贝构造/赋值——直接
= delete，避免用户误用
构造失败时资源必须立即释放，不能依赖析构
如果构造函数里申请资源成功，但后续初始化（如绑定、验证、设置属性）失败，此时对象尚未完成构造，析构函数不会执行。
典型错误写法：
ScopedResource(int fd) : ptr_(new int(fd)) {
if (!validate_fd(fd)) throw std::runtime_error("bad fd");
// 此时 fd 已泄露！ptr_ 指向 new 出来的 int，但 fd 本身没关
}
正确方式：在构造函数体外完成资源获取，或用工厂函数封装异常安全流程：
static ScopedResource<int> make_fd(int fd) {
if (!validate_fd(fd)) throw std::runtime_error("bad fd");
return ScopedResource<int>(fd, [](int fd) { ::close(fd); });
}</int></int>
- 永远不要在构造函数里做「申请 + 多步初始化」混合操作
- 对 C API 资源（如
malloc、open、cudaMalloc），建议先调用底层接口，再根据返回值决定是否构造对象 - 若必须在构造中申请，用
try/catch捕获并手动释放，但代码丑陋且易漏 —— 工厂函数更清晰
std::unique_ptr 已覆盖绝大多数场景，自研需有明确理由
除非要管理非指针资源（如 int 类型的 socket fd）、或需要定制非常规释放时机（如延迟到 event loop 下一帧释放），否则直接用 std::unique_ptr 配合自定义 deleter 更安全可靠。
例如管理文件描述符：
auto fd_deleter = [](int* fd) { if (fd && *fd != -1) ::close(*fd); };
using unique_fd = std::unique_ptr<int decltype>;
unique_fd ufd(new int(open("/dev/null", O_RDONLY)), fd_deleter);</int>
-
std::unique_ptr的移动语义、noexcept、SFINAE 友好性都经过严格验证，自研容易踩隐晦坑 - 若真要封装，优先考虑组合而非继承：
class FileDescriptor { std::unique_ptr<int ...> fd_; }</int>，比裸模板更易约束接口 - 最常被忽略的一点：RAII 对象的生命周期必须严格对应作用域。把它塞进
std::shared_ptr或跨线程传递，就脱离了“自动”范畴，得自己保证线程安全与释放顺序
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
