结论：别从零手写RAII模板类，优先用std::unique_ptr配noexcept自定义删除器；仅当需延迟初始化、状态感知释放或封装非指针资源（如int fd、HANDLE）时才自定义。
直接说结论：别从零手写 RAII 模板类，优先用 std::unique_ptr 配自定义删除器；只有当需要延迟初始化、状态感知释放、或封装非指针资源（如 int fd、HANDLE）时，才考虑自定义。
std::unique_ptr 自定义删除器必须 noexcept
这是最容易踩的坑——删除器里调用 fclose()、close() 或 CloseHandle() 时，若没加 noexcept，一旦触发移动操作（比如函数返回该对象），程序可能直接崩溃。编译器不会报错，但运行时行为未定义。
-
std::unique_ptr<file void></file>这种写法隐含删除器是函数指针，天然noexcept；但 lambda 默认不是 - lambda 必须显式声明：
[](FILE* f) noexcept { if(f) fclose(f); } - 不能捕获局部变量（如
[&log]），否则类型不可移动；若真需上下文，改用函数对象或把状态塞进资源结构体 - C 风格函数指针（如
free、fclose）可直接传，无需包装
自定义 RAII 类必须禁用拷贝且移动后置空
手写模板时，= default 移动构造函数是典型错误——它只是浅拷贝指针，析构时两个对象都试图释放同一资源。
- 显式声明：
MyRAII(const MyRAII&) = delete;和MyRAII& operator=(const MyRAII&) = delete; - 移动构造中必须将源对象句柄设为无效值：
fd_(other.fd_) { other.fd_ = -1; }（对intfd）或ptr_(other.ptr_) { other.ptr_ = nullptr; } - 析构函数里仍要判空：
if (fd_ != -1) ::close(fd_);，因为移动后原对象还可能被析构 - 不提供
get()的非常量重载，避免用户拿到裸句柄后手动释放
构造函数失败必须抛异常，不能留“半成品”对象
RAII 的契约是“对象存在即资源就绪”。如果 fopen() 返回 nullptr、open() 返回 -1、CreateFile() 返回 INVALID_HANDLE_VALUE，构造函数就不能让对象活下来。
立即学习“C++免费学习笔记（深入）”；
- 资源获取必须在成员初始化列表完成，不能放到构造函数体里——否则异常抛出时析构不执行，泄漏发生
- 禁止用
is_valid_标志位“容忍失败”，这等于把资源管理责任推给用户 - 多步申请（如先
mmap再mlock）应拆成多个 RAII 对象，或用私有 static 工厂函数封装并做回滚 - 错误码必须转为异常：
throw std::system_error(errno, std::generic_category())
析构函数里释放失败只能忽略，绝不能 throw
析构中抛异常会直接调用 std::terminate()，尤其在栈展开期间（另一个异常正在传播时），这是 C++ 的硬性限制。
- 所有释放前加有效性检查：
if (handle_ != INVALID_HANDLE_VALUE) CloseHandle(handle_); - 忽略系统调用返回值是标准做法；生产环境不要重试、不要阻塞、不要记录日志（
std::cout/printf不是异步信号安全） - 若有依赖顺序（如
fflush()→fclose()），必须在析构函数内显式编码，不能靠成员变量销毁顺序 - 禁止在析构中调用任何可能抛异常的函数（包括
std::string构造、容器操作等）
最常被忽略的一点：RAII 安全的前提是资源生命周期和对象生命周期严格对齐。一旦出现裸指针传出、跨作用域转移、或异常中途跳出，手写类比 std::unique_ptr 更容易出错——后者经过标准库多年锤炼，移动语义、异常安全、类型约束都已完备。真要自定义，重点不在“怎么封装”，而在“怎么守住边界”。
