ABI不兼容的根源在于编译器对符号修饰、类布局、异常处理等实现差异，而非代码错误；不同编译器或版本对STL类型内存布局、虚表排布等细节定义不同，导致跨编译器链接时运行时崩溃或静默错误。
ABI不兼容的根源在编译器对符号和布局的实现差异
ABI（Application Binary Interface）不兼容不是“写法错”，而是不同编译器（或同一编译器不同版本/配置）对同一段C++代码生成的二进制接口不一致。核心在于：函数名修饰（name mangling）、类内存布局、异常处理机制、RTTI结构、虚表排布、调用约定等，都由编译器自行定义，没有跨厂商标准。
比如 g++ 11 和 clang 15 都支持 C++17，但对 std::string 的小字符串优化（SSO）缓冲区大小、std::vector 的内部指针偏移、甚至 std::shared_ptr 的控制块内存布局都可能不同——这些细节一旦暴露在动态库接口中（如返回值、参数、虚函数），就会导致运行时崩溃或静默错误。
链接阶段如何暴露ABI问题？
链接器本身不校验ABI，它只按符号名匹配。问题往往在运行时才爆发：
-
undefined symbol: _ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSt7__cxx1112basic_stringIS4_S5_T1_E—— 这是 GCC 5+ 启用libstdc++新 ABI 后的符号，老版本链接器找不到对应实现 - 动态库 A 用
clang -stdlib=libc++编译，主程序用g++ -stdlib=libstdc++，即使头文件一致，std::string的构造函数地址被解析为不同逻辑，std::string("hello")可能触发 double-free - 虚函数调用跳转到错误偏移：GCC 把虚表第一个条目放 vptr 之后，Clang 放在开头，若基类指针跨编译器传递，
obj->foo()就会 call 错函数
哪些场景最危险？
以下情况只要混用不同编译器或标准库，几乎必然出问题：
