Conan2 介绍（侦探小说开场 · 面向团队同学）
午夜，CI流水线红灯亮起。
同样一份代码，A同学Windows编译顺利跑通；B同学本地编译报错链接符号缺失；CI服务器CentOS7直接崩溃闪退。
没有改业务代码，没有提交差异，仅仅是第三方库，同一个库，在三台机器上呈现三种完全不同的结局。
线索散落：手动拷贝的lib、本地编译残留产物、系统自带旧版库、ABI不兼容的二进制、层层嵌套的间接依赖。没有人能完整画出依赖关系图，bug随机复现，排查如同一桩无头悬案。
Conan2，就是这桩“C++依赖地狱”案件的侦探。
它是什么
Conan2是面向C/C++的跨平台包管理器，Conan1的重大重构版本，和CMake深度绑定。简单理解：给C++世界的pip/npm，专门侦查、统一管理VTK、OpenCASCADE、opennurbs、HDF5、CGNS这类海量第三方库，终结依赖随机翻车的谜案。
现实中我们遇到过的案件（真实工程示例）
案件1：“我本地好的，你那边崩”
- 案情：Windows开发机手动编译VTK9.2，一切正常；提交CI，CentOS7编译，链接报错一堆未定义符号。同事电脑又能编译。
- 作案原因：每个人本地编译VTK编译选项不一样，静态/动态、C++标准、编译器版本差异，没有统一记录，全靠每个人手工操作记忆。
- Conan2破案：通过profile统一记录编译器、系统、编译选项，所有人、CI服务器使用同一套配置，自动拉取匹配二进制，消除“在我机器能跑”的玄学。
# conanfile.txt极简示例
[requires]
vtk/9.2.6
opencascade/7.7.0
opennurbs/0.0.1
[generators]
CMakeDeps
CMakeToolchain
执行命令：
conan install . --output-folder=build --build=missing
不需要每个人手动编译一遍庞杂的VTK/OCC。
案件2：间接依赖连环爆炸
- 案情：我们引入A库，A库内部依赖zlib；项目本身又直接引入另一个版本zlib。没有任何编译报错，运行时随机崩溃、内存错乱。肉眼看CMakeLists完全看不出冲突。
- 作案原因：C++不会自动校验传递依赖，版本冲突埋藏在二进制深处，属于很难复现的幽灵bug。
- Conan2破案：自动解析完整依赖图谱，检测版本冲突，做版本收敛，清晰打印全部传递依赖，把隐藏线索全部摊开。
案件3：跨平台移植的无尽加班
- 案情：Windows调通全部依赖，迁移到CentOS7，需要逐个下载源码、打补丁、配置编译参数，每个库踩坑几天，交叉编译更是噩梦。
- Conan2破案：一份配置文件，Windows、Linux共用，需要就下载预编译包；没有现成包就自动本地编译，一套配方跑多平台。
案件4：CI构建速度灾难
- 案情：每次CI触发，都完整编译VTK/OCC，一次流水线40分钟以上，改一行代码也要完整重编全部第三方库。
- Conan2破案：二进制缓存机制，编译好的库缓存到本地/私有仓库，CI、开发机直接复用，不再重复编译重型第三方库，流水线时间大幅缩短。
Conan2 真正解决的4类核心问题
- 消除环境玄学：不再靠“手动拷贝库、本地编译备忘录”，依赖版本、编译参数全部文本化记录，代码仓库可追踪，任何人拿到代码，一套命令还原环境。
- 管控传递依赖：把看不见的间接依赖显性化，检测版本冲突，避免运行时随机崩溃。
- 跨平台统一构建：Windows、CentOS、CI服务器一套配置，不用每个平台维护一套编译脚本。
- 提速开发与CI：二进制缓存，避免重复编译VTK/OCC这种重量级库，同时支持搭建私有仓库，存放我们自己打包的内部库。
补充提醒：它和老版本Conan1语法不兼容，生成器全部更换，不再使用旧的
conanbuildinfo.cmake，使用CMakeDeps+CMakeToolchain，原生配合CMake的find_package()。
简单工作流程
- 在项目里写
conanfile.txt/conanfile.py，写明我们需要哪些第三方库； - 执行
conan install，工具自动解析依赖，下载匹配二进制，缺失则编译； - CMake加载Conan生成的工具链文件，直接
find_package()，无需手动写include、lib路径。
