动态库版本冲突时应使用RTLD_LOCAL加载并隐藏非接口符号，通过带版本前缀的函数指针类型安全调用，封装生命周期管理，避免跨dlclose调用。
动态库版本冲突时，dlopen 加载失败怎么办
直接用 dlopen 指定路径加载不同版本的库文件，是可行的，但失败往往不是因为路径错，而是符号重定义或全局符号污染。Linux 下多个 .so 若导出同名全局符号（比如都定义了 init_config()），后加载的库可能被前一个覆盖，导致调用错乱甚至段错误。
- 必须在
dlopen时传入RTLD_LOCAL（而非默认的RTLD_GLOBAL），避免符号泄露到全局符号表 - 每个版本的库要确保导出符号加唯一前缀，或使用
visibility=hidden编译，并仅显式__attribute__((visibility("default")))导出接口函数 - 不要依赖
libfoo.so这种软链接——它会掩盖版本差异；必须用完整路径如/opt/lib/foo-v1.2.0.so
如何安全获取并调用不同版本库里的同名函数
不能靠 dlsym 直接取 "process_data" 这种裸名，否则两个版本的 process_data 地址可能混用。得把函数指针类型绑定到具体版本上下文里。
- 为每个版本定义独立的函数指针类型，例如：
using v1_proc_t = int(*)(const char*);和using v2_proc_t = int(*)(const char*, size_t); -
dlsym返回void*，必须强制转成对应版本的函数指针类型，不能转成通用函数指针再复用 - 建议封装加载逻辑：每个版本对应一个结构体，含
void* handle、各函数指针成员、以及卸载时的清理函数
dlclose 后还能继续调用已取的函数指针吗
可以，只要函数指针本身没被覆盖或释放，调用仍有效。但这是危险操作：若该库被 dlclose 后又被其他模块重新 dlopen（尤其同名不同版），其代码段可能被换掉，再次调用就跳进不可知地址。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 除非你完全控制所有
dlopen/dlclose顺序，否则不要跨dlclose调用函数指针 - 更稳妥的做法是：保持
handle生命周期与业务逻辑一致；需要切换版本时，先停用旧版所有调用，再dlclose，再加载新版 -
dlclose不等于立即卸载——只有引用计数归零才真正卸载，所以多次dlopen同一路径不会重复加载，但版本号不同则视为不同库
C++ 类型安全封装：避免手动 dlsym 的常见失误
手写一堆 dlsym + 强制转换极易出错，尤其是参数数量或 const 修饰不匹配时，编译器不报错，运行期崩。
立即学习“C++免费学习笔记（深入）”；
- 用模板 +
constexpr字符串做函数名检查：例如定义template<auto name> struct symbol_loader;</auto>，在编译期校验符号是否存在（需配合nm -D预扫描） - 把每个版本的接口抽象成纯虚类，运行期通过工厂函数返回实现对象，内部完成
dlopen/dlsym，对外隐藏指针细节 - 务必检查
dlsym返回值是否为nullptr——常见错误是忘了检查，直接调用空指针
最易被忽略的是 RTLD_LOCAL 和符号可见性配合使用；很多人只改 dlopen 标志，却没关掉库内不必要的符号导出，结果还是冲突。版本隔离不是靠路径区分，而是靠符号作用域隔离。
