根本原因是Conan依赖解析失败：未匹配到满足版本、通道、settings约束的包；远程源未配置（如Conan 2.x默认无远程）；或lock文件过期未更新。
conan install 找不到包，根本原因就这三类
不是网络卡、不是命令输错，而是 Conan 在依赖解析阶段压根没在任何配置的远程源里匹配到满足约束的包。它不会“尽力而为”，而是严格按 requires 中的版本、通道、设置（settings）做精确匹配——缺一不可。
-
conanfile.py里写了"zlib/1.2.13"，但没加@，Conan 默认查conancenter；而该版本在 conancenter 没预编译二进制，又没开--build=missing，就直接报“Package not found” - 用了模糊版本如
"openssl/[^3.0]"，本地缓存或远程索引更新后，解析结果漂移，CI 上某次构建突然失败 - 声明了
settings = "os", "arch", "compiler", "build_type"，但当前环境是os=Windows+compiler=msvc+compiler.version=193，而远程仓库只提供了compiler.version=192的二进制，不兼容就跳过
远程源配置错误：默认不连 conancenter，得手动加
Conan 2.x 默认不启用任何远程源，conan remote list 可能为空。很多人以为装完就能用，结果所有 conan install 都失败——因为根本没有地方可查。
- 必须显式添加：
conan remote add conancenter https://center.conan.io - 国内用户建议加镜像源（如腾讯云或阿里云提供的 conancenter 镜像），否则
conan search响应极慢甚至超时 - 企业私有仓库要配
--force覆盖同名远程，且需提前conan user -r myremote -p token登录认证
依赖声明写法不当：看似简洁，实则埋雷
requires 字段不是自由文本，每个字符都影响解析逻辑。最常踩的坑是省略通道、混用版本语法、忽略构建选项传递。
- 写成
"poco/1.12.4"→ 实际走的是poco/1.12.4@（即默认 channel），但某些旧包（如gtest）必须带@bincrafters/stable才能命中 - 写成
"fmt/10.2.1"没问题，但若下游依赖要求fmt/10.2.1:shared=True，而你没在default_options或命令行传参，链接时可能报 undefined reference - 用
requirements()方法动态加依赖时，忘了调用self.requires("xxx")，而是直接写字符串，Conan 完全无视
缓存与 lock 文件不一致：本地状态已过期
Conan 的 conan.lock 是确定性构建的关键，但它不会自动更新。你改了 conanfile.py，却没重新生成 lock 文件，conan install 仍按旧图谱拉取——可能拉到已下线的旧版本，或跳过新声明的依赖。
- 每次修改
requires或settings后，必须运行：conan lock create . --lockfile-out conan.lock - CI 环境中禁止用
conan install .，必须指定--lockfile=conan.lock，否则失去可复现性 - 怀疑缓存损坏？别急着删整个
~/.conan2，先试conan cache clean "*"清空包缓存，保留配置和远程设置
真正难调试的从来不是“找不到包”，而是“明明有包，却不用”。重点盯住 conan remote list、conan search 的输出、以及 conan install -v 的详细日志里那句 “Trying to resolve X in remote Y”——那里藏着解析器真实看到的世界。
