conanfile.py必须放在项目根目录，conan不会向上查找；应与cmakelists.txt同级，版本号须写死如"fmt/10.2.1"，settings需显式声明，且conan install必须纳入构建流程。
conanfile.py 必须放在项目根目录
Conan 不会自动向上查找配置文件，conan install 命令执行时只认当前目录或显式指定路径下的 conanfile.py（或 conanfile.txt）。如果把它放在 deps/ 或 cmake/ 子目录里，CMake 生成阶段就找不到依赖声明，find_package() 会失败。
常见错误现象：运行 conan install . 报错 ERROR: Conanfile not found，或者 CMake 报 Could not find a package configuration file —— 很可能就是 conanfile.py 位置不对。
- 项目结构应为：
./conanfile.py、./CMakeLists.txt、./src/等同级目录 - 不要用相对路径引用外部 conanfile；Conan 不支持
conan install ../shared-deps/conanfile.py这类跨项目复用方式（除非你明确用--file指定，但此时它已不属于“跟项目一起维护”） - 若多个子模块共用一套依赖，应统一收口到根目录的
conanfile.py，而不是每个子目录放一个
CMakeLists.txt 里不能硬编码路径
Conan 生成的 xxx-config.cmake 文件默认输出到构建目录（如 build/），CMake 需通过 CMAKE_PREFIX_PATH 找到它们。一旦你在 CMakeLists.txt 里写死类似 set(CMAKE_PREFIX_PATH "/home/user/project/build")，就破坏了可移植性——别人 clone 后无法直接构建。
正确做法是让 Conan 的 CMakeDeps 和 CMakeToolchain 生成器自动控制路径，并由 conan install 命令决定输出位置。
- 确保
CMakeLists.txt中只写标准调用：find_package(fmt REQUIRED CONFIG) - 不要在 CMake 中手动
list(APPEND CMAKE_PREFIX_PATH ...)指向绝对路径 - 构建时统一用
conan install . --output-folder=build，再cd build && cmake ..，这样 CMake 自动读取 Conan 放在build/下的配置
依赖版本必须写死在 conanfile.py 里
很多人习惯在 conanfile.py 中写 self.requires("fmt/[^10]") 或 "fmt/10.x"，这会导致每次 conan install 解析出不同版本 —— 看似灵活，实则破坏了“配置与项目一起维护”的前提：可复现性。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
工程中真正需要的是确定性，不是动态更新。版本号写死，才意味着 Git 提交的那一刻，整个依赖图就锁定了。
- 写成
"fmt/10.2.1"，而不是"fmt/10.*"或"fmt/[^10]" - 如需升级，应显式修改
conanfile.py并提交，而非靠 CI 自动 bump - 进阶可配合
conan lock create .生成conan.lock文件，但该文件也应纳入 Git —— 它是conanfile.py的精确快照，不是替代品
settings 和 options 要显式声明，别依赖全局配置
Conan 默认 settings（如 os、compiler）来自本地 profile，但 profile 是用户级配置，不随项目走。如果你没在 conanfile.py 里声明 settings，别人换环境（比如从 GCC 切到 Clang）可能因 profile 不一致导致构建失败或链接错误。
同样，default_options 如 "zlib:shared=True" 若只存在 profile 里，Git 上看不到，协作时极易遗漏。
- 在
conanfile.py中明确写出：settings = "os", "compiler", "build_type", "arch" - 对关键行为选项，用
default_options = {"*:shared": False}统一约束，而不是靠命令行传-o zlib:shared=True - 避免使用
conan profile update修改全局 profile 来适配某个项目 —— 那等于把配置藏在了本地磁盘里，不是“跟项目一起维护”
最易被忽略的一点：很多人以为把 conanfile.py 提交到 Git 就算“一起维护”了，但忘了 conan install 命令本身是否被纳入构建流程。CI 脚本里漏掉这一步，或者开发者手动跳过它直接跑 CMake，整个依赖配置就形同虚设。维护不是“有文件”，而是“每次构建都强制走这一步”。
