需用 conan upload 显式上传本地 conan create 生成的包至远程仓库，如 conan upload "hello/0.1@" -r=myteam；上传前须配置远程、凭据及 profile，注意包引用格式、平台匹配与 ci 自动化发布策略。
怎么把本地 conan create 打的包推到团队可用的远程仓库
本地用 conan create 生成的包默认只存在你本机缓存（~/.conan2 或 C:\Users\XXX\.conan2），其他人根本看不到。要让团队用上，必须显式上传到一个大家都能访问的远程仓库。
常见错误是以为 conan create 自动发布——它不传，只建包；也不校验远程是否已存在同名包，直接覆盖风险高。
- 先确认远程仓库已添加：
conan remote add myteam https://artifactory.mycompany.com/artifactory/api/conan/conan-local - 确保你有写权限（通常需提前配置凭据：
conan user -r myteam -p YOUR_API_KEY） - 上传命令不是
conan create，而是：conan upload "hello/0.1@" -r=myteam --force（--force覆盖同名包，谨慎使用） - 注意包引用格式：必须带
@，如"hello/0.1@"表示不指定 user/channel；若配方里写了user="myorg"，则应为"hello/0.1@myorg/stable"
为什么上传后别人 conan install 还是找不到包
最常踩的坑是：远程仓库地址、包引用、profile 设置三者没对齐。
比如你在 Windows 上用 MSVC 构建，但同事在 Linux 上用 GCC 执行 conan install，即使包已上传，Conan 默认不会下载或构建适配对方环境的二进制——除非你上传时用了 --build=missing 或提前为多平台构建并上传了所有变体。
- 检查对方能否列出包：
conan search hello/0.1@ -r=myteam - 确认对方 profile 的
settings.compiler、settings.os和你上传时一致（用conan profile show default对比） - 如果只上传了 Windows 版二进制，Linux 用户执行
conan install会报Cannot find a valid package for 'hello/0.1'，而非连接失败 - 解决方式之一：上传时加
--all（上传所有配置变体），但更推荐按需上传 + 让 CI 自动构建多平台包
如何避免每次手动 conan upload？CI 中自动发布的关键点
人工上传不可靠，也难追溯。真实团队都走 CI 流水线自动发布，核心是控制“什么条件下允许上传”和“上传哪些东西”。
- 只允许从 tag 或特定分支触发上传（例如
git tag v0.1.0后触发） - 上传前必须通过
conan test验证包功能（需配套写test_package/目录） - 用
conan lock生成conan.lock文件并随包一起上传，保证依赖可复现 - CI 中不要用
--force，改用--skip-upload-existing防止误覆盖已验证版本 - 上传命令建议封装成脚本，并显式指定 profile：
conan upload "hello/0.1@myorg/stable" -r=myteam -pr:h=default
conan create 和 conan export-pkg 该选哪个
如果你已有编译好的库文件（比如预编译的 .a 或 .dll），别用 conan create——它会强制调用 build() 方法，可能破坏你已有的产物。
这时应该用 conan export-pkg，它跳过构建阶段，直接把现有二进制打包并导出到本地缓存，再上传：
- 准备一个空目录，放好头文件、库文件、
conanfile.py（含package()方法描述文件映射） - 运行：
conan export-pkg . hello/0.1@myorg/stable -pr:h=default - 再上传：
conan upload "hello/0.1@myorg/stable" -r=myteam - 注意：
export-pkg不校验源码一致性，所以务必确保conanfile.py中的settings和实际二进制匹配，否则上传后别人安装会链接失败
