std::unique_ptr配自定义删除器已覆盖95%场景；手写易漏noexcept、移动后置空等关键点，导致栈展开时调用std::terminate；仅当需延迟初始化、非指针资源封装、预释放回调或特殊共享语义时才应自定义RAII类。
别从零写 RAII 模板类——std::unique_ptr 配自定义删除器已覆盖 95% 的场景；手写极易漏掉 noexcept、移动后置空、拷贝禁用，甚至导致程序在栈展开时直接调用 std::terminate。
std::unique_ptr 自定义删除器必须标记为 noexcept
析构函数隐式调用删除器，而 C++ 标准要求析构函数不得抛异常。若删除器（如 lambda 或函数对象）内部调用 fclose 或 CloseHandle 且未加 noexcept，一旦该调用失败（比如 fclose 因缓冲区写入错误返回 EOF），编译器可能拒绝生成隐式移动构造函数，或更糟：在栈展开中触发 std::terminate。
实操建议：
- 所有删除器显式声明
noexcept：[](FILE* f) noexcept { if (f) fclose(f); } - 避免在删除器里做日志、网络 I/O、
std::cout等非异步信号安全操作 - 系统调用失败时只忽略返回值；调试期可用
assert或写入stderr，但生产环境不重试、不阻塞
lambda 删除器不能捕获外部变量（除非按值且 trivial）
捕获引用（[&log]）或含非 trivial 析构类型的变量（如 std::string）会导致删除器类型不可移动/不可复制，进而让 std::unique_ptr 移动失败或编译报错，错误信息往往晦涩如 “use of deleted function”。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 只按值捕获 POD 类型（
[ctx_id]、[flag]） - 需要上下文逻辑时，把状态封装进独立对象并传裸指针（
[ctx = ctx_ptr.get()]），确保ctx_ptr生命周期长于unique_ptr - 若必须带复杂状态，改用函数对象类，显式定义移动构造和
noexcept调用操作符
资源获取失败必须在构造时抛异常，不能“带病初始化”
RAII 的契约是：“对象存在 → 资源就绪”。如果 fopen 返回 nullptr、open 返回 -1、CreateFile 返回 INVALID_HANDLE_VALUE，却在构造函数体内设个 is_valid_ 标志位然后默默返回，后续调用 get() 就会暴露无效句柄——用户无法区分这是“资源未申请”还是“申请失败”，~RAIIHandle() 也可能对 nullptr 或无效句柄重复调用释放函数。
实操建议：
- 资源获取逻辑必须放在成员初始化列表中，失败立即
throw（如std::system_error） - 禁止在构造函数体中分配资源；否则异常中途跳出会导致对象未完全构造，析构函数不执行，泄漏发生
- 多步申请（如先
mmap再mlock）应拆成多个 RAII 对象，或用私有static工厂函数封装并保证回滚
什么时候才值得自己写 RAII 模板类？
只有当 std::unique_ptr 或 std::shared_ptr 无法满足以下任一条件时，才考虑手写：
- 需延迟初始化（
std::optional<T>+ 自定义析构可替代，但注意optional不自动调用析构，需手动控制） - 资源不是指针类型（如
intfd、HANDLE、pthread_mutex_t），且需封装状态检查（如is_locked()） - 需在
reset()前插入预释放回调（如日志、指标上报），此时可继承std::unique_ptr并重载reset - 需支持资源池、引用计数外的共享语义（如跨线程所有权转移但不允许多持有）
即便此时手写，也必须显式禁用拷贝、实现移动时置空、析构前判空、所有释放调用加 noexcept——这些不是“可选优化”，而是防止未定义行为的底线。
