conan install 必须在含 conanfile.txt 或 conanfile.py 的目录执行；依赖声明需固定版本与通道，package() 中须用 self.copy 显式复制头文件和库到约定路径；CMake 需禁用系统 Find 模块并优先使用 Conan 生成的配置。
conan install 命令到底该在哪儿运行
必须在包含 conanfile.txt 或 conanfile.py 的目录下执行，不是项目根目录，也不是 build 目录——是“声明依赖”的那个目录。很多人把文件放在 src/ 里却在项目顶层跑 conan install，结果报错 ConanException: No conanfile.py or conanfile.txt found。
常见场景：你用 CMake 管理构建，习惯把 CMakeLists.txt 和 conanfile.txt 放一起；如果用了 conanfile.py（推荐），它通常和 CMake 配置同级，且需确保 settings 和 requires 块写对。
-
conan install . --build=missing -s build_type=Release：点号表示当前目录有 conanfile - 不要加路径如
conan install ./src，除非你明确把 conanfile 放那儿且 cd 进去了 - 如果用
conan install+--generator cmake_find_package，生成的conanbuildinfo.cmake默认输出到当前目录，CMakeLists.txt 得用include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)，不是源码目录
conanfile.py 里 requires 写法容易漏掉版本约束
写成 requires = "zlib/1.2.13" 看似没问题，但实际会触发远程搜索、可能匹配到预编译二进制不兼容的版本；更糟的是，不加 @user/channel 时 Conan 默认用 conancenter，而某些包（比如旧版 openssl）在 conancenter 里没有预编译包，--build=missing 又没开，就卡住不动。
真正稳妥的写法得兼顾可复现性和构建控制：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 固定版本+通道：
"zlib/1.2.13@", "openssl/1.1.1w@"（注意末尾 @ 表示默认 channel） - 需要特定用户频道时写全：
"gtest/1.14.0@bincrafters/stable"（不过现在多数已迁移到 conancenter） - 避免用
~或^模糊版本，CI 环境下极易因缓存或远程索引变化导致构建漂移 - 如果依赖本身也用 Conan 管理（比如你自己的库），确保它的
exports_sources包含头文件和 CMake 配置，否则conan create后下游找不到find_package()模块
conan create 打包时找不到头文件或链接失败
典型错误是 conan create . user/testing 报 ERROR: Unable to find 'xxx.h' 或 undefined reference to 'xxx::func()'，根本原因不是代码错，而是 package() 方法没把东西拷对位置。
Conan 的包结构是约定死的：include/ 放头文件，lib/ 放静态库，bin/ 放动态库或可执行文件。CMakeLists.txt 里 target_include_directories(xxx PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) 没用——那是源码期路径，打包期得靠 self.copy 显式复制。
- 必须在
package(self)里写：self.copy("*.h", dst="include", src="include") - 静态库要进
lib/：self.copy("*.a", dst="lib", src="build/lib") - 别依赖
exports或exports_sources——它们只影响上传源码，不影响最终安装到本地缓存的二进制包内容 - 用
conan test验证时，测试工程的CMakeLists.txt必须调用find_package(YourLib)，且你的包里得有cmake_find_package生成器支持的 config 文件，否则找不到 target
Windows 下 conan install 后 CMake 找不到 OpenSSL 或 zlib
不是 Conan 没装上，而是 CMake 的 find_package(OpenSSL) 和 Conan 提供的 FindOpenSSL.cmake 冲突了：系统自带的 Find 模块优先级更高，它去注册表或默认路径找，结果找到旧版或空路径，然后报 Could not find OpenSSL，哪怕 conan install 成功输出了 OpenSSL/3.0.13。
解法很直接：关掉 CMake 自己的查找逻辑，完全走 Conan 提供的路径。
- 在 CMakeLists.txt 开头加：
set(CMAKE_MODULE_PATH ${CMAKE_BINARY_DIR} ${CMAKE_MODULE_PATH}) - 确保
conan install用了-g cmake_find_package（或更新的cmake_find_package_multi），它会生成FindOpenSSL.cmake到 build 目录 - 调用
find_package(OpenSSL REQUIRED)前，确认CONAN_LIBS_OPENSSL已被 Conan 注入（可通过message(STATUS "LIBS: ${CONAN_LIBS_OPENSSL}")验证） - MinGW 用户额外注意：
conan install时必须指定-s compiler=gcc -s compiler.version=11 -s compiler.libcxx=libstdc++11，否则默认按 Visual Studio 构建，二进制不兼容
最常被忽略的一点：Conan 缓存里的包是按完整 settings 哈希隔离的，conan install 和 conan create 的 -s 参数必须严格一致，差一个 build_type 或 compiler.runtime，就等于两个世界，链接时符号找不到、头文件路径错乱都是必然结果。
