conan package_id是依赖与配置共同生成的兼容性签名，用于判断二进制是否可复用；它由settings、options和requires计算得出，但默认不包含compiler.libcxx等关键ABI字段，需在package_id()中显式设为"ANY"或剔除无关项，且无法检测头文件或符号级ABI变化。
conan package_id 是什么，它怎么决定二进制是否复用
它不是包的唯一哈希，而是由你声明的依赖+配置共同算出的一个“兼容性签名”。conan create 时，Conan 会根据 settings（如 os, compiler.version）、options（如 shared=True）和 requires（依赖的 package ID）生成一个 package_id。只要这些输入没变，Conan 就认为二进制可复用。
容易踩的坑：
- 默认情况下，
self.info.settings.compiler.libcxx不参与计算——但如果你的库实际链接了libstdc++或libc++，不加这条会导致 Linux 下 GCC 和 Clang 编译出的包被当成同一个 ID，运行时报符号缺失或 ABI 崩溃 -
options中未显式声明的字段（比如你写了options = {"shared": [True, False]}，但没写"fPIC"），默认会被忽略——即使 CMakeLists.txt 里用了fPIC，也不会触发重编译
如何自定义 package_id 让它真正反映 ABI 变化
在 conanfile.py 的 package_id() 方法里手动控制哪些东西该影响 ID。这是最常被跳过的一步，也是二进制错乱的根源。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 强制让
compiler.libcxx生效：def package_id(self): self.info.settings.compiler.libcxx = "ANY" - 把影响 ABI 的自定义选项全标为
"ANY"：self.info.options.my_option = "ANY" - 如果某个 option 实际不影响 ABI（比如只控制日志级别），可以剔除：
del self.info.options.verbose - 跨平台时注意：Windows 下
compiler.runtime必须参与计算，否则MT和MD混用会崩溃
conan install 时提示 “Package not found” 却明明 build 过，怎么回事
不是服务器没同步，大概率是本地缓存里的 package_id 和当前环境算出的不一致。常见原因有：
- 升级了 Conan 版本（v1.x 到 v2.x），
package_id算法变了，旧包 ID 失效 - 本地
conan.conf改过default_profile，导致settings默认值不同 - CI 脚本里漏了
--profile，用了系统默认 profile（比如带compiler.version=12），而本地开发用的是11 - 你在
package_id()里删了某个 option，但之前 build 的包还带着旧 ID，新 install 就找不到
查证方法：运行 conan info . --package-filter="*" -pr=myprofile，看输出的 ID 字段是否和 conan search 列出来的匹配。
C++ ABI 兼容性不能只靠 conan package_id
package_id 是静态规则，它不检查头文件变化、内联函数修改、模板实例化差异这些真实影响 ABI 的东西。比如：
- 你改了一个
inline函数体，package_id不变，但调用方可能拿到旧实现 - 头文件里新增了一个
constexpr变量，被下游#include后直接展开，此时换二进制包毫无意义 - 使用
CONAN_EXPORTED宏导出类时，虚表布局稍有变动，package_id完全无感知
所以，哪怕 package_id 一致，只要头文件或导出符号有变更，就该 bump version 或至少清掉旧包重新 conan create。这点很容易被当成“conan 已经管好了”而忽略。
