必须用精确版本号和channel，如openssl/3.3.2@；禁用~或^模糊语法，Conan 2.x不支持；主版本变更必破ABI；生产环境须配合profile固定的conan.lock使用。
必须用精确版本号，不能用波浪号（~）或插入号（^）模糊匹配。 Conan 没有 npm 那套语义化自动升级逻辑，模糊写法在 CI 或不同机器上极易导致构建漂移——今天能过，明天换台机器就链接失败。
conanfile.txt 里 require 的写法必须带完整版本和 channel
常见错误是只写 openssl/3.3.2，看似没问题，但 Conan 默认会去 conancenter 查，而某些旧版 OpenSSL 在 conancenter 没预编译包；--build=missing 又没开，就会卡住不动。
- 稳妥写法是显式带上
@表示默认 channel：openssl/3.3.2@ - 若依赖来自私有仓库或特定用户频道，必须写全：
gtest/1.14.0@bincrafters/stable（尽管现在多数已迁移到 conancenter） - 绝对不要用
openssl/~3.3或openssl/^3.3—— Conan 2.x 不支持这种语法，会直接报错或退化为远程搜索，结果不可控
版本号本身要遵循 SemVer，且与 ABI 兼容性强相关
C++ 库的二进制兼容性极脆弱。主版本号变更（如 openssl/2.x → openssl/3.x）几乎必然破坏 ABI，哪怕只是头文件里加了个 [[nodiscard]] 或改了枚举值顺序。
- 主版本号递增：不兼容 API/ABI，必须全量验证下游代码
- 次版本号递增：新增功能但保持 ABI 向后兼容，可灰度上线
- 修订号递增：仅修复 bug，理论上可无感替换（但仍建议跑一遍集成测试）
- 嵌入式项目尤其注意：OpenSSL 3.3.2 和 3.3.1 可能在
sysroot下触发不同的符号解析行为，别只看 patch 号
生产环境必须配合 lockfile 使用
conan install 单独运行不生成锁文件，conan lock 才能固化整个依赖图谱。没有 lockfile，conan install 每次都可能拉到不同编译参数下的二进制（比如某次用了 libstdc++11，下次变成 libstdc++14），静态链接时直接报 undefined reference。
立即学习“C++免费学习笔记（深入）”；
- 生成锁文件：
conan lock create --requires="openssl/3.3.2@" --profile:build=default --profile:host=arm64-release -o build_type=Release - 后续构建统一用锁文件驱动：
conan install conan.lock --output-folder=build --build=missing - CI 流水线中应校验
conan.lock是否被意外修改，否则“可重现构建”就是空话
最常被忽略的一点：Conan 的版本锁定只管“谁来提供”，不管“怎么编”。同一个 openssl/3.3.2@，用 gcc-12 和 clang-16 编出来的库，libssl.a 里的符号 ABI 就不互通。所以 profile 必须和版本声明一起进仓库，缺一不可。
