conan库升级需同步更新profile、abi设置及cmake生成器；默认不自动构建缺失二进制，须显式加--build=missing；openssl 3.1+要求c++17、正确toolchain和集成测试验证abi兼容性。
第三方库升级不是改个版本号就完事——Conan 里改 conanfile.txt 中的版本，只是第一步；漏掉 Profile 一致性、ABI 兼容性或生成器适配，编译能过、链接失败、运行段错误，都可能。
升级时为什么 conan install 报 “missing binary” 却不自动构建？
Conan 2.x 默认只尝试下载预编译二进制包，不主动触发源码构建，尤其当远程仓库（如 Conan Center）没提供匹配你当前 settings 的二进制时。
- 常见诱因：Profile 里写了
compiler.libcxx=libstdc++11，但远程只有libstdc++（旧 ABI）的包 - 交叉编译场景下，
os=Linux+arch=armv8组合在 Conan Center 的二进制覆盖率仍有限 -
--build=missing必须显式加，不能依赖默认行为；漏写就卡在「找不到包」而不是「开始编译」
实操建议：升级 OpenSSL 从 3.0.13 到 3.1.5 后，务必跑：
conan install .. --build=missing -pr:h profiles/arm64-release -pr:b default
其中 -pr:h 指定目标平台 Profile，-pr:b 指定构建机 Profile（通常用 default），避免 settings 错位导致二进制误判。
CMakeDeps 和 CMakeToolchain 生成器对升级敏感吗？
非常敏感。旧版 Conan 可能用 cmake_find_package，它靠 FindXXX.cmake 模拟查找逻辑；而 CMakeDeps 直接生成 XXXConfig.cmake，路径、target 名称、甚至头文件包含逻辑都由配方（Recipe）控制。
- OpenSSL 升级到 3.x 后，
OpenSSL::SSL和OpenSSL::Crypto成为标准 target；但若你 CMakeLists.txt 还写target_link_libraries(myapp PRIVATE ssl crypto)，会链接失败 -
CMakeToolchain若未随 Profile 更新（比如仍用 GCC 11 的 toolchain 去编译需 GCC 12 特性的新 OpenSSL），CMake configure 阶段就报错 - 每次升级后，删掉
build/下所有*.cmake文件再重跑conan install，避免缓存残留
交叉编译项目升级时，Profile 文件最容易被忽略什么？
Profile 不是“设一次就永远有效”的配置，它必须和你要升级的库的编译要求对齐。OpenSSL 3.1+ 默认启用 enable-fips 或要求 perl 环境，而你的 Profile 若没声明 tools.build:compiler_executables 或 sysroot 路径偏差，recipe 构建阶段就会失败。
- 检查 Profile 是否显式指定
compiler.cppstd=17：OpenSSL 3.1+ 构建脚本依赖 C++17 特性，GCC 11 默认 cppstd=14 会导致 configure 失败 - 确认
[env]区块是否补全了交叉工具链变量，例如：CC=/opt/arm64-toolchain/bin/aarch64-linux-gnu-gccAR=/opt/arm64-toolchain/bin/aarch64-linux-gnu-ar - 不要复用开发机 Profile 去构建目标平台库——
os=Linux在 x86_64 和 arm64 上 ABI 完全不兼容，Profile 必须严格区分 host/target
真正麻烦的从来不是「怎么升」，而是「升完谁来验证 ABI 兼容性」。OpenSSL 3.1 的 SSL_CTX_set_ciphersuites 是新增 API，但如果你的代码还调用了已废弃的 SSL_CTX_set_cipher_list，编译不报错、运行时握手失败——这类问题不会出现在 Conan 日志里，得靠集成测试兜底。
