recipe 是 conan 包构建逻辑的唯一定义，即 conanfile.py 中可执行的 python 脚本，通过 source()、build()、package()、package_info() 精确控制源码获取、编译、打包及消费接口声明，同一 recipe 配合不同 profile 可生成多平台二进制包。
recipe 是 Conan 包构建逻辑的唯一定义，它不决定“用什么库”，而是决定“怎么编出那个库”。
recipe 就是 conanfile.py 里的那套 Python 逻辑
它不是配置文件，也不是元数据清单，而是一个可执行的构建脚本。Conan 客户端会实例化你写的 ConanFile 子类，依次调用 source()、build()、package() 等方法——每一步都由你控制。
-
source()决定从哪拉代码（git clone / download / copy from local） -
build()决定用什么命令编译（self.run("make")或cmake.configure()） -
package()决定把哪些文件打进包（头文件、.a/.so、.dll、cmake 配置等） -
package_info()不参与构建，但决定别人怎么用你的包（self.cpp_info.libs、self.cpp_info.includedirs等必须写对）
同一个 recipe 可能生成多个 binary package
recipe 本身不绑定平台或 ABI，它只是“菜谱”。真正产出二进制包的是 conan create 或 conan build 命令配合 profile 运行的结果。比如：
- 用
profile=linux-gcc-x86_64构建 → 得到一个 Linux x86_64 的pkg/1.0@user/stable二进制包 - 换
profile=armv8-clang再跑一次 → 得到另一个 ARM64 的二进制包，但 recipe 没改一行 - 这两个包共享同一个 recipe reference：
pkg/1.0@user/stable，但 Package ID 不同
如果你漏写 settings = "os", "arch", "compiler", "build_type"，Conan 就无法区分它们，后续 install 时可能拿错二进制。
recipe 错误最常导致链接失败或头文件找不到
这不是安装失败，而是使用者在集成时才发现的问题。典型现象包括：
-
undefined reference to 'xxx'→self.cpp_info.libs没填，或填错大小写（MyLib≠mylib） -
fatal error: mylib/myheader.h: No such file or directory→self.cpp_info.includedirs指向了错误路径，或package()没把头文件 copy 进去 - 动态库运行时报
libxxx.so: cannot open shared object file→ 忘了设self.cpp_info.bindirs或没把 .so 放进package()目标目录 - 交叉编译时链接了 host 侧的 libc →
profile里sysroot和 recipe 中的build()步骤没对齐
recipe 的复杂点不在语法，而在它必须精确反映真实构建过程：你手动用 Makefile 编出来的库路径、符号导出方式、依赖传递行为，都得在 package_info() 里如实声明。少一个 self.cpp_info.defines，下游就可能因为宏开关不一致而行为异常——这种问题往往要追进汇编层才能定位。
