根本原因是dlopen失败未检查即调用dlsym导致段错误，且动态库依赖未满足时静默失败；必须检查dlopen返回值并用dlerror定位，路径用绝对路径，加载加RTLD_LAZY|RTLD_GLOBAL，符号需extern "C"导出。
为什么直接用 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++ 封装核心是构造加载、析构卸载，且禁止拷贝（句柄不可共享），只允许移动。
关键实现点：
立即学习“C++免费学习笔记（深入）”；
- 构造函数中调用
dlopen，失败则抛std::runtime_error（带dlerror()内容） - 析构函数中非空句柄必须调用
dlclose；注意dlclose返回值需检查，多次关闭同一句柄会出错 - 禁用拷贝构造/赋值：
DynamicLib(const DynamicLib&) = delete;；移动构造中将源句柄置为nullptr - 提供
get_symbol<T>(const char* name)模板方法，内部用reinterpret_cast<T>(dlsym(handle_, name))，调用前检查handle_和dlsym返回值
dlsym 返回的函数指针怎么安全转成 C++ 成员函数或带捕获的 lambda？
不能。C++ 成员函数有隐式 this 参数，ABI 上和 C 函数不兼容；lambda 若含捕获则不是 POD 类型，无法通过 dlsym 直接获取地址。这是常见误解。
正确做法：
- 动态库导出函数必须是
extern "C"的自由函数（避免名字修饰），参数/返回值限于 POD 类型 - 若需对象行为，约定接口为工厂函数，例如
extern "C" MyInterface* create_instance();，返回抽象基类指针 - 不要试图把 lambda 地址传给
dlsym——它根本不在动态符号表里
Linux 下调试 dlopen 失败的三个必查项
很多问题卡在环境层面，和代码逻辑无关。
- 确认目标 so 文件有执行权限：
ls -l libxxx.so，缺 x 权限时dlopen会失败（即使只是读数据） - 检查依赖是否满足：
ldd libxxx.so，出现not found的库必须提前用dlopen加载，或确保在/etc/ld.so.cache中 - 查看 SELinux 状态：
getenforce，强制模式下可能拦截动态加载，临时用setenforce 0排查（生产勿用）
符号可见性常被忽略：默认编译的 so 中函数是 hidden 的，需加 __attribute__((visibility("default"))) 或链接时加 -fvisibility=default。
