RAII是唯一能防止dlopen/dlsym/dlclose引发崩溃和泄漏的方式：构造函数必须检查dlopen返回值并异常终止，析构函数noexcept仅dlclose，禁用拷贝、移动转移句柄，符号获取须绑定对象生命周期。
直接用 dlopen/dlsym/dlclose 手动管理动态库句柄，90% 的崩溃和符号未定义错误都源于加载失败后继续调用 dlsym，或重复 dlclose、漏关导致句柄泄漏。RAII 不是“更优雅的写法”，而是唯一能堵住这些漏洞的方式。
构造函数里必须检查 dlopen 返回值并抛异常
裸调 dlopen 失败返回 nullptr，但很多人只做 if (!handle) return; 然后往下走——后续任何 dlsym 都会崩。RAII 类的构造函数必须把加载失败当作不可恢复错误处理：
- 构造函数参数应包含
const char* lib_path和int flags（如RTLD_LAZY | RTLD_LOCAL） - 调用
dlopen后立即判空，为空则 throwstd::runtime_error("dlopen failed: " + std::string(dlerror())) - 绝不能留一个“半初始化”对象：要么完整构造成功，要么彻底失败、不留下可析构的脏状态
析构函数必须 noexcept 且只做 dlclose
dlclose 可能失败（比如引用计数未归零），但析构函数绝不能抛异常——否则栈展开时二次崩溃。正确做法是：
- 析构函数声明为
~LibHandle() noexcept - 只执行
if (handle_) dlclose(handle_);，不检查返回值，不打印日志，不重试 - 不把
dlerror()放进析构逻辑：它不是线程安全的，且可能在信号上下文中被调用
拷贝禁用、移动语义必须转移句柄所有权
多个对象持有同一 void* 句柄，dlclose 被调两次就触发未定义行为。标准解法是：
立即学习“C++免费学习笔记（深入）”；
- 显式删除拷贝构造与拷贝赋值：
LibHandle(const LibHandle&) = delete;、operator=(const LibHandle&) = delete; - 移动构造中接管句柄并置空源对象：
handle_ = other.handle_; other.handle_ = nullptr; - 移动赋值前先
dlclose当前句柄（若非空），再接管新句柄 - 所有成员变量（如
void* handle_）初始化为nullptr，避免析构时误关野指针
dlsym 查符号必须绑定到 RAII 对象生命周期内
拿到函数指针后，不能把它存成全局裸指针或静态变量——库卸载后调用就是段错误。正确姿势是：
- 提供
template<typename funct> FuncT symbol(const char* name)</typename>成员函数 - 内部调用
dlsym(handle_, name)，判空后reinterpret_cast并返回 - 返回的函数指针只应在当前
LibHandle对象存活期间使用；离开作用域即失效 - 不缓存符号地址：不同平台对
dlsym结果的稳定性要求不同，缓存反而增加风险
最易被忽略的一点：dlopen 的 RTLD_GLOBAL 标志会影响整个进程的符号可见性，和 RAII 封装无关——它属于链接策略，应在设计阶段决定，而不是在 RAII 类里动态切换。别试图在构造函数里根据条件改 flag，那会破坏封装边界。
