ABI是确保编译后代码可互相调用的底层规则，包含函数调用约定、名称修饰、类内存布局、异常处理和RTTI；C++中因标准未规定ABI，升级时易因成员变量增删、虚函数修改等破坏兼容性，导致程序异常；为保持稳定，应使用Pimpl惯用法、避免改动已有类结构、提供C风格接口并进行兼容性测试，确保库升级时不引发二进制不兼容问题。
C++中的二进制兼容性（ABI，Application Binary Interface）是指不同编译单元之间在二进制层面能否正确交互的能力。简单来说，如果你有一个用旧版本编译的库，另一个程序用新版本的头文件但链接旧版本的二进制库，程序仍能正常运行，就说明具有二进制兼容性。C++标准不规定ABI，因此它由编译器、平台和库实现共同决定。这使得C++库在升级时极易破坏ABI，导致程序崩溃或行为异常。
什么是ABI，它包含哪些内容
ABI是一套底层规则，确保编译后的代码可以互相调用。它包括：
- 函数调用约定：参数如何传递、谁负责清理栈（如cdecl、thiscall）
- 名称修饰（Name Mangling）：C++函数名如何编码成符号名，不同编译器可能不同
- 类内存布局：成员变量顺序、虚函数表（vtable）结构、多重继承处理
- 异常处理机制：异常如何抛出和捕获
- RTTI（运行时类型信息）：dynamic_cast 和 typeid 的实现方式
只要这些规则不变，新旧代码就能安全链接。而C++语言特性（如模板、内联函数）容易在升级时改变这些底层细节，从而破坏ABI。
库升级中常见的ABI破坏行为
即使接口看起来没变，以下修改也会破坏二进制兼容性：
立即学习“C++免费学习笔记（深入）”；
- 在类中添加或删除非静态成员变量：会改变对象大小和内存布局，已有代码访问错位
- 修改虚函数的顺序、数量或签名：破坏vtable结构，导致调用错误函数
- 从普通函数改为内联函数，或反之：影响符号是否存在，链接时可能找不到
- 更改枚举类型的基础类型：如从 int 改为 char，影响传参和存储
- 修改模板实现（即使模板声明不变）：模板代码通常在头文件中，用户代码直接编译，变化直接影响行为
例如，一个已发布的库中类 A 原本有两个 int 成员，客户端代码按此布局创建对象。若新版本加入第三个成员，旧客户端仍按原大小分配内存，就会引发越界访问。
如何保持接口和ABI稳定
为了安全升级库而不破坏现有程序，可采取以下策略：
- 使用Pimpl惯用法（Pointer to Implementation）：将所有数据成员移到Impl类中，主类只保留一个指针。这样内部变更不会影响外部布局
- 避免在已发布类中添加非虚成员函数以外的内容：尤其是成员变量和虚函数
- 虚析构函数必须存在且永不删除：基类没有虚析构是常见陷阱，加上后也不能再移除
- 使用版本号并明确标注ABI变更：如.so.1 到 .so.2 表示不兼容升级
- 提供稳定的C风格接口：C的ABI更简单稳定，可用 extern "C" 包装C++功能
- 测试ABI兼容性：用旧二进制链接新头文件，或工具如 abi-compliance-checker 进行比对
总结
C++库的ABI稳定性比API更难维护，因为很多看似无害的改动都会引发底层结构变化。开发者在设计公共接口时应提前规划扩展性，优先使用Pimpl、避免暴露实现细节，并严格审查每次变更的影响。对于广泛使用的库，保持ABI兼容往往是向后兼容的关键。
基本上就这些。
