conan.lock文件必须提交到git，它是构建快照而非缓存文件，记录依赖的精确版本、修订号、package_id及远程来源，确保ci和协作环境构建结果完全一致；未提交将导致依赖漂移。
conan.lock 文件必须提交到 Git
不提交 conan.lock，就等于没锁定依赖。它不是缓存文件，而是构建快照：记录每个依赖的精确版本、修订号（revision）、package_id、甚至远程来源。CI 拉代码后执行 conan install . 时，Conan 会严格按 lock 文件拉取——哪怕远程仓库里同名包已更新或被删，只要 lock 文件存在，结果就一致。
常见错误是把 conan.lock 加进 .gitignore，或只在本地生成却不提交。后果是：你本地能复现，别人 git clone 后 conan install 出来的二进制可能完全不同，尤其当依赖有多个预编译版本（如 zlib/1.2.13 在 ConanCenter 有 GCC 11/12/13 的不同 package_id）。
profile 必须显式指定，不能依赖 detect
conan profile detect 生成的 profile 是“当前机器快照”，含本地编译器路径、版本、默认 build_type 等。但这些值在不同机器上必然不同——比如 macOS 上 clang 版本、Windows 上 MSVC 工具链路径，都会导致 package_id 变化，进而触发重编译或拉错二进制。
正确做法是：在项目中维护一个明确命名的 profile 文件（如 profiles/linux-gcc-release），内容固定 os=Linux、compiler=gcc、compiler.version=12、compiler.libcxx=libstdc++11、build_type=Release。CI 和协作成员统一用 --profile:build profiles/linux-gcc-release --profile:host profiles/linux-gcc-release。
注意：build_type 是 settings，不是 option，它直接参与 package_id 计算，且无法靠下游“传递”来覆盖——必须从 host profile 里写死。
避免模糊版本声明（如 ~1.2 或 ^1.2.0）
Conan 默认启用 semver 兼容匹配，zlib/1.2.0 可能解析成 zlib/1.2.13，而后者若在不同时间点上传了多个 ABI 变体（比如加了 fPIC=True 新选项），就会让 package_id 漂移。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
真正可复现的写法只有两种：
- 带
@的精确引用：zlib/1.2.13@（走默认 channel） - 全限定引用：
openssl/1.1.1w@conancenter/stable（虽然现在多数已迁至conancenter，但显式写出更稳妥）
绝对不要用 ~ 或 ^，它们在 CI 缓存未命中、远程索引刷新后极易导致构建漂移——你以为在用 1.2.x，实际拉的是 1.3.0 的二进制，且链接时可能 ABI 不兼容。
conan create 打包时必须严格遵循目录约定
自己写 conanfile.py 打包时，如果 package() 方法没把头文件放进 self.cpp.package.includedirs 对应的 include/ 目录，或没把库放进 lib/，下游 find_package() 就会失败。这不是版本问题，是包结构错位。
典型症状：ERROR: Unable to find 'xxx.h' 或 undefined reference to 'xxx::func()'。根本原因不是代码错，而是 package() 里漏了 self.copy("*.h", dst="include", src="include")，或没把 libxxx.a 拷到 lib/ 下。
Conan 的包结构是硬编码约定：include/、lib/、bin/、res/，CMakeDeps 生成器只认这些路径。哪怕你用 exports_sources 把头文件带进缓存，conan create 时没在 package() 里复制进去，下游照样找不到。
