extern "c"的唯一作用是禁用c++名称修饰，使函数符号名与c一致以确保正确链接；必须用#ifdef __cplusplus条件包裹头文件中的extern "c"块，否则c编译器报错，且需配合c兼容类型和visibility属性才能实现真正的跨语言调用。
extern "C" 必须加在头文件里，且只对 C++ 编译器生效
如果你在写一个供 C 和 C++ 项目共同使用的动态库头文件，extern "C" 不是可选的装饰，而是链接层的必需声明。它告诉 C++ 编译器：这部分函数名不要做 name mangling，保持 C 风格的符号名（比如 init_config 就是 init_config，而不是 _Z12init_configv）。但注意：extern "C" 对 C 编译器无效——C 标准根本不认识这个语法，所以必须用预处理器条件包裹。
- 错误写法：
extern "C" { void foo(); }直接放在 .h 里 → C 编译器报错error: expected identifier or '(' before string literal - 正确写法：用
#ifdef __cplusplus包裹，确保 C 编译器跳过extern "C" - 常见疏漏：只在 .cpp 实现文件里加
extern "C"→ 头文件暴露的声明仍被 C++ mangling，C 端链接时找不到符号
动态库导出函数必须同时满足 C linkage 和可见性规则
仅加 extern "C" 不足以让函数被外部 C 程序调用。GCC 默认编译的 shared library 中，函数符号默认是全局可见的，但若用了 -fvisibility=hidden（推荐做法），就必须显式标记导出。
- C++ 实现文件中，函数定义前要加
extern "C"，且需配合 visibility 属性：extern "C" __attribute__((visibility("default"))) int load_config(const char* path); - 更稳妥的做法是在头文件中统一定义宏：
#define EXPORT_API extern "C" __attribute__((visibility("default")))，然后声明为EXPORT_API int load_config(const char* path); - 不加
visibility("default")时，即使nm -D libxxx.so看不到该符号，C 端dlsym会返回NULL，错误信息是undefined symbol: load_config
头文件里不能混用 C++ 类型，否则 C 端无法解析
extern "C" 只解决符号名问题，不解决类型兼容。C 编译器不认识 std::string、引用、重载、模板等任何 C++ 特性。
- 错误示例：
extern "C" { void log_message(std::string msg); }→ C 文件包含此头文件直接编译失败 - 正确做法：参数和返回值必须是 C 兼容类型——基本类型、
struct（不含成员函数/虚表）、const char*、指针；如需传递字符串，用const char*或带长度的const uint8_t* - 结构体若含 C++ 成员（如
std::vector<int></int>），必须拆成纯 C 结构 + 独立操作函数，例如：typedef struct { int* data; size_t len; } IntArray;，再配extern "C" IntArray* make_int_array(size_t n);
验证是否真正兼容：用 nm 和 objdump 看符号，用 C 程序实测 dlsym
别信“编译过了就 OK”。很多问题只在链接或运行时暴露。
- 检查符号：编译后执行
nm -D libmylib.so | grep init_config，应看到T init_config（不是U或带下划线前缀/后缀的乱码） - 检查 ABI：用
objdump -t libmylib.so | grep init_config，确认 type 是FUNC且 binding 是GLOBAL - 最硬核验证：写一个极简 C 文件，
#include <dlfcn.h></dlfcn.h>，void* h = dlopen("./libmylib.so", RTLD_LAZY);，void (*f)() = dlsym(h, "init_config");，运行看是否 segfault 或f为NULL
最容易被忽略的是：C++ 实现里调用了 STL 或其他 C++ 运行时函数（比如 std::cout），会导致 C 程序加载时因缺失 libstdc++.so 而失败——哪怕头文件完全 C 兼容，动态库本身也依赖 C++ ABI。
