私有Conan仓库（如cpp-local）专用于存储团队自研非开源C++二进制包，包括内部基础库、业务SDK、定制化第三方库及预编译嵌入式目标包；严禁上传公共库源码或未构建产物，须通过conan create/export-pkg生成完整包结构，并配合虚拟仓库cpp-all聚合远程与本地源，实现权限管控、签名验证与环境隔离。

私有仓库主要存团队自研 C++ 库的二进制包

Conan 私有仓库（如 cpp-local）不是用来镜像 ConanCenter 的，而是专为「你团队自己写的、不对外开源的 C++ 组件」服务的。典型包括：

• 内部基础库：比如统一日志模块 mylog/1.2.0、跨平台线程封装 mythread/0.8.3
• 业务 SDK：面向特定硬件或协议的封装，如 sensor-driver/2.1.0、can-protocol/0.5.1
• 定制化第三方库：你 fork 了 protobuf 并打了 patch，构建出 protobuf-patched/3.21.9，这种不能直接用官方版的必须走私有仓
• 预编译的嵌入式目标包：比如为 Cortex-M4 + GCC 12.2 + newlib 构建的 nanopb/0.4.6 静态库，ConanCenter 不提供该组合，只能自己 build 后上传

不要往私有仓库里塞公共库的原始源码或未构建产物

常见错误是把 boost/1.82.0 或 zlib/1.3.1 的源码 zip 包手动上传到私有仓——这违背 Conan 设计逻辑，也浪费存储和带宽。正确做法是：

Conan 2.31.2

Conan 2.31.2 官方历史源码包，适合复现依赖解析、CMake 配置、二进制包兼容性和跨平台构建环境。

下载

• 让私有虚拟仓库（cpp-all）聚合 conan-center（远程） + cpp-local（本地），开发时只配置一个 remote
• 公共依赖仍走 conan-center 下载；只有「无法从公开源直接构建」或「必须锁定内部修改版本」的包才进 cpp-local
• 上传前必须用 conan create . 或 conan export-pkg 生成完整包结构（含 conaninfo.txt、conanmanifest.txt 和二进制文件），不能只传 conanfile.py

企业级部署中，私有仓库还承担权限与合规控制

比如金融或车规项目要求所有依赖可审计、不可被外部篡改，这时私有仓库的作用就超出“存包”本身：

• 通过 JFrog CLI 设置细粒度权限：jfrog rt permission-create 可限制 dev-group 只能读 cpp-local，而 ci-bot 账号才有写权限
• 禁止上传未经签名的包：Artifactory 可配置 GPG 签名验证策略，确保每个 mycrypto/3.0.0 都附带团队私钥签名
• 隔离敏感构建环境：为 ARM64+Android NDK 构建的包，只允许发布到 cpp-android-local，避免被 x86 测试机误用

私有仓库的核心价值不在“多存几个包”，而在“精确控制哪些包能被谁、在什么条件下、以什么形态使用”。一旦开始混传公共包、跳过 conan create 流程、或忽略 profile 与 settings 的绑定，后续的二进制复现和 CI 稳定性就会快速崩塌。