必须同步更新conan.lock文件，否则版本变更不生效且CI构建不可重复；先修改conanfile.txt或conanfile.py中的版本号，再执行conan lock create . --lockfile-out=conan.lock，最后用conan install . --lockfile=conan.lock拉取新二进制。
直接更新依赖版本号并重新 install，但必须同步处理 conan.lock —— 否则版本可能不生效、CI 构建不可重复。
改 conanfile.txt 或 conanfile.py 里的版本号
这是最表层的动作，但不是全部。比如把 openssl/3.1.3 改成 openssl/3.3.2，或把 fmt/10.2.1 升到 fmt/10.3.0：
- 只改
[requires]行，其他部分（如[generators]）不用动 - 如果用
conanfile.py，注意版本可能写在self.requires("xxx/1.2.3")里，别漏掉引号和括号 - 版本号写错（比如拼成
openssl/3.3.22）会导致conan install报ERROR: Unable to find 'openssl/3.3.22' in remotes
必须运行 conan lock 重新生成 conan.lock
Conan 2.x 默认启用锁定机制：conan install 不会自动更新 lock 文件，只读取它。跳过这步，你的新版本根本不会进构建流程。
- 执行
conan lock create . --lockfile-out=conan.lock（推荐显式指定输出） - 如果项目已有
conan.lock，且只想升级某一个包（比如只升openssl），加--requires="openssl/3.3.2"参数 - 不带
--lockfile-out直接跑conan lock，会默认输出到当前目录的conan.lock，但容易覆盖旧版而没意识到 - 检查生成后的
conan.lock：搜索"openssl"，确认"ref"字段确实是新版本，且"rrev"（recipe revision）和"prev"（package revision）已刷新
再跑 conan install 才真正拉取/构建新二进制
此时 conan install 的行为取决于 lock 文件内容，而不是 conanfile 里的文字 —— 这是新手最容易混淆的点。
- 命令要带
--lockfile：例如conan install . --output-folder=build --build=missing --lockfile=conan.lock - 如果不加
--lockfile，Conan 会忽略你刚生成的 lock，退回到“按 conanfile 推导依赖图”，可能复用旧二进制、也可能出冲突 - 若提示
ERROR: Conflict in xxx: requirement yyy conflicts with zzz，说明传递依赖有版本不兼容，得看conan.lock里对应项的"requires"字段，手动加override或调整主依赖版本 - 交叉编译场景下，
--build=missing很关键：新 OpenSSL 版本大概率没有预编译的arm64二进制，不加这个参数会失败
真正难的不是改数字，而是理解 conan.lock 是事实源（source of truth）—— 它一旦生成，conanfile 就只起参考作用。团队协作时，conan.lock 必须提交进 Git，否则每人本地 install 出来的依赖可能完全不同。
