动态库加载这件事，看着简单，但实际用起来坑不少。很多人上来就用 dlopen 和 dlsym，结果不是段错误就是符号找不到，折腾半天还不知道问题出在哪。其实，这里面的关键点就几个，捋清楚了，写起来就稳了。
为什么直接用 dlopen 容易出段错误或符号找不到？
根本原因在于，dlopen 加载失败时不会主动报错，只是返回一个 nullptr。如果你没检查这个返回值，直接拿着空句柄去调 dlsym，那结果就是程序直接崩溃，而且往往连个提示都没有。更隐蔽的一种情况是，动态库本身依赖了其他共享库，比如 -lstdc++ 对应的 so 文件没提前加载，这时 dlopen 也会静默失败。唯一的线索，就是 dlerror() 返回的错误信息，但很多人恰恰忽略了这一步检查。
所以，实操上有几个原则必须守住：
- 每次
dlopen之后，必须紧跟着检查返回值：if (!handle) { fprintf(stderr, "%s\n", dlerror()); }，这行代码能救你一命。 - 加载时，建议使用
RTLD_LAZY | RTLD_GLOBAL组合。前者是延迟绑定，能降低启动开销；后者RTLD_GLOBAL则让当前库的符号对后续加载的库可见，避免依赖库之间互相找不到符号。 - 路径一定要用绝对路径。相对路径受当前工作目录（
cwd）影响极大，一旦程序运行环境变了，就容易找不到文件。可以用realpath("./xxx.so", nullptr)把相对路径转换成绝对路径，稳定可靠。
如何封装成 RAII 风格的 C++ 类避免资源泄漏？
裸指针管理 void* 句柄，最大的问题是容易忘记调用 dlclose，尤其是在异常路径下，资源泄漏几乎是必然的。C++ 封装的思路很清晰：构造时加载，析构时卸载，禁止拷贝（句柄本身不可共享），只允许移动。
关键实现点：
- 构造函数中调用
dlopen，如果失败，直接抛出std::runtime_error，并把dlerror()的内容带进去，方便定位问题。 - 析构函数中，只要句柄非空，就必须调用
dlclose。注意，dlclose的返回值需要检查，多次关闭同一个句柄会导致错误。 - 禁止拷贝构造和拷贝赋值：
DynamicLib(const DynamicLib&) = delete;。移动构造则要把源句柄置为nullptr，避免重复释放。 - 提供一个模板方法
get_symbol，内部用(const char* name) reinterpret_cast获取符号地址。调用前务必检查(dlsym(handle_, name)) handle_和dlsym的返回值，确保安全。
dlsym 返回的函数指针怎么安全转成 C++ 成员函数或带捕获的 lambda？
这个想法很常见，但结论是：不能。C++ 成员函数有隐式的 this 参数，在 ABI 层面和 C 函数不兼容。lambda 如果带了捕获，也不是 POD 类型，无法通过 dlsym 直接获取地址。这是不少新手容易踩的坑。
正确的做法：
- 动态库导出的函数，必须是
extern "C"的自由函数，避免名字修饰（name mangling）。参数和返回值也最好限定在 POD 类型，保证兼容性。 - 如果确实需要对象的行为，可以约定一个接口，比如
extern "C" MyInterface* create_instance();，返回一个抽象基类指针。这样既保持了灵活性，又绕开了函数指针不兼容的问题。 - 千万不要试图把 lambda 的地址传给
dlsym——它根本不在动态符号表里，这么做只会得到一个空指针。
Linux 下调试 dlopen 失败的三个必查项
很多 dlopen 的问题，其实和代码逻辑没什么关系，而是卡在环境层面。
- 检查目标 so 文件是否有执行权限：
ls -l libxxx.so。如果缺少 x 权限，dlopen会直接失败，即使你只是读取数据也一样。 - 用
ldd libxxx.so检查依赖是否满足。如果出现not found的库，要么提前用dlopen加载，要么确保它存在于/etc/ld.so.cache中。 - 查看 SELinux 状态：
getenforce。强制模式下，系统可能会拦截动态加载操作。临时可以用setenforce 0进行排查，但生产环境千万不要这么做。
还有一个容易被忽略的点：符号可见性。默认编译的 so 文件中，函数可能是 hidden 的，dlsym 根本找不到。需要在函数声明前加上 __attribute__((visibility("default")))，或者在链接时用 -fvisibility=default 强制所有符号可见。
