conan 2.31.0 的官方更新日志里明确标注，workspace 功能正式结束实验孵化阶段，这是该版本最核心的改动方向之一。workspace 专门面向多包、多仓库本地联调的开发场景，后续官方在 2.32.0 版本里又进一步增强了 workspace open、workspace add 等命令的能力，看得出来 conan 2 整个系列正在把工作区能力从之前的实验入口，逐步落地成日常开发的常规流程。
来源：Conan 官方 Changelog
2.31.0 版本还带来两个实用调整：一是 `replace_in_file` 现在支持正则匹配规则，二是如果执行完 `conan config install-pkg` 之后再跑 `conan config install`，工具会主动弹出警告。前者能让配方或者配置脚本实现更灵活的文本替换，后者则是提前提示用户配置来源和安装顺序可能引发非预期结果，对于需要维护内部配置包的企业团队来说，这类小提示能大幅减少「本地跑没问题、CI 环境复现失败」的棘手问题。
来源：Conan 官方 Changelog
同版本还新增了对 GCC 14.4、15.3，以及 intel-cc 2025.2、2025.3 和 2026.1 的适配，同时补上了 `cpp_info.ignored_requires`、NO_SONAME 支持、`.tar.zst` 格式解压等能力。这次更新不像 2.32.0 那样集中做批量工具链升级，而是把工作区、配置安装、编译器适配、依赖传播控制几大模块的改动放在同一轮迭代里，非常值得多平台 C/C++ 项目优先评估。
站在项目管理的视角看，Conan 这一系列更新，核心服务的都是多平台、多配置、多包协作的开发场景。C/C++ 团队日常遇到的痛点，往往不是单个依赖装不上，而是 lockfile、profile、tool_requires、远程仓库和本地缓存，没法在 CI 环境和开发机之间保持状态一致。官方更新日志里反复出现 workspace、graph、toolchain、SBOM、配置安装这类关键词，足以说明 Conan 2.x 后续的演进核心，依然是打磨全链路的工程化能力。
升级的时候一定要留意已经被移除或者收紧的旧逻辑：官方已经在多个版本里说明，之前标注过废弃的功能会按计划逐步删除，对应的配置项和命令参数，现在如果用法不对也会给出更明确的报错或者警告。如果团队自己维护了内部的 Conan 模板，最好先拿真实项目跑一遍完整的 install、build、graph、upload 和 workspace 流程，确认输出报告、缓存命中、远程权限这几部分都没有异常，再全量推送升级。
从官方的发布记录还能看出，Conan 的每个小版本通常同时包含新特性、功能调整、问题修复三类改动，不能只看版本号新旧就直接升级默认没风险。更稳妥的升级思路是先通读目标版本的官方更新日志，再根据自己项目有没有用到 Workspace、CMakeConfigDeps、AutotoolsToolchain、lockfile、上传功能或者 SBOM 输出，划定对应的测试范围，不用无差别全量测试。
信源说明：本文内容全部整理自 Conan 2.31.0 官方更新日志，以及 2.29.0、2.30.0 等周边版本的公开记录；所有 Workspace 相关的具体行为规则，请以当前版本的官方文档为准。
