RAII模板类必须严格接管原始指针生命周期，明确所有权、禁用拷贝、实现移动语义，支持自定义删除器，析构前判空，区分reset/release，匹配分配与释放方式（如new/delete或new[]/delete[]）。
RAII模板类必须接管原始指针的生命周期
RAII不是“加个析构函数就完事”，关键在于资源所有权必须明确且不可转移（除非显式支持移动）。如果你只是把 new 出来的指针存进类里，但没禁止拷贝、没定义移动语义、也没在析构里调用 delete，那它就不是RAII——它只是个普通容器，还容易导致双重释放或内存泄漏。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 模板参数应支持自定义删除器，比如
std::default_delete<t></t>或 lambda，不能硬编码delete - 默认禁用拷贝构造和拷贝赋值（
= delete），避免浅拷贝引发的资源争用 - 必须实现移动构造和移动赋值，否则无法用于返回局部对象或
std::vector等容器 - 内部存储用
T*而非std::unique_ptr<t></t>——否则就重复造轮子了，目标是理解而非封装已有设施
析构函数里调用 delete 前必须判空
常见错误是直接写 delete ptr_;，一旦对象被默认构造、移动后又析构，或者手动调用 reset() 清空过指针，ptr_ 就是 nullptr。C++标准规定对空指针调用 delete 是合法的，但依赖这个行为会掩盖逻辑缺陷，且自定义删除器（如关闭文件句柄）往往不接受空输入。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 在析构函数中统一用
if (ptr_) deleter_(ptr_);，显式控制执行路径 - 删除器类型应为
std::function<void></void>或函数对象模板参数，支持close(fd)、fclose(fp)等非delete场景 - 如果删除器抛异常（比如关文件时磁盘满），需在析构函数内
try/catch吞掉——析构函数不该传播异常
reset() 和 release() 的语义必须严格区分
reset() 是移交资源控制权并清理旧资源；release() 是放弃管理但不释放资源。混淆二者会导致资源泄露或提前释放。典型错误：在 reset(new T) 前没检查原指针是否非空，或 release() 返回后忘了手动 delete。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
reset(T* p = nullptr)：先用旧删除器清理当前ptr_，再更新为p -
T* release()：只置ptr_为nullptr并返回原值，不调用删除器 - 两个函数都应返回
void或原指针（按惯例），不要返回布尔值或状态码——语义已由函数名定义清楚
不支持数组类型的 delete[] 会静默出错
用 new int[10] 初始化 RAII 类，却用 delete ptr_ 释放，行为未定义。编译器不会报错，运行时可能崩溃或内存损坏。这不是“偶尔能跑通”的问题，而是 C++ 类型系统与动态内存协议之间的硬性约束。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 模板类本身不做
T是否为数组的推导——那是使用者的责任 - 提供特化版本：例如
raii_ptr<t></t>，其删除器默认为[](T* p) { delete[] p; } - 更稳妥的做法是：让模板接受删除器类型作为第二参数，如
raii_ptr<int decltype p delete></int>，强制显式声明释放方式
真正难的不是写一个能编译的 RAII 包装器，而是确保每次构造/移动/重置/析构时，资源的申请与释放次数严格一一对应，并且删除器的行为与分配方式完全匹配。这点在混合使用 malloc/free、Win32 CreateFile/CloseHandle、OpenGL glGenBuffers/glDeleteBuffers 时尤其容易漏掉。
