conan升级openssl前必须确认abi兼容性、证书路径变更、插件机制及构建选项延续；openssl/3.3.2升级后ssl_ctx_new崩溃，主因是libssl.so符号绑定变化或混用系统旧库，需用readelf和ld_debug验证依赖与加载路径，并显式配置fips、tls版本及证书路径。
升级 Conan 依赖前，必须先确认 ABI 兼容性、证书路径变更、插件加载机制和构建选项是否延续——OpenSSL 这类底层库不是换版本号就完事。
openssl/3.3.2 升级后 SSL_CTX_new 崩溃？检查 ABI 和 libssl.so 版本符号
Conan 升级 OpenSSL 后常见崩溃点不在代码，而在二进制层：新版本 libssl.so.3 默认启用 FIPS 模式或禁用旧 TLS 协议，且符号表与 libcrypto.so 的绑定关系可能变化。尤其当项目里混用了系统 OpenSSL（如 Ubuntu 自带的 /usr/lib/x86_64-linux-gnu/libssl.so.1.1）时，dlopen 加载会静默失败，SSL_CTX_new 返回 NULL。
- 用
readelf -d ~/.conan2/p/b/openss*/package/*/lib/libssl.so | grep NEEDED确认它依赖的是libcrypto.so.3，而非.so.1.1 - 运行时加
LD_DEBUG=libs查看实际加载路径，避免LD_LIBRARY_PATH指向了旧系统库 - 若需兼容旧协议，得在
conanfile.txt中显式传参：[options] openssl:fips=False openssl:no_tls1_3=False
conan install --build=missing 不等于自动适配新 profile
升级依赖版本后，如果 profile 里 compiler.version 或 os 有微调（比如从 gcc 11 改成 gcc 12），Conan 不会自动复用旧二进制包——哪怕只差一个小版本，也会触发重新编译。但更隐蔽的问题是：profile 中漏掉 compiler.libcxx，会导致 std::string 在链接时出现 undefined reference to __cxa_throw。
- 每次升级依赖前，先跑
conan profile show default和conan profile show your-cross-profile对比关键字段 - 交叉编译 profile 必须显式写全
compiler.libcxx，不能依赖detect—— 它在容器或 CI 环境里常识别错 - 升级后首次
conan install建议加--verify参数，强制校验远程包哈希，防缓存污染
conan.lock 文件不更新？手动删 generators/ 和 conan.lock 再重装
Conan 2.x 默认基于 conan.lock 解析依赖树。但如果你只改了 conanfile.txt 里的版本号（比如 openssl/3.0.13 → openssl/3.3.2），却没删旧 lock 文件，Conan 会优先沿用锁文件里记录的旧解析结果，导致升级无效。
- 执行
rm -rf generators/ conan.lock，再跑conan install . --build=missing - CI 流水线里务必把
conan.lock提交进 Git，否则不同机器上解析出的传递依赖（比如zlib、cares）可能版本不一致 - 别信
conan update—— 它只更新远程索引，不刷新本地 lock
真正容易被忽略的，是证书路径硬编码问题：OpenSSL 3.x 默认不再内置 CA 路径，SSL_CTX_set_default_verify_paths() 可能返回 0；你得在代码里显式调用 SSL_CTX_load_verify_locations(ctx, "/path/to/cacert.pem", NULL)，而这个路径必须和 Conan profile 里 tools.build:sysroot 下的根文件系统结构对齐。
