Conan私有仓库必须启用revisions_enabled并结合包引用与revision确保可复现；conandata.yml需按settings分层映射；对外用语义化版本，对内可用时间戳扩展格式。
Conan私有仓库的版本号不能只靠语义化（SemVer）硬套
Conan 本身不限制版本号格式，但实际协作中，hello/1.0 这类写法在私有仓库里极易引发冲突——比如不同团队同时发 hello/1.0，却指向完全不同的二进制或源码。真正起作用的是「包引用 + revision」组合，而 revision 默认不显式暴露，容易被忽略。
必须启用 revisions_enabled 才能保证可复现
Artifactory 或 Conan Server 若未开启 revisions，上传同名包会覆盖旧版，CI 构建可能突然失败。检查和启用方式如下：
- Artifactory 7.x：进入
Admin → Configuration → General，勾选Enable Package Revisions - Conan CLI 配置：
conan config set general.revisions_enabled=True（客户端和服务端都需开启） - 验证是否生效：
conan upload hello/1.0 -r=myremote --force后再执行一次，两次上传应生成不同rrev（recipe revision）
conandata.yml 里怎么写版本映射才不踩坑
私有包若用 conan new 生成模板，conandata.yml 默认只存版本号，但实际需要绑定 Git commit、构建平台、编译器等上下文。常见错误是把所有变体塞进同一个版本：
- ❌ 错误写法：
1.0: {url: "...", commit: "abc123"}—— 没区分gcc-11/x86_64和clang-15/arm64 - ✅ 正确写法：按
settings分层，例如：1.0: {linux_gcc11: {commit: "...", sha256: "..."}, macos_clang15: {...}} - 上传时务必加
--build=missing并指定完整settings，否则conan upload可能漏传某平台二进制
私有仓库里要不要用日期版（如 20260921）？
可以，但仅限内部快速迭代场景，且必须配合 revision 使用。纯日期版的问题在于无法表达逻辑演进关系，比如 20260921 和 20260922 谁是主干、谁修复了 bug，全靠人工记。更稳妥的做法是：
- 对外发布稳定版：用语义化版本（
2.1.0），并打 Git tag - 对内每日构建：用
2.1.0+20260921格式，其中+后为构建时间戳，Conan 允许这种格式，且排序仍按主版本优先 - CI 流水线中，从
git describe --tags提取版本号，避免手输错误
revision 是隐式锚点，版本号是显式标签；两者缺一不可。漏掉 revision，版本号再规范也没法回滚到确切二进制。
