undefined reference to 是链接阶段错误，表明目标文件已生成但链接器找不到函数或变量的定义；90%的原因是定义存在却未被链接，如源文件遗漏、库未指定、模板实现未内联或c++调用c函数未加extern "c"。
直接说结论：undefined reference to 是链接阶段错误，不是编译失败，说明目标文件（.o）已经生成，但链接器找不到某个符号（函数/变量）的定义。90% 的情况是“定义存在，但没被链接进去”。
为什么用 g++ 编译 C++ 文件还会报 undefined reference
因为 g++ 只负责把源码转成目标文件，真正决定“哪些定义能被找到”的，是链接器看到的输入列表。常见诱因包括：
- 调用了
foo()，但foo()的实现只写在utils.cpp里，而你只写了g++ main.cpp -o app——utils.cpp根本没参与链接 - 类成员函数声明在头文件，但定义写在
A.cpp里，而你漏编了A.cpp或忘了把它加进构建命令 - 静态成员变量只在类内声明（如
static int count;），但没在类外定义（int A::count = 0;） - 模板函数或类的实现放在了
.cpp文件里，而实例化发生在别的翻译单元（比如main.cpp中用了MyVec<int></int>，但MyVec.cpp没被编译，或没被链接）
g++ 命令里漏掉源文件或库是最常见原因
别依赖“头文件包含”就能自动拉入实现——头文件只提供声明，不提供定义。链接器只认你明确给它的 .o 或 .a/.so。
- 手动编译时，必须列出所有含定义的
.cpp：例如g++ main.cpp utils.cpp network.cpp -o app - 如果用了静态库
libmath.a，得显式加-L. -lmath，且顺序不能错：被依赖的库放右边，即g++ main.o -L. -lmath（不是-lmath main.o） - 动态库同理，
-lstdc++必须出现在命令行靠后位置，否则可能被忽略 - CMake 或 Makefile 里检查
SOURCES或add_executable(...)是否漏掉了某个.cpp
模板代码放 .cpp 里一定会触发这个错误
这不是 bug，是 C++ 模板的实例化机制决定的：编译器需要看到模板的完整定义，才能为具体类型（如 int）生成代码。如果定义在 MyVec.cpp，main.cpp 就看不到，链接时自然找不到 MyVec<int>::push_back</int>。
- 最稳妥做法：模板声明和定义都放在头文件（
.h或.hpp）里 - 若坚持分离，可用显式实例化：在
MyVec.cpp末尾加template class MyVec<int>;</int>，但这只能覆盖你预知的类型，无法支持用户任意实例化 - 注意：内联函数、
constexpr函数、lambda 捕获的函数对象也受同样约束——定义必须对调用者可见
容易被忽略的细节：C 和 C++ 混合链接
如果你在 C++ 代码里调用了 C 写的函数（比如 extern "C" { void c_func(); }），但没加 extern "C" 声明，或者 C 库是用 gcc 编译的，而你用 g++ 链接却没加 -lc，也会报 undefined reference to c_func。
- 确认 C 函数在 C++ 中是否用
extern "C"包裹（头文件里加#ifdef __cplusplus判断） - 检查 C 库是否真被链接：用
nm -C libxxx.a | grep c_func看符号是否存在，且没有 C++ name mangling - 某些系统上
libc不会自动链接，需显式加-lc（虽然通常不用）
真正麻烦的 case 往往藏在构建系统里：Makefile 变量展开为空、CMake 的 target_sources 没生效、IDE 缓存了旧的 .o 文件。遇到诡异的 undefined reference，先 rm *.o *.a *.so 清干净再重试，比对着代码猜半天更省时间。
