直接#include C头文件会链接失败，因C++编译器对函数名进行name mangling而C不修饰，导致链接器找不到原始符号；解决方法是用extern "C"告知C++编译器按C规则处理符号。
为什么直接 #include C 头文件会链接失败
因为 C++ 编译器对函数名做 name mangling（名字修饰），而 C 编译器不修饰。比如 C 中的 void init() 在 C++ 目标文件里可能变成 _Z4initv，链接器找不到原始的 init 符号，报 undefined reference to 'init'。
解决方法不是改 C 库，而是告诉 C++ 编译器：“这部分函数按 C 的规则处理符号”。核心就是 extern "C" 块。
extern "C" 的两种写法和适用场景
写法一：包裹整个头文件（推荐用于你自己控制的 C 头）
#ifdef __cplusplus
extern "C" {
#endif
void process_data(int* buf, size_t len);
int get_version(void);
ifdef __cplusplus
}
立即学习“C语言免费学习笔记（深入）”；
endif
写法二：在 C++ 源文件中显式声明（适合无法修改的第三方 C 头）
extern "C" {
#include "legacy_c_lib.h" // 确保该头内部没用 extern "C"
}
// 或者只声明需要的函数（更安全）
extern "C" {
int c_calc_sum(const int*, int);
void c_reset_state();
}
- 如果 C 头文件本身已自带
#ifdef __cplusplus保护，直接#include即可 - 如果 C 头里用了 C++ 关键字（如
class、template），必须用写法二 + 显式声明，避免编译错误 -
extern "C"只影响链接符号，不影响调用约定（如__cdecl/__stdcall），Windows 下需额外确认
结构体/联合体/枚举能用 extern "C" 吗
不能。extern "C" 只作用于函数和全局变量，对类型定义无效。C 和 C++ 对结构体的 ABI 兼容性取决于：
- 成员顺序和对齐（用
#pragma pack或alignas统一） - 是否含 C++ 特有内容（如非 POD 成员、构造函数、虚函数）——这类结构体不能跨语言传递
- 字符串字段：C 用
char*，C++ 用std::string，必须显式转换
安全做法是只传 Plain Old Data（POD）结构，例如：
struct Config {
int timeout_ms;
char server_ip[64];
uint8_t enable_ssl;
}; // 这个结构体在 C/C++ 中二进制布局一致动态库加载时的 extern "C" 注意点
用 dlopen/LoadLibrary 手动加载时，extern "C" 依然必要 —— 它确保你声明的函数指针类型与实际符号匹配。
- Linux 下用
dlsym获取函数地址后，必须用extern "C"声明的函数指针类型来 cast，否则调用可能崩溃 - Windows 下若 C 库导出函数未加
__declspec(dllexport)，或 .def 文件未导出 unmangled 名，GetProcAddress会失败 - 检查符号是否存在：Linux 用
nm -D libxxx.so | grep init，看输出是否为init（不是_Z4initv）
常见坑：C 库用 static 修饰函数，导致符号不可见，extern "C" 也救不了。
