答案是C++编译器默认进行名字修饰而C不修饰，导致链接时符号名不匹配。1. C++将foo修饰为_Z3foov等，C保留foo；2. 链接器找不到对应符号，报undefined reference；3. 必须用extern "C"包裹#include或声明以禁用修饰；4. 对无__cplusplus保护的C头文件需手动加extern "C"包裹；5. 还需注意库路径、链接顺序及运行时契约问题。
为什么C++直接#include C头文件会链接失败
C++编译器默认对函数名做名称修饰（name mangling），比如把 foo 编译成 _Z3foov 这类符号；而C编译器生成的是未修饰的 foo。链接时找不到对应符号，就会报 undefined reference to 'foo'。
常见错误现象：
- 编译通过，但链接时报
undefined reference - 头文件里声明了函数，
g++却说“找不到定义”
解决方法只有一条：告诉C++编译器“这部分是C代码，别修饰名字”：
extern "C" {
#include "my_c_lib.h"
}
注意：必须用 extern "C" 包住 #include，不能只包函数声明——因为头文件里可能有宏、typedef、结构体等，它们本身不参与链接，但函数声明必须被正确标记。
立即学习“C语言免费学习笔记（深入）”；
如何处理C库的头文件本身没加extern "C"保护
很多C库（尤其是系统级或老项目）的头文件只面向C设计，里面没有 #ifdef __cplusplus 判断。你不能改它源码，就得自己兜底：
#ifdef __cplusplus
extern "C" {
#endif
<h1>include "legacy_c_header.h"</h1><h1>ifdef __cplusplus</h1><p>}</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/gongju/2823" title="C++14">C++14</a>
<p>C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><h1>endif</h1>这样写更安全，尤其当该头文件被其他C++文件多次包含时，避免重复打开/关闭 extern "C" 块。
另外注意：
-
extern "C"只影响函数和变量的链接约定，不影响类型定义（struct/class）、宏、内联函数 - 如果C头文件里有
static inline函数，C++里也能用，但本质是每个翻译单元一份副本，不涉及链接
链接时要同时指定C库和依赖的系统库
C++调用C库 ≠ 只加一个 -l 就完事。常见疏漏：
- 忘记传C库的路径：
-L/path/to/c/lib - 库名写错：比如库文件是
libmathutils.a，得用-lmathutils（去掉lib前缀和后缀） - 依赖顺序错误：C++目标文件在前，C库在后，否则链接器可能忽略未解析符号
正确写法：g++ main.cpp -L. -lmy_c_lib -o app - 缺少C库依赖的系统库：比如C库内部用了
pthread或m，得补上-lpthread -lm
可以用 nm -D libmy_c_lib.so | grep my_func 确认符号是否存在且未被strip。
混合编译时要注意调用约定和内存管理边界
C++调用C函数看似简单，但实际容易出问题的点在运行时：
- C函数返回的指针（比如
char*）由谁释放？C库用malloc分配，C++端不能用delete，得用free - C库如果接收函数指针回调，传入的lambda或成员函数地址会崩溃——C不认C++的调用约定，必须用普通函数或
static成员函数 - 结构体字段对齐：C库头文件若没显式加
<strong>attribute</strong>((packed))，而C++代码用了#pragma pack，可能导致内存布局不一致
最稳妥的做法：所有跨语言边界的内存分配/释放、回调注册、结构体传递，都在C层封装一层薄接口，明确约定所有权和生命周期。
C和C++混用不是编译问题，而是契约问题——两边对“怎么传、谁管、何时清”得有一致理解。这点比 extern "C" 更容易被忽略。
