conan list --graph=conan.lock可准确查项目已安装包，它解析锁文件输出完整依赖图；conan install --dry-run则用于预览修改conanfile后将安装的包，二者均基于项目上下文而非本地缓存。
conan list 命令查当前项目已安装的包
直接运行 conan list * 会在当前 conan 缓存中列出所有已下载的包，但这不是“项目用了哪些”，而是“本地缓存里有什么”。真正对应项目的依赖树，得从项目锁文件或安装上下文出发。
正确做法是：确保你已在含 conanfile.txt 或 conanfile.py 的目录下执行过 conan install，然后用以下命令：
-
conan list --graph=conan.lock：解析conan.lock文件，输出完整依赖图（含传递依赖） -
conan list "mylib/*" --graph=conan.lock：只过滤出某一级依赖及其子树 -
conan list --graph=conan.lock --format=json：输出 JSON，适合脚本解析
注意：conan.lock 必须存在且是最新的——如果改过 conanfile 但没重跑 conan install，结果会过期。
conan install --dry-run 看本次会拉什么包
当你改了 conanfile.txt 还没真正安装时，--dry-run 是最轻量的预览方式。它不下载、不构建，只做依赖解析和版本匹配：
-
conan install . --dry-run --build=missing：显示所有将被安装（或构建）的包名+版本+二进制 ID - 输出中带
[binary] Download表示走远程二进制；带[binary] Build表示要本地编译 - 若看到大量
[binary] Missing，说明 profile 设置（如compiler.version）和远程可用二进制不匹配
这个命令不会生成 conan.lock，也不写入 generators/，纯只读检查。
为什么 conan search 不适用于查项目依赖
conan search 是查远程或本地缓存里“有哪些包可选”，不是查“我的项目用了哪些”。常见误用：
-
conan search fmt*→ 返回所有名字含 fmt 的包（比如fmt/10.2.1,fmt/11.0.0,fmt-test/1.0），和你项目无关 -
conan search -r=center fmt/10.2.1→ 只确认该版本是否存在，不反映是否被当前项目引用
真正属于项目的包，必须通过 conan.lock 或 conan install --dry-run 推导——因为 Conan 的依赖解析是 context-sensitive 的：同一 conanfile 在不同 profile 下可能解析出完全不同的二进制组合。
CMakeLists.txt 里 find_package 跟实际依赖对不上怎么办
这是高频陷阱：CMake 找到的库，未必是你通过 Conan 安装的那个。典型原因有：
- CMake 优先找到了系统自带的
/usr/include/fmt，而不是 Conan 下载的~/.conan2/p/b/fmt/... -
find_package(fmt CONFIG REQUIRED)没加CONFIG，导致 fallback 到 CMake 自带的 Findfmt.cmake（可能版本错、路径错） -
CMAKE_PREFIX_PATH没指向 Conan 生成的generators/目录，或者include()了错误的 toolchain 路径
验证方法：在 CMake 配置阶段加一句 message(STATUS "fmt_DIR = ${fmt_DIR}")，看它指向的是 Conan 生成的 fmt-config.cmake，还是系统路径。如果不是前者，说明 CMakeDeps 没生效或 conan install 没成功生成配置。
