结论先行

C 语言具有更简单、更稳定且事实标准的应用二进制接口（ABI）。

C 语言的 ABI 简单性极大地促进了跨语言和跨编译器的二进制兼容性，这是实现高度模块化和解耦的关键。

C ABI：实现事实标准

C 语言的 API 仅仅暴露了基本的函数签名（函数名、参数、返回值），不包含任何复杂的语言特性。

没有名称修饰 (Name Mangling)：C 语言不支持函数重载。在编译时，源代码中的函数名（如 my_func）几乎直接转换为二进制符号名（如 _my_func）。这种一对一的映射是标准化的、可预测的，并且在所有主流编译器和平台上都保持一致。
- 模块化优势：不同语言或不同编译器编译的模块可以很容易地通过这些简单的符号名进行链接和调用。

C++ ABI 的复杂性：耦合的根源

相比之下，C++ 为了支持其高级特性，其 ABI 变得极其复杂且非标准化，这直接破坏了模块化和解耦。

🚨 名称修饰的不一致性 (Name Mangling Inconsistency)

多对一映射：C++ 支持函数重载、命名空间、类和模板。为了区分同名但参数不同的函数，编译器必须对函数名进行修饰（即 Name Mangling），将参数类型等信息编码到最终的符号名中。
非标准化：C++ 标准没有规定名称修饰的具体算法。因此，GCC、Clang、MSVC 等不同编译器，甚至同一编译器的不同版本，都会使用不同的名称修饰方案。
- 耦合后果：如果一个库用 GCC 编译，其二进制符号名是 _Z4funcIiEvi；而如果调用者用 MSVC 编译，它查找的符号名可能是 ?func@H@@YAXH@Z。两者不匹配，导致链接失败。这要求库和调用方必须使用相同的编译器和相同的版本，形成了紧密的耦合。

👻 复杂的运行时特性

C++ 的许多核心特性都需要复杂的运行时支持，这些支持必须由 ABI 来规定，但往往不稳定：

C++ 特性	对 ABI 的影响	耦合后果
虚函数	需要定义虚函数表（vtable）的内存布局和访问规则。	vtable 布局在不同编译器或版本中可能不一致，破坏了二进制兼容性。
异常处理	需要复杂的堆栈展开（Stack Unwinding）机制的规范。	异常机制的实现细节在不同 ABI 中差异很大，导致跨模块的异常传播极易出错。
RTTI	需要定义运行时类型信息（RTTI）对象的结构。	同样，结构的差异会导致模块无法正确识别彼此的类型信息。