不能只用conancenter，因其是公开只读社区仓库，无法上传私有库、控制生命周期、审计操作、保障二进制兼容性；公司级公共库需自建私有远程仓库（如artifactory）实现统一入口、权限隔离与元数据可溯。

适合，但必须搭配私有远程仓库使用，单纯用 ConanCenter 或本地缓存无法满足公司级公共库的可控性、安全性和协作需求。

为什么不能只用 conan-center

ConanCenter 是公开、只读的社区仓库，所有包由社区审核发布，你无法：

• 上传内部封装的 Hello、company-utils 这类私有库
• 控制包的生命周期（比如下线一个有漏洞的旧版本）
• 审计谁上传/下载了哪个包、何时操作
• 保证二进制兼容性——不同团队用不同 settings（如 compiler.version=12 vs 14）构建的包，在 ConanCenter 上不会自动归并或标记冲突

必须自建远程仓库（如 Artifactory）

公司级公共库管理的核心是「统一入口 + 权限隔离 + 元数据可溯」，这只能靠私有远程仓库实现。常见组合：

Conan 2.31.2

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

下载

• Artifactory CPP CE（免费版已足够中小团队）：支持 Conan v1/v2 协议，提供 Web UI、权限组、审计日志、代理缓存
• Cloudsmith 或 PackageCloud：托管型服务，省运维但需评估合规与网络策略
• 不推荐纯 conan remote add ./repo --allowed-packages="*" 这种本地目录“伪远程”：它没并发控制、无鉴权、不支持多用户同时上传、无法做包签名验证

关键配置点容易被忽略

即使搭好了 Artifactory，以下三点不做清楚，很快会陷入包混乱：

• 强制启用 verify_ssl=True：避免中间人劫持，尤其在 CI 环境中默认可能为 False
• 为每个业务线/部门设置独立 remote 和 repository（如 team-a-prod、team-b-staging），而不是全公司共用一个 conancenter 别名
• conan upload 时必须带 --check 参数校验包完整性；否则损坏的 conanfile.py 或缺失的 export_sources 会导致下游构建失败且难以定位

真正卡住团队的往往不是 Conan 本身，而是上传流程没人审核、版本号随意打、requires 写死 commit hash 而非语义化版本——这些得靠流程和权限来管，不是工具能自动解决的。