conan install 是核心命令，必须在含 conanfile.py 或 conanfile.txt 的目录执行，需配置有效远程、匹配 profile 设置，并显式指定生成器（如 -g cmakedeps）才能生成 cmake 可用配置。
conan install 命令是核心入口
直接运行 conan install 就能拉取二进制包，但必须配合 conanfile.py 或 conanfile.txt 声明依赖。它不会自动猜你要什么包，也不会从当前目录“扫描”出依赖。
常见错误现象：执行 conan install . 报错 ERROR: conanfile.py not found，说明项目根目录下缺声明文件；或者报 No remote defined，说明没配置远程仓库。
- 确保当前目录有
conanfile.py（推荐）或conanfile.txt - 运行前先确认远程已就位：
conan remote list应至少显示一个可用远程（如conancenter） - 若远程 URL 过期（比如旧版 Conan 默认用
https://conan.bintray.com），需手动更新：conan remote update conancenter --url="https://center2.conan.io"
依赖声明写法决定能否命中二进制包
Conan 不是“下载源码编译”，而是优先找匹配当前环境的预编译二进制包。能否成功获取，取决于 conanfile 中的依赖写法 + 当前 profile 设置是否与远程已有包的 settings 完全一致。
例如，远程只有 boost/1.85.0 对应 compiler=gcc、compiler.version=11、arch=x86_64 的二进制，而你本地 profile 是 compiler=gcc、compiler.version=9，那就会 fallback 到源码构建（除非加 --build=missing 显式允许）。
-
conanfile.py中用requires = "zlib/1.3.1", "openssl/3.2.1"最稳妥，版本号越精确，越容易命中现成二进制 - 避免写
"zlib/[*]"或"zlib/latest"—— Conan Center 不提供动态版本解析，会直接失败 - 检查 profile 是否匹配：
conan profile show default，重点关注compiler、compiler.version、arch、os
为什么有时 conan install 没报错却没生成库链接信息？
因为 conan install 默认只下载包并解压到本地缓存（~/.conan2/p），不自动生成 CMake 可用的配置。你需要显式指定生成器和输出路径。
典型遗漏：忘了加 -g CMakeDeps -g CMakeToolchain，结果 cmake .. 时 find_package(OpenSSL) 找不到。
- 推荐命令：
conan install . -if build -g CMakeDeps -g CMakeToolchain -s compiler=gcc -s compiler.version=11 -
-if build表示把生成的conan_deps.cmake和conan_toolchain.cmake放进build/目录 - CMakeLists.txt 中必须包含：
include(${CMAKE_BINARY_DIR}/conan_toolchain.cmake)和find_package(YourDep REQUIRED)
遇到 “Package is corrupted” 或 “Cannot find package” 怎么办？
不是网络问题，大概率是本地缓存损坏或远程元数据未同步。Conan 2.x 的缓存校验比旧版更严格，轻微哈希不一致就会拒绝使用。
- 先清空对应包缓存：
conan remove "zlib/*" -c（-c表示 clean，慎用；可加--dry-run预览） - 再重试安装，Conan 会重新从远程拉取完整包
- 如果明确知道远程有该包但始终找不到，检查是否用了带
@user/channel的引用（如zlib/1.3.1@conan/stable）—— Conan 2.x 已废弃 channel，应简化为zlib/1.3.1 - 私有仓库场景下，确认
conan user -r your-remote -p "xxx" your-user已登录，否则 401 错误会被静默吞掉
conan install 看似成功，后续构建却完全不可用。
