最常用、最稳妥的方式是conan export-pkg + conan upload：先用export-pkg跳过构建、直接打包本地预编译的头文件和库文件（需显式copy并声明完整settings），再用upload上传，支持按revision精确推送或强制覆盖。
直接上传预编译二进制包最常用、最稳妥的方式是 conan export-pkg + conan upload，而不是用 conan create——后者会强制走构建流程，对已有 .a/.lib/.so 文件反而多余且易出错。
用 conan export-pkg 打包本地二进制文件
当你手头已有编译好的头文件、库文件（比如 include/ 和 lib/libfoo.a），不需要再编译源码时，必须跳过 conan create。核心是写一个轻量 conanfile.py，只声明包结构和二进制路径：
-
self.copy("*.h", dst="include", src="my_headers")—— 显式指定头文件来源 -
self.copy("*.a", dst="lib", src="prebuilt/lib")—— 不依赖 build() 方法，直接拷贝 - 必须设置
settings = "os", "arch", "compiler", "build_type"，否则export-pkg会报错“missing settings” - 运行命令：
conan export-pkg . foo/1.2.3@user/channel -s os=Linux -s arch=x86_64 -s compiler=gcc -s compiler.version=11 -s compiler.libcxx=libstdc++11
conan upload 的三种常见模式与陷阱
上传不是简单执行一次命令就完事，不同场景要选对参数组合，否则远程仓库收不到完整信息或版本混乱：
- 只传最新 recipe revision + 对应二进制：
conan upload foo/1.2.3@user/channel -r=myremote—— 默认行为，安全但不覆盖旧 revision - 传所有 recipe revisions（含历史）：
conan upload foo/1.2.3@user/channel#* -r=myremote—— 注意#*是通配符，不是注释 - 强制上传所有二进制（即使已存在）：
conan upload foo/1.2.3@user/channel --force -r=myremote—— 谨慎使用，可能破坏 lockfile 一致性 - 常见错误：
ERROR: Recipe 'foo/1.2.3@user/channel' not found—— 说明export-pkg没成功，先检查本地缓存：conan list foo/1.2.3@user/channel
远程仓库配置与认证失败的典型表现
上传失败往往卡在认证或 URL 配置上，而非 Conan 命令本身：
-
conan remote list必须显示你的 remote 名称（如myremote），且状态为ENABLED - 如果 remote URL 是私有 Artifactory，确保已执行：
conan user -p "mypassword" -r myremote myusername；密码含特殊字符必须加双引号 - ConanCenter 已切换为
https://center2.conan.io（2026年6月起），旧配置会导致403 Forbidden或重定向失败 - 上传后查不到包？用
conan list "foo/*" -r=myremote验证，不是conan search（该命令在 Conan 2.x 中已弃用）
真正容易被忽略的是：每次 export-pkg 都会生成新的 recipe revision（哪怕内容没变），而 upload 默认只推最新 revision。如果你依赖 lockfile 复现构建，就得确认远程是否保留了对应 revision——否则 CI 上 conan install 会拉不到匹配的二进制。
