extern "C" 只能出现在 C++ 代码中，用于包裹 C 函数声明（非定义），不可写入 .c 文件；否则编译器报错“expected identifier or '('”。
多个 .c 文件里怎么写 extern "C" 才不报错
直接说结论：extern "C" 只能出现在 C++ 代码里，且必须包裹 C 函数声明（不是定义），不能写在 .c 文件中。如果你混用 C 和 C++，常见错误是把 extern "C" 错贴到 .c 源文件里，编译器会直接报 error: expected identifier or '('。
典型场景：你有 utils.c（纯 C 实现）和 main.cpp（C++ 主程序），想在 C++ 里调用 C 函数 int add(int a, int b);：
-
utils.c里只写实现：int add(int a, int b) { return a + b; }，**不加任何 extern "C"** -
utils.h里要区分编译环境：#ifdef __cplusplus extern "C" { #endif int add(int a, int b); #ifdef __cplusplus } #endif -
main.cpp包含头文件即可：#include "utils.h"，链接时 clang 自动按 C ABI 解析符号
Clang 编译命令里要不要加 -x c++ 或 -x c
clang 默认根据后缀判断语言类型，.c 当 C，.cpp 当 C++。混编时关键不是加 -x，而是确保链接阶段符号能对上。
常见错误：用 clang main.cpp utils.c 直接编译 —— clang 会把 utils.c 当 C 编译，但 main.cpp 里调用的符号名是 C++ mangling 后的，导致 undefined reference to 'add'。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 正确做法：分步编译，或显式指定链接语言：
clang++ main.cpp utils.c -o prog（用clang++启动链接器，它会自动处理 C 符号） - 如果坚持用
clang，得手动告诉链接器用 C++ runtime：clang main.cpp utils.c -lstdc++ -o prog -
-x c++只在需要强制解释某文件为 C++ 时才用（比如给 .h 文件加语法检查），日常混编不用它
extern "C" 块里能放变量、宏、struct 吗
能放，但意义不同：extern "C" 只影响函数和全局变量的符号链接方式（禁用 name mangling），不影响类型定义。
- 函数声明：必须放，否则 C++ 调用 C 函数会找不到符号
- 全局变量声明：
extern "C" int global_var;是合法的，用于跨语言访问 C 全局变量 -
struct、typedef、#define：放在extern "C"块里**无效且多余**，它们本身不生成符号，也不参与链接 - 常见坑：把整个头文件全包进
extern "C"，结果 struct 里嵌套了 C++ 类型（如std::string），导致 C 文件包含时报错
为什么 Clang 提示 ‘function declared as extern "C" but defined as extern "C++"’
这是声明和定义分离导致的符号不一致，本质是头文件没被所有源文件统一包含，或条件编译没对齐。
- 典型原因：
utils.h里写了extern "C"声明，但utils.c里没包含这个头文件（或包含了但没触发__cplusplus宏），导致定义时用的是 C++ ABI - 检查方法：用
clang -E utils.c | grep add看预处理后是否保留了extern "C"声明 - 根本解法：C 文件永远只包含 C 头文件；C++ 文件包含带
extern "C"包裹的头文件；不要在 .c 里写#ifdef __cplusplus
最易忽略的点：头文件里 extern "C" 的 #ifdef 必须用 __cplusplus，不是 __GNUC__ 或其他宏；而且所有用到该头文件的 C++ 源码，都得确保这个宏在包含前已定义（通常默认满足）。
