根本原因是Conan本地缓存中缺失对应ID的二进制包，需先运行conan search ref确认该引用是否存在；若不存在，说明conan create或conan export-pkg未成功执行。
conan upload 报错 “Binary not found” 怎么定位
根本原因不是网络或权限问题，而是 Conan 在本地缓存里压根没找到对应 ID 的二进制包。它不关心你有没有源码、有没有 build 目录，只认 conan search 能列出来的那个完整引用（比如 zlib/1.2.13@user/channel + 配置哈希）。
- 先运行
conan search zlib/1.2.13@user/channel，确认该引用是否在本地存在；如果返回空，说明conan create或conan export-pkg根本没成功执行过 - 如果引用存在，但
conan search zlib/1.2.13@user/channel -r=remote-name显示远程没有，说明上传前漏了--all或没指定正确远程名 - 注意：
conan upload默认只传二进制，不传 recipe；如果 recipe 没先conan upload -r=remote --recipe，后续二进制上传会失败或被拒绝
上传时提示 “Permission denied” 或 “Forbidden”
这不是账号密码输错了，而是远程仓库的写权限没配对。Conan 不会自动把你的登录态映射到所有远程，每个 remote 都要单独授权。
- 运行
conan remote list确认目标 remote 名字（比如artifactory），再用conan user -r artifactory -p your-token登录 - 私有 Artifactory 用户需确保
write_permissions在server.conf或 UI 中已为该用户/组开启，且路径匹配（如user/*@user/channel） - 如果用的是
conan_server（非 Artifactory），检查~/.conan_server/server.conf里的[write_permissions]是否包含你的 user/channel 模式
conan upload 后远程查不到二进制，但命令显示 success
成功只是指文件发出去了，不代表它被正确索引或保存。常见于 profile 不一致导致 ID 计算偏差——你上传的包 ID 和别人 conan install 时计算出的 ID 对不上，等于白传。
- 对比上传方和下游消费方的 profile：运行
conan profile show default，重点核对os、arch、compiler.version、build_type是否完全一致 - 上传时加
--all参数，否则只传当前配置下的二进制；而conan install默认按本地 profile 匹配，ID 差一个字符就找不到 - 避免混用
conanfile.txt和conanfile.py：前者不声明settings，全靠 profile；后者若在settings块里漏写某项（比如没写compiler.libcxx），ID 就会少一截
CI 环境下 upload 失败，但本地能通
CI 容器里缺 profile 或默认 profile 被覆盖是高频原因。Conan 不会自动继承宿主机的 profile，每次 conan profile detect 都依赖容器内实际环境。
- CI 脚本开头必须显式创建或复制 profile：
conan profile new default --detect或从版本库加载conan profile import ci-profile - 确认 CI 使用的 Python 版本与本地一致；Conan 2.x 对 Python 3.8+ 有严格要求，低版本可能静默跳过某些校验
- 不要依赖
conan config install自动同步 settings.yml——它不处理 profile，且若远程 URL 权限不足，会静默失败
真正卡住的地方往往不是 upload 命令本身，而是上传前那个“本地包是否存在且 ID 可复现”的状态。很多人盯着 upload 日志看，却忘了先跑一遍 conan search 和 conan info 确认包的真实身份。
