这不是编译错误，是链接器找不到符号定义，问题出在“有声明、没实现”或“实现了、但没进链接流程”；常见原因包括函数未定义、定义不匹配、静态成员未在类外定义、C/C++混用未加extern "C"、源文件未参与编译、库链接顺序错误、模板定义未放头文件等。
直接说结论：这不是编译错误，是链接器找不到符号定义，问题一定出在“有声明、没实现”或“实现了、但没进链接流程”这两类地方。
函数声明了但没写定义，或者定义不匹配
最常见的是头文件里写了 void log_error(const std::string& msg);，但所有 .cpp 文件里都没出现这个函数的实现；或者写了实现，但参数类型/顺序/const 修饰不一致，比如写成了 void log_error(std::string msg) —— 这会导致生成的符号名不同，链接器认为是两个函数。
- 用
nm -C your_file.o | grep log_error看目标文件里有没有对应符号（-C表示 demangle，可读） - 检查声明和定义的拼写、命名空间、
const、引用类型是否完全一致 - 静态成员变量必须在类外单独定义，光在类内
static int count;不够，还得在某个.cpp里写int MyClass::count = 0;
C++ 调用 C 函数时符号找不到
比如 main.cpp 调用了 func.c 里的 int add(int, int);，但链接时报 undefined reference to `add(int, int)' —— 这是因为 C++ 编译器对函数名做了 name mangling，而 C 函数没有，两者符号名对不上。
- 在 C 头文件里包一层
extern "C"：#ifdef __cplusplus extern "C" { #endif int add(int, int); #ifdef __cplusplus } #endif - 或者在 C++ 文件里调用前加
extern "C" { int add(int, int); } - 确保
.c文件确实被编译进了项目（CMake 中不能只写add_executable(app main.cpp)，得把func.c也列进去）
源文件没参与编译，或库链接顺序错
链接器按命令行从左到右扫描目标文件和库，如果 main.o 依赖 utils.o，但命令是 gcc main.o -lutils，而 libutils.a 里又依赖更底层的 core.o，那就可能失败 —— 因为链接器看到 main.o 里有未定义符号，去 libutils.a 找到了，但发现 libutils.a 自己也有未定义符号，此时已过期不再回头查。
立即学习“C++免费学习笔记（深入）”；
- 把依赖者放前面，被依赖者放后面：例如
g++ main.o utils.o core.o -o app或g++ main.o -lutils -lcore - CMake 中检查
add_executable()的源文件列表，确认所有.cpp和.c都列全了 - 用
make clean或删掉build/目录重来，避免旧的.o文件残留导致误判
模板定义没放在头文件里
模板函数或类的定义如果只写在 .cpp 里，其他文件包含头文件后能编译通过（因为声明可见），但链接时会报 undefined reference —— 模板实例化发生在使用点，而实现不在同一编译单元，链接器自然找不到。
- 把模板的声明和定义都放在头文件中（
.h或.hpp） - 或者显式实例化：在
.cpp里写template class MyStack<int>;</int>，但仅限你知道所有要用的类型 - 别指望靠
#include "my_stack.cpp"来绕过 —— 这容易引发 ODR 违规或重复定义
最容易被忽略的是：你以为改了定义，其实改的是另一个同名函数；或者 CMakeLists.txt 里用了 file(GLOB ...) 自动收集源文件，但新添加的 .cpp 没触发重新生成 Makefile，导致它根本没进编译流程。动手前先确认 compile_commands.json 或 make VERBOSE=1 输出里真有那个文件。
