extern "C"用于禁用C++名字修饰，使函数按C链接规范处理；必须配合#ifdef __cplusplus守卫，避免C编译器报错，且仅适用于函数声明而非定义或C源文件。
头文件里用 extern "C" 包裹声明，不是定义
静态库本身不决定 C/C++ 兼容性，关键在头文件怎么暴露接口。C++ 编译器默认对函数名做 name mangling，而 C 链接器只认原始符号名。所以必须用 extern "C" 告诉 C++ 编译器：“这部分声明按 C 的规则链接”。
常见错误是把整个头文件直接包在 extern "C" 里，没加 #ifdef __cplusplus 守卫 —— 这会让纯 C 编译器报错，因为 extern "C" 是 C++ 语法。
正确写法是：
#ifdef __cplusplus
extern "C" {
#endif
<p>void my_lib_init(void);
int my_lib_process(const char* data, int len);</p><h1>ifdef __cplusplus</h1><p>}</p><h1>endif</h1><p>这样 C 和 C++ 文件都能安全包含这个头文件。
静态库的源文件用 C 写，别混用 extern "C" 定义
静态库的实现（.c 文件）应该用纯 C 编写，编译时用 gcc（不是 g++），否则可能引入 C++ 运行时依赖，破坏 C 兼容性。
不要在 C 源文件里写 extern "C" —— 它在 C 里非法，且毫无意义。C 编译器天然生成 C 链接符号。
如果非要用 C++ 实现（比如复用模板逻辑），则必须确保：
- 所有对外导出函数用
extern "C"声明（在头文件中已处理） - 函数体内不能调用 C++ 特有特性（如
std::string、异常、RTTI） - 编译时加
-fno-exceptions -fno-rtti，并链接-lc而非-lstdc++
链接时别漏掉 -l 顺序和 -static 语义
用 GCC 链接静态库时，extern "C" 只解决符号名问题，不解决链接路径或顺序问题。常见症状是：undefined reference to 'my_lib_init'，即使头文件和 .a 文件都存在。
原因往往有：
-
-L路径没加对，或-lmylib放在了依赖它的目标文件之前 - 静态库实际是用
g++编译的，内部含 C++ 符号，导致 C 程序链接时报undefined reference to '__cxa_atexit'等 - 用了
-static但没意识到它会强制静态链接所有依赖（包括 libc），可能引发兼容性问题
验证符号是否符合预期：用 nm -C libmylib.a | grep my_lib_init，输出应为 T my_lib_init（不是 T _Z12my_lib_initv）。
跨平台构建时注意 __declspec(dllexport) 不适用
Windows 下 DLL 常用 __declspec(dllexport) 控制符号导出，但这是 Windows 特有机制，GCC/Linux 下无效。静态库（.a）在 Linux/macOS 上不涉及导出声明 —— 所有全局函数默认可链接，只要头文件声明匹配即可。
误加 #ifdef _WIN32 + __declspec 到头文件里，会导致 Linux 下编译失败。保持头文件干净，只用 extern "C" + __cplusplus 守卫就足够。
真正容易被忽略的是：不同架构（x86_64 vs aarch64）或不同 libc 版本（glibc 2.28 vs 2.34）下，静态库虽能链接成功，但运行时可能因 ABI 差异崩溃 —— 这和 extern "C" 无关，但常被误认为是接口问题。
