conanfile.txt 或 conanfile.py 是 Conan 依赖声明的唯一源头，其他如 conanbuildinfo.cmake 或 xxxConfig.cmake 均为自动生成的中间产物；删除后者可重生成，删除前者则流程直接失败。
直接看 conanfile.txt 或 conanfile.py，其他都是衍生物——没这两个文件，Conan 就不知道你依赖什么、怎么构建。
为什么不是 conanbuildinfo.cmake 或 xxxConfig.cmake？
这些是 conan install 运行后自动生成的中间产物，不是源声明。删掉它们再跑一遍 conan install 就能重新生成；但删了 conanfile.txt 或 conanfile.py，整个流程就卡在第一步。
常见误操作：在 CI 脚本里只上传 conanbuildinfo.cmake，却漏传 conanfile.py，结果构建失败报 No conanfile.py or conanfile.txt found。
conanfile.txt 和 conanfile.py 该怎么选？
conanfile.txt 适合简单项目，纯声明式，结构清晰：
- [requires] 列出库名/版本，如
fmt/10.2.1、zlib/1.2.13@（注意末尾@表示默认 channel） - [generators] 指定输出格式，
CMakeDeps和CMakeToolchain是 Conan 2.x 推荐组合 - 不支持条件逻辑、动态配置或自定义构建步骤
conanfile.py 是完整 Python 脚本，适合需要控制细节的场景：
- 可在
requirements()方法里写 if/else 判断平台或选项 - 用
package()显式调用self.copy("*.h", dst="include")控制头文件路径 - 能覆盖
configure()、build()等钩子，适配 Makefile 或自定义构建流程
conan.lock 是必须关注的“隐藏主角”
它不参与初始声明，但一旦出现，就说明项目已进入可复现构建阶段：
- 首次运行
conan install后自动生成，记录每个依赖的精确revision和package_id - CI 中应提交
conan.lock，否则不同机器可能拉到不同二进制（尤其当远程有多个预编译版本时） - 执行
conan install --lockfile=conan.lock才能真正锁定全部依赖状态；只靠conanfile.py里的版本号不够
容易被忽略的一点：conan.lock 会随 settings（比如 compiler.version）变化而变化——同一份 conanfile.py，在 GCC 11 和 Clang 16 下生成的 lock 文件完全不同。
