conan管理的是带完整构建上下文的二进制包，包含库文件、头文件、cmake配置及依赖快照；conan install默认下载预编译二进制，仅当无匹配settings时才本地构建，确保可复现性。
Conan 管理的不是“源码文件”或“头文件压缩包”，而是带完整构建上下文的 二进制包（binary package）——它封装了编译产物、依赖关系、构建配置和使用元信息，本质是“可复现的构建结果”。
conan install 时到底在拉什么
执行 conan install 时，Conan 默认优先从远程仓库（如 https://center.conan.io）下载预编译好的二进制包，而不是源码。这些包包含：
-
.so/.dll/.dylib和.a/.lib文件（按build_type和shared选项区分） - 头文件目录（
include/），路径已由 Conan 注入到构建系统中 - 构建时所需的
cmake配置模块（如FindXXX.cmake或xxx-config.cmake） - 依赖图快照（
conaninfo.txt或现代 lockfile 中的graph节点）
如果你本地没有匹配当前 settings（如 os=Linux, compiler=gcc, compiler.version=12, build_type=Release）的二进制，Conan 才会触发本地构建（需有对应 conanfile.py 和源码）。
为什么不能只管理头文件或 .a 文件
单纯拷贝头文件或静态库会导致构建不可复现，因为：
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
- 头文件版本和 ABI 兼容性不绑定：比如
nlohmann/jsonv3.11.2 的头文件若搭配旧版std::stringABI 编译，可能在链接期或运行时报错 -
.a文件隐含编译器标志（-fPIC、-std=c++17、-D_GLIBCXX_USE_CXX11_ABI=1），缺失则链接失败或行为异常 - 不同
build_type下宏定义差异大（如BOOST_DISABLE_ASSERTS在 Release 下生效），仅靠文件无法表达
Conan 把这些上下文全部编码进包 ID（如 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9），确保“相同 settings → 相同二进制”。
conanfile.py 里 requires 声明的到底是什么
requires = ["zlib/1.2.13", "openssl/3.0.10"] 声明的不是“任意 zlib 1.2.13”，而是满足当前 settings 和 options 的、经验证可组合的一组二进制包。它实际等价于：
zlib/1.2.13#r12a3b4c@conancenter:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 openssl/3.0.10#v5x6y7z@conancenter:8e9f0d1c2b3a4f5e6d7c8b9a0f1e2d3c4b5a6f7e
其中 #r12a3b4c 是 recipe 的 revision（配方快照），:5ab8...ac9 是该配方在当前配置下生成的二进制包 ID。Conan 依赖这两层唯一性来保证可追溯性和可重现性。
最容易被忽略的是：Conan 不强制你用它的构建逻辑——你可以用 conan export-pkg 把自己已有的 .so + include/ 打包进去，只要提供正确的 conanfile.py 描述其 settings 和 options。它管的从来不是“怎么编”，而是“编出来的这个东西，在什么条件下能被安全复用”。
