conan 官方更新日志显示，2026年6月29日正式推出2.30.0版本，其中一个核心新特性是sbom生成模块新增了spdx表达式支持。对于需要交付软件物料清单的c/c++开发团队来说，这个更新的价值不在于日常命令用起来更顺手，而是许可证、依赖项和合规输出的内容，能直接对齐审计系统通用的标准表达格式。
来源：Conan 官方 Changelog
2.30.0版本还做了不少细节补全：给`LockfileAPI`补上了类型注解，给Conan的HTML输出页面加了专属favicon，新增`conf=~`作为配置项的取消赋值操作，在AutotoolsToolchain和GnuToolchain里加入`ASFLAGS`参数，支持架构和sysroot标志配置。同时还给Meson、Autotools、Premake这几个工具链新增了IntelCC支持，把msys2下的clang64、ucrt64等运行环境做了显式建模。这些改动都能看出来，Conan 2.30还在持续打磨构建系统适配、IDE和API的使用友好度。
来源：Conan 官方 Changelog
翻完2.27到2.30的版本更新记录就能发现，Conan这段时间一直在同步清理旧版本的遗留逻辑。2.27.0正式移除了原有的Conan 1.X别名兼容逻辑，新增CVE版本信息查询、Clang 22支持，还在HTML依赖图里展示了传递依赖关系；2.28.0引入了policies配置体系，针对版本范围、系统工具调用、构建图的展示逻辑做了一系列调整。大家升级到2.30.0的时候，记得把SBOM输出校验、policy配置迁移、旧脚本兼容性这几项放在同一轮测试里做完。
站在项目管理的视角看，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、upload或者SBOM输出来划定对应的测试范围。
信源说明：本文内容全部整理自Conan 2.30.0、2.28.0、2.27.0三个版本的官方更新日志；所有SBOM字段和许可证相关表达，请以项目自身的依赖元数据和官方工具的实际输出结果为准。
