RAII 是 C++ 资源管理的核心契约，需将初始化与清理严格绑定于构造/析构函数；推荐优先使用 std::unique_ptr + 自定义 deleter 封装资源，避免裸指针泄漏，注意析构函数不可抛异常。
用 RAII 模式把初始化和清理绑死在构造/析构里
直接在构造函数里做初始化、析构函数里做清理，是最自然也最安全的做法。C++ 的对象生命周期管理机制天然支持这个模式，只要不手动调用 delete 或提前 std::move 出作用域，就能保证清理一定发生。
常见错误是：把资源句柄（比如 FILE*、int socket_fd、void* cuda_stream）存为裸指针或原始整数，又没在析构里显式释放——结果资源泄漏，且无编译器提醒。
- 初始化失败时，构造函数抛异常，对象不会被创建，也就没有析构问题；但得确保已分配的中间资源能被正确回滚（比如先 malloc 了一块内存，再 open 失败，就得在 catch 里 free）
- 避免在构造函数里做耗时或可能阻塞的操作（比如网络连接、大文件读取），否则会拖慢栈上对象创建，也难测试
- 如果类需要移动语义，必须显式定义移动构造函数和移动赋值运算符，并把原对象的资源置为无效状态（比如设为
-1或nullptr），否则析构时会 double-free
std::unique_ptr + 自定义 deleter 是最省心的封装方式
当初始化返回的是一个原始指针（比如 new、malloc、glfwCreateWindow），而清理需要调用特定函数（比如 delete、free、glfwDestroyWindow），直接用 std::unique_ptr 包一层，把清理逻辑塞进 deleter 里，比手写构造/析构更简洁、更难出错。
示例：封装 OpenGL 上下文
立即学习“C++免费学习笔记（深入）”；
class GLContext {
std::unique_ptr<void, void(*)(void*)> ctx_;
public:
GLContext() : ctx_(glfwCreateContext(), [](void* p) { glfwDestroyContext(p); }) {
if (!ctx_) throw std::runtime_error("failed to create GL context");
}
};- deleter 必须是可调用对象（函数指针、lambda、functor），且类型要和
std::unique_ptr<T, D>的第二个模板参数一致；捕获变量的 lambda 不能用于模板推导，得显式写类型 -
std::unique_ptr不支持数组语法（new[]），要用std::unique_ptr<T[]>，其默认 deleter 就是delete[]，不用额外指定 - 如果初始化函数返回的是非指针类型（比如
int fd），就别硬套std::unique_ptr，改用 RAII 类或std::optional<int>配合独立的 close 函数
避免把“可选初始化”逻辑塞进构造函数
有些场景下，初始化可能失败但你不想抛异常（比如日志模块尝试连 syslog，连不上就退化到 stderr），这时硬塞进构造函数会让接口变重、语义模糊——用户无法区分“对象构建失败”和“功能降级”。
- 推荐拆成两步：先构造空对象（不执行任何外部操作），再提供
init()成员函数返回bool或std::expected<void, Error> - 此时必须加标志位（如
bool inited_ = false;）并在所有业务函数开头检查，否则容易触发未定义行为 - 析构函数仍需安全：若
init()没成功，清理逻辑应跳过或静默；但资源字段（如int fd_ = -1;）必须初始化为无效值，防止误清理
std::shared_ptr 的自定义 deleter 容易踩内存生命周期坑
用 std::shared_ptr 封装带清理逻辑的资源时，deleter 持有对外部对象的引用（比如捕获 this 或某个 manager）会导致循环引用或悬垂指针，尤其在多线程环境下。
- deleter 中不要捕获 this 指针；如果必须关联其他对象，用
std::weak_ptr替代std::shared_ptr捕获 - deleter 执行时机不可控（最后一个
shared_ptr被销毁时），不适合需要确定性清理的场景（比如 GPU stream 同步、文件锁释放） - 比起
shared_ptr，优先考虑unique_ptr或栈对象 RAII；只有真正需要共享所有权时才用前者
RAII 不是语法糖，是 C++ 资源管理的契约。最容易被忽略的点是：析构函数里不能抛异常——一旦在栈展开过程中析构器再抛异常，程序直接 terminate。所以所有可能失败的清理操作（比如 close() 返回 -1）都得默默吞掉错误，或记录日志，绝不能 throw。
