应提交conan.lock文件并强制使用，版本化profile，cmakelists.txt中通过cmakedeps/cmaketoolchain集成且禁用系统查找路径。
用 conan lock 文件统一依赖解析结果
团队各自运行 conan install 时，即使 conanfile.txt 相同，也可能因本地 profile、远程仓库顺序、缓存状态不同，导致拉取的二进制 package ID 不一致——比如一个拉到 fmt/10.2.1#r123@_/_:abc123，另一个拉到 fmt/10.2.1#r123@_/_:def456，链接行为或 ABI 就可能出岔子。
根本解法是生成并提交 conan.lock 文件：
- 首次配置后，运行
conan install . --lockfile-out=conan.lock --build=missing，它会把当前解析出的完整依赖树（含每个包的 revision、package ID、settings/options）固化下来 - 把这个
conan.lock提交进 Git，所有成员构建前先执行conan install . --lockfile=conan.lock - CI 流水线也必须强制使用该锁文件，不能跳过；否则“在我机器上能跑”问题立刻复现
- 更新依赖时，不是直接改
conanfile.txt后重装，而是先conan lock update conan.lock，再验证变更影响
profile 必须版本化，不能只靠默认
Conan 的 default profile 是用户级配置，每人本地可随意改——你设了 compiler.cppstd=17，同事没设，conan install 就可能选错二进制。这不是 bug，是设计使然。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
正确做法是把 profile 当成项目资产管：
- 在项目根目录建
profiles/linux-gcc11-release和profiles/win-msvc193-static这类命名清晰的文件，明确写死os、arch、compiler、build_type、compiler.cppstd等关键 settings - CI 脚本里显式传参：
conan install . -pr:h profiles/linux-gcc11-release --lockfile=conan.lock - 禁止在团队中使用未声明的 profile；
conan profile list只用来查本地调试，不用于正式构建
CMakeLists.txt 里不能硬编码 find_package 名称
很多人以为只要 find_package(fmt CONFIG) 就万事大吉，但 Conan 2.x 生成的 fmtConfig.cmake 文件名实际取决于 CMakeDeps 的输出逻辑——如果团队有人误删了 generators 或用了旧版 cmake_find_package，CMake 就会 fallback 到系统路径，找到 /usr/lib/x86_64-linux-gnu/cmake/fmt/fmtConfig.cmake，而它和 Conan 下载的 fmt/10.2.1 完全不是一回事。
安全写法是让 CMake 严格依赖 Conan 输出：
-
conanfile.txt中必须声明[generators]为CMakeDeps和CMakeToolchain -
CMakeLists.txt开头加两行：include(${CMAKE_BINARY_DIR}/conan_toolchain.cmake) include(${CMAKE_BINARY_DIR}/fmt-config.cmake)（注意：文件名由CMakeDeps自动生成，实际名可能是fmt-config.cmake或fmtConfig.cmake，看conan install输出） - 禁用系统查找路径：
set(CMAKE_FIND_PACKAGE_NO_SYSTEM_ENVIRONMENT_PATH ON)，避免意外 fallback
最易被忽略的一点：锁文件和 profile 都是“活”的。它们不是写一次就封存的文档，而是每次 conan install 命令执行时被读取、校验、甚至覆盖的运行时输入。一旦有人绕过它们直接调命令，整套一致性机制就失效了。
