能避免典型问题，关键在于正确封装：构造时调用init并抛异常、析构时加初始化标志检查、禁用拷贝允许移动、全局单例需原子计数与call_once、分层封装全局状态与句柄、lambda删除器按值捕获。
直接用 RAII 封装第三方库的初始化/释放函数，能避免忘记调用 cleanup、异常路径下泄漏、多线程竞争等典型问题。关键不是“能不能”，而是“怎么封才不踩坑”。
构造时调用 init，析构时调用 cleanup
绝大多数 C 风格第三方库（如 OpenSSL、libcurl、SQLite3、libpq）都提供成对的 init() / cleanup() 函数，且要求调用顺序严格、不能重复、不能跨线程混用。RAII 的核心就是把这对操作绑定到一个对象生命周期里。
- 构造函数中调用
init()，失败时必须抛异常（比如std::runtime_error），禁止静默失败或返回错误码 —— 否则对象处于“半初始化”状态，析构时调用cleanup()可能崩溃 - 析构函数中无条件调用
cleanup()，且内部要加 guard：检查是否真被成功初始化过（例如用布尔标志位），避免重复释放或对未初始化状态调用 cleanup - 禁用拷贝（
= delete），允许移动（移动后原对象置为无效态），防止多个对象试图管理同一全局状态
单例式全局初始化需额外加锁
像 curl_global_init(CURL_GLOBAL_ALL) 这类函数是进程级单例，多次调用会出错；但多个 RAII 对象可能在不同线程同时构造。单纯靠对象生命周期不够，必须引入线程安全控制。
- 用
std::atomic<bool></bool>+std::call_once管理首次初始化，而不是靠对象数量判断 - 析构时不能直接调用
curl_global_cleanup()—— 它是全局的，只能在最后一个 RAII 实例销毁时调用；需用引用计数（std::atomic<int></int>）跟踪活跃实例数 - 示例：构造时
++counter并首次 init；析构时--counter，若归零才真正 cleanup
资源句柄与全局状态分离封装
有些库（如 SQLite3、PostgreSQL libpq）既需要全局初始化（sqlite3_initialize()），又需要每个连接单独管理（sqlite3_open() / sqlite3_close()）。这两层资源不能混在一个 RAII 类里。
立即学习“C++免费学习笔记（深入）”；
- 拆成两个类：
SQLiteGlobalGuard管理全局 init/cleanup，SQLiteConnection管理单个sqlite3*句柄 - 前者负责进程级状态，后者负责资源独占性 ——
SQLiteConnection应禁用拷贝、允许移动，并在析构时调用sqlite3_close() - 注意
sqlite3_close()返回值：它可能返回SQLITE_BUSY，但 RAII 析构函数不应抛异常；应记录日志或忽略，确保析构函数不 throw
Deleter 传入 lambda 时捕获变量要谨慎
当 cleanup 函数需要额外上下文（比如日志器指针、配置对象），容易想到用 lambda 捕获，但这极易引发悬空引用。
- lambda 必须按值捕获（
[log = std::move(logger)](void*) { log->info("cleanup"); }），绝不能按引用捕获外部局部变量 - 如果 logger 是栈对象，移动后原对象失效，lambda 内部调用仍安全；但如果捕获的是指针或引用，析构时访问已销毁对象就会 UB
- 更稳妥的做法是让 RAII 类持有所需上下文的副本（如
std::shared_ptr<logger></logger>），再传给 Deleter
最常被忽略的一点：很多第三方库的 cleanup 函数本身不是线程安全的，或者要求和 init 在同一线程调用（如 Windows 的 COM 初始化）。RAII 类无法自动满足这种约束，必须由使用者保证对象创建和销毁发生在同一逻辑上下文（比如同一线程、同一 event loop iteration），这点文档里往往不写，但 runtime 会 crash。
