conan通过os、arch、compiler等维度固化abi上下文，compiler.libcxx和compiler.version直接影响c++ abi兼容性；它确保链接一致性但不解决跨so的c++类型传递、虚表布局或头文件泄露abi细节问题；需结合abidiff验证符号层abi变更，并依赖pimpl或extern "c"实现真正隔离。
Conan包的二进制标识里藏着ABI信息
Conan不把“一个库”当成抽象概念，而是按os、arch、compiler、compiler.version、compiler.libcxx、build_type等维度生成唯一二进制包ID。其中compiler.libcxx（如libstdc++11 vs libstdc++）和compiler.version（如gcc 11 vs gcc 12）直接对应C++ ABI关键变量——比如GCC 5+默认启用新_GLIBCXX_USE_CXX11_ABI=1，而旧版GCC或Clang可能用旧ABI，std::string内存布局就不同。
这意味着：Conan不是“帮你装对版本”，而是强制你声明并固化ABI上下文。一旦compiler.libcxx写错，Conan可能拉来一个符号能链接但运行时析构崩溃的std::vector。
动态链接场景下，Conan不替你解决ABI跨模块传递问题
Conan能确保你链接的libfoo.so和你的主程序用同一套libstdc++和编译器版本，但它**不管你在代码里怎么用C++类型跨so边界**。典型踩坑点：
- 在共享库导出函数中直接返回
std::string或接收std::shared_ptr<t></t>参数——即使Conan保证了两边都用gcc 12.3 libstdc++11，只要其中一方升级了标准库补丁（如glibcxx内部字段微调），仍可能因RTTI或控制块布局变化而崩溃 - 头文件里定义了含虚函数的类，并在多个Conan包之间继承——虚表偏移、vptr位置这些ABI细节，Conan不校验也不约束，只依赖你手动保持类定义完全一致
- 用了
conan install --build=missing，但本地CMakeLists.txt里漏写了set(CMAKE_CXX_STANDARD 17)——Conan按配置选包，但CMake实际编译时可能降级到C++14，触发ABI隐式变更
abidiff + Conan profile是验证ABI兼容性的最小可行组合
Conan本身不带ABI检查能力，但可以和abidiff（来自libabigail）配合做回归验证：
你需要：
- 用相同
conan profile构建两个版本的库（如v1.2.0和v1.2.1） - 提取各自的
.so文件，运行abidiff old.so new.so - 重点关注输出里的
Changed type、Removed function、Size of type changed——这些直接对应ABI破坏点 - 把
abidiff结果集成进CI，在conan create后自动执行，避免人肉核对
注意：abidiff只能检测符号层变化，对inline函数修改、模板实例化差异或constexpr行为变更无能为力——这些仍需靠统一工具链和禁用不稳定的ABI特性（如-fno-rtti）来规避。
Conan的requires和visible不解决C++ ABI隔离
Conan的requires声明只控制链接时依赖，package_info()里的cpp_info.includedirs和cpp_info.libdirs只影响编译路径。它**无法阻止头文件把不稳定的C++ ABI细节泄露出去**。例如：
你的Conan包A依赖包B，B的头文件里有：
class Widget {
public:
virtual void render() = 0;
private:
std::vector<int> m_cache; // 这个成员顺序/对齐方式随ABI变
};</int>
哪怕Conan确保A和B用同一套compiler.libcxx，只要B更新了内部实现（比如把m_cache挪到前面），A重新编译时就会拿到新布局，但若A的二进制已发布，旧A加载新B的so，dynamic_cast或虚函数调用就可能跳错地址。
真正可控的做法只有两种：要么用Pimpl彻底隐藏实现，要么导出纯extern "C"函数——Conan能帮你分发这两者的二进制，但不能替你做这个设计决策。
