C++调用Swift时Bridging Header失效报错如何解决？

1. 桥接方案遗漏配置说明 #

你遇到的Undefined symbol: sayHello()错误核心原因是C++的名字修饰（Name Mangling）机制：C语言编译全局函数时不会修改函数名，而C为了支持函数重载，会给函数名加上参数、返回值相关的修饰后缀。你在Swift里用@_cdecl("sayHello")导出的是C ABI的纯C函数名，C侧直接引用时会按C++的规则找修饰后的函数名，自然找不到。

你只需要修改桥接头文件CToSwift-Bridging-Header.h里的sayHello声明，给它加extern "C"包裹，告诉C++编译器这个函数用C的ABI规则寻址即可：

// CToSwift-Bridging-Header.h
void callCpp();

#ifdef __cplusplus
extern "C" {
#endif
extern void sayHello();
#ifdef __cplusplus
}
#endif

如果你的桥接头只会被C引用，也可以直接写成extern "C" void sayHello();，加条件判断是为了兼容C和C两种编译环境。修改完重新编译即可正常调用。

2. 其他C++调用Swift的可行方案 #

• 间接封装层方案：先把需要调用的Swift逻辑全部用@_cdecl导出为C函数，再用一个纯C的封装层对外提供接口，C++侧直接调用这个C封装层的接口即可，逻辑清晰，兼容性最好，适合跨语言调用场景不复杂的项目。
• Objective-C++ 中间层方案：如果是苹果生态的项目，可以把C代码改成.mm后缀的Objective-C代码，Objective-C可以同时兼容C语法和Objective-C语法，而Swift可以直接和Objective-C互操作，相当于通过Objective-C++作为中间层中转调用，适合需要调用大量Swift接口、参数类型复杂的场景。
• 独立服务调用：如果是跨进程场景，可以把Swift逻辑封装成XPC服务（苹果生态）或者独立的HTTP/本地Socket服务，C++侧通过进程间通信调用，耦合度最低，适合两个模块独立性要求高的场景。

3. Swift作为库引入的可行性 #

完全可以，苹果生态下可以把Swift代码编译成静态库或者动态库（.framework/.tbd，Windows平台也支持编译成dll）：

• 编译Swift代码时，选择生成库目标，把所有需要对外暴露的C接口都统一放到一个公开的头文件里，注意所有对外的C接口都要用extern "C"修饰保证C++可以识别。
• 编译C++代码时，把Swift生成的库加入链接依赖，把公开头文件加入头文件搜索路径，即可像调用普通系统库一样调用Swift导出的接口。
• 注意需要保证Swift库和C++代码的架构、部署目标版本完全一致，避免出现链接或者运行时错误。

内容的提问来源于stack exchange，提问作者Gowtham naveen