conan不处理运行时动态库加载，仅负责编译期依赖分发与链接配置；需手动实现跨平台dlopen/loadlibrary逻辑，并通过--output-folder、conf配置、package()方法导出库文件，统一拼接库名，确保运行时路径、依赖、符号导出正确。
Conan 本身不处理运行时动态库加载，它只管编译期依赖分发和链接配置。真正要让程序在 Windows/Linux/macOS 上一致地 dlopen/LoadLibrary，得靠你自己写跨平台加载逻辑——Conan 只帮你把 libmath.so、mathlib.dll、libmath.dylib 正确构建、安装并告诉 CMake 链到哪，但加载时机、路径拼接、错误诊断全得手写。
Conan 怎么把动态库文件放进可部署路径
默认情况下，Conan 把动态库装进缓存目录（如 ~/.conan2/p/xxx），运行时根本找不到。你必须显式导出或重定向到项目本地目录：
- 用
conan install . --output-folder=deploy把二进制和库文件复制到deploy目录 - 在
conanfile.txt里加[conf]段控制输出结构，例如：[conf] tools.cmake.layout:build_folder_vars=["settings.build_type"]
- 对动态库包（比如自建的
myplugin/1.0），确保其package()方法里调用了self.copy("*.dll", dst="bin")、self.copy("*.so", dst="lib")等，否则conan install后压根没文件可加载
动态库名和路径怎么跨平台统一拼接
不同系统对库名约定不同，硬编码 "libmath.so" 在 Windows 上会失败。必须按目标平台生成正确文件名：
- Windows：用
"mathlib.dll"或"myplugin.dll"（LoadLibrary自动补.dll，但显式写更可控） - Linux：必须带
lib前缀和.so后缀，如"libmyplugin.so" - macOS：用
"libmyplugin.dylib"，注意 macOS 10.15+ 默认拒绝未签名 dylib，dlopen返回NULL且dlerror()报 “no suitable image found” - 推荐封装一个函数：
get_library_filename("myplugin")，内部用#ifdef _WIN32分支返回对应字符串
Conan 安装的动态库为什么 dlopen 失败
常见原因不是 Conan 装错了，而是运行时环境缺失：
-
LD_LIBRARY_PATH（Linux）或DYLD_LIBRARY_PATH（macOS）没包含 Conan 输出的lib/目录，dlopen找不到依赖链上的其他 so/dylib - Windows 下缺
.dll依赖（比如你的插件依赖openssl.dll），而 Conan 只保证头文件和静态链接信息，不自动把依赖 dll 复制到运行目录 - Conan profile 里
compiler.libcxx设成libstdc++却在 clang 下运行，导致dlsym找不到extern "C"符号——因为 name mangling 规则错配 - 忘记在动态库源码里加
extern "C"块，C++ 编译后符号名被修饰，GetProcAddress和dlsym都查不到
最易被忽略的一点：Conan 管的是“构建时可见性”，不是“运行时可见性”。哪怕 conan install 成功、CMakeLists.txt 里 target_link_libraries 也写了，只要运行时 dlopen 的路径不对、依赖缺失、符号没用 extern "C" 导出，就必然失败——这些环节 Conan 一概不介入，得你逐层验证。
