看conan官方更新日志，2.31.2版本在2026年8月4日正式推送，核心改动全部集中在上传流程上：用`conan upload .. --dry-run -f=json > to_upload.json`生成的json文件，现在可以直接给`conan upload -l=to_upload.json`调用走完完整上传流程，不需要重新准备所有待上传构件。这个改动看起来覆盖场景很窄，但对把dry-run预演设为发布审核必经步骤的团队来说非常关键。
来源：Conan 官方 Changelog
在二进制包的完整发布链路里，dry-run导出的JSON一般用来让CI先拉取全量待上传内容清单，再把这份清单传给后续的审批、签名、实际上传环节。这次官方修复后，同一份清单可以更稳定地跨环节传递，大幅减少「预演阶段展示的待上传内容」和「实际上传时重新计算生成的内容」出现偏差的概率。这点对私有远程仓库、多平台构建场景尤其友好，这类场景下待上传构件数量多、依赖图复杂，重复生成清单既耗时间，也很容易出现漏错。
来源：Conan 官方文档
整个2.31.x系列还带来了不少其他改动：Workspace功能结束孵化正式上线、replace_in_file支持正则匹配、config install新增使用顺序提示等等。2.31.2本身没有新增大功能，却补上了发布流水线里之前缺失的这块实用能力。如果你们团队已经升级到2.31.0或者2.31.1，日常也在用JSON清单驱动上传流程，建议优先验证2.31.2的upload dry-run全流程是否符合预期。
从项目协作的角度来看，Conan这一系列更新，主要都是为了适配多平台、多配置、多包协同的复杂开发场景。C/C++开发团队的常见痛点从来不是单个依赖能不能安装，而是lockfile、profile、tool_requires、远程仓库和本地缓存，能不能在CI环境和开发者本地机器上保持行为完全一致。官方更新日志里反复提到workspace、依赖图、工具链、SBOM、配置安装这些关键词，也能看出来Conan 2.x后续的迭代重点，依然放在工程化链路的体验优化上。
升级版本的时候也要留意部分旧行为已经被移除或者收紧。官方在多个版本里都明确标注，不少之前标记为废弃的功能已经按计划删除，对应的配置项和命令参数也会给出更明确的报错或警告提示。如果团队自己维护了内部的Conan模板，升级前最好先用真实项目把install、build、graph、upload、workspace这些核心流程全跑一遍，确认最终报告输出、缓存命中情况、远程权限都没有异常。
从官方公开的更新记录还能看出来，Conan的小版本更新通常会同时混进新特性、功能调整、问题修复三类改动，不能只看版本号高低就直接判断升级风险。更稳妥的升级思路是先通读目标版本的更新日志，再根据自己项目实际用到的功能——比如有没有用Workspace、CMakeConfigDeps、AutotoolsToolchain、lockfile、上传导出清单、SBOM输出这些，来划定对应的测试范围，不需要全量覆盖所有功能。
信源说明：本文内容整理自Conan 2.31.2和2.31.0官方更新日志、Conan Workspace官方文档；不同团队的远程仓库权限、CI流程都有差异，实际升级效果请结合自身环境验证。
