必须先执行 conan create 或 conan install --build=missing，确保包已构建并存入本地缓存，否则 conan upload 会因“Package not found”报错；前者适用于有源码和 conanfile.py 的场景，后者适用于已有依赖定义但未构建的情况。
conan upload 之前必须先 conan create 或 conan install --build=missing
私有仓库里空空如也，直接 conan upload 会报错 ERROR: Package not found。Conan 不允许上传“未构建完成”的包——它只认本地缓存中已存在的二进制或头文件产物。
所以迁移历史依赖的第一步不是推，而是确保每个包都已在本地缓存里“活”过一次：
-
conan create：适用于你有源码和conanfile.py的情况（比如fast-lzma2或cppstub），执行后生成包并存入缓存 -
conan install . --build=missing：适用于已有conanfile.txt/py但依赖尚未构建的项目，强制本地编译缺失项 - 若原项目用的是旧版 Conan（conan install 默认不触发构建，必须显式加
--build=missing，否则缓存里压根没东西可传
上传时要指定 remote 和 ref，别漏掉 @user/channel
Conan 的包引用（reference）是四元组：name/version@user/channel。私有仓库迁移最常踩的坑，就是把 zlib/1.2.13 这种裸引用直接往私有 remote 上传——它会被当成 zlib/1.2.13@_/_，而下游 requires = "zlib/1.2.13@myteam/stable" 根本匹配不上。
正确做法是上传前统一打上组织级 channel：
- 先重命名缓存中的包：
conan copy zlib/1.2.13@_/_ myteam/stable --all - 再上传：
conan upload "zlib/1.2.13@myteam/stable" -r=my-private-remote --force - 如果原始包带 profile 差异（比如 ARM/Debug），
--force必须加上，否则只传默认配置
避免重复上传失败包，用 conan list + conan search 先核对
私有仓库不是垃圾桶，传错版本或损坏包体后，conan upload 默认不会覆盖，而是报 ERROR: Recipe already exists。但这个错误不告诉你到底哪个配置冲突，容易卡在中间状态。
推荐上传前做两层检查：
- 查本地缓存是否完整：
conan list "zlib/1.2.13@myteam/stable"（Conan ≥2.0）或conan search "zlib/1.2.13@myteam/stable"（Conan 1.x） - 查远程是否已有同名包：
conan search "zlib/1.2.13@myteam/stable" -r=my-private-remote - 若远程已存在但内容不一致（比如少了 Debug 配置），必须先
conan remove再传，不能靠--force覆盖二进制层
CMake 集成时别依赖 conancenter，改用你的 remote
即使所有包都传进私有仓库了，如果项目 conanfile.py 里还写着 requires = "zlib/1.2.13"（无 channel），conan install 仍会优先去 conancenter 查找——除非你显式禁用或调序。
安全做法是收敛 remote 源：
- 运行
conan remote remove conancenter（如果不需要公共源） - 或至少调低优先级：
conan remote update my-private-remote --index=0 - CMakeLists.txt 中必须用
find_package(zlib CONFIG REQUIRED)，且确保CMakeDeps生成器输出的zlib-config.cmake来自你的 remote，而不是系统或 conancenter 缓存残留
真正麻烦的不是上传动作本身，而是上传之后——CMake 找不到包、链接时报 undefined symbol、甚至 conan install 在 CI 上突然拉到旧版二进制，往往是因为 remote 顺序、channel 命名或生成器缓存没清理干净。
