conan create生成的包默认仅存于本地缓存（~/.conan2/p/），其他项目无法直接发现，需通过上传远程、conan link或统一user/channel等方式实现复用，且须严格匹配settings与options。
conan create 生成的包默认只在本地缓存，不自动共享
执行 conan create . 后，包会存进本地缓存（~/.conan2/p/ 下按 hash 组织），其他项目 conan install 时查不到它——除非显式配置了远程或启用了本地缓存共享机制。
- Conan v2 默认关闭“本地可发现性”，即：一个项目
conan create出来的包，对另一个项目是不可见的，哪怕在同一台机器 - 这不是 bug，是设计：避免污染全局命名空间，强制依赖声明显式化
- 常见误操作：在项目 A 里
conan create后，直接切到项目 B 运行conan install，结果报错ERROR: Unable to find 'mylib/0.1' in remotes
让内部项目复用的三种可行路径
选哪条取决于团队规模、CI 流程和是否已有私有仓库：
-
轻量协作（2–5人小团队）：用
conan upload推到私有远程（如 Artifactory、Nexus 或简易conan_server），再在其他项目conan remote add并conan install -
无远程但需跨项目引用：启用
conan link（仅限开发阶段），例如在包源码目录运行conan link . mylib/0.1@，之后其他项目就能通过requires = "mylib/0.1@"引用——注意@后不能带user/channel，否则会去远程查 -
CI/CD 集成场景：在构建流水线中固定使用
--user=ci --channel=stable，然后所有项目统一写requires = "mylib/0.1@ci/stable"；配合conan upload mylib/0.1@ci/stable -r=myremote实现版本可控分发
CMakeLists.txt 里别硬编码路径，靠 Conan 自动注入
很多人想把 conan create 输出的头文件或库路径手动写进 CMakeLists.txt，这是反模式。Conan 的价值恰恰在于解耦——你只要确保：
- 消费项目中
conan install成功生成了generators/下的CMakeDeps.cmake和CMakeToolchain.cmake -
CMakeLists.txt中调用find_package(mylib CONFIG REQUIRED)，而不是include_directories(...)或link_directories(...) - 确认
conanfile.py的package_info()正确设置了self.cpp_info.libs和self.cpp_info.includedirs，否则find_package找不到符号
容易被忽略的版本与选项一致性
内部包复用失败，80% 出在 settings 或 options 不匹配。比如你在 A 项目用 conan create . -s build_type=Debug 打的包，在 B 项目 conan install 时没加 -s build_type=Debug，Conan 就会认为这是两个不同包，拒绝复用。
- 检查方式：运行
conan list "mylib/*" --graph=graph.html可视化依赖图，看实际解析出的二进制 hash 是否一致 - 推荐做法：所有内部项目统一使用 profile（如
conan profile new internal --detect && conan profile update settings.build_type=Release internal），安装时指定--profile=internal - 特别注意
shared选项：mylib/0.1@user/channel:shared=True和:shared=False是完全不同的二进制，必须显式对齐
