lnk2019错误本质是链接器找不到函数或变量的定义，即编译通过但链接时因符号未定义而报“unresolved external symbol”，需先定位错误信息中的具体符号名，再检查声明与定义一致性、模板实现位置、静态成员类外定义、源文件是否参与编译、库是否正确链接及c/c++混用时extern "c"缺失等问题。
查链接器错误里具体是哪个符号没实现
“unresolved external symbol”不是泛泛而谈的编译失败，而是链接阶段明确告诉你：某个符号（比如函数或变量）在编译时声明了，但所有目标文件（.obj/.o）里都找不到它的定义。关键第一步是看错误信息末尾的符号名，例如：_ZN5MyCls4funcEv 或 my_helper_function —— 这才是你要追的线索。
常见干扰项：C++ 函数名经过 name mangling，直接搜源码可能找不到。用 dumpbin /symbols（Windows）或 c++filt（Linux/macOS）解码：c++filt _ZN5MyCls4funcEv 输出可能是 MyCls::func()。
确认声明和定义是否匹配（尤其注意 inline、static、模板）
很多“没实现”其实是声明和定义对不上号，链接器压根不认它们是同一个东西：
-
inline函数必须在头文件里定义，不能只声明；如果只在 .cpp 里写inline void f() { }，其他翻译单元看不到定义，就会报错 -
static函数/变量作用域限于当前编译单元，头文件里声明static int g_val;然后在 .cpp 里定义，别的文件无法访问，链接时自然找不到 - 模板函数/类的定义通常不能分离到 .cpp（除非显式实例化），否则只有声明没有实例化代码，链接器无从生成具体函数体
- 成员函数声明写了
const或引用限定符（&/&&），但定义漏掉了，算两个不同函数
检查是否漏加源文件或库到链接列表
最朴素但高频的问题：定义确实写了，但那个 .cpp 根本没参与编译，或者对应的 .lib/.a 没传给链接器：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用 IDE（如 VS）时，右键 .cpp 文件 → “属性” → 确认“排除在生成之外”是“否”
- CMake 中检查
add_executable或add_library的源文件列表是否包含定义所在 .cpp - 命令行链接时，确保所有相关 .obj/.o 都列在
link.exe或g++命令末尾；用nm -C xxx.o | grep func可验证目标文件里是否存在该符号 - 调用第三方库时，不仅
#include头文件，还必须把对应.lib（Windows）或-lxxx（Linux）加进链接选项
跨模块导出/导入符号（DLL/so 场景）
Windows 下 DLL 导出函数若没加 __declspec(dllexport)，或者调用方没用 __declspec(dllimport) 声明，链接器会认为这是普通外部符号，找不到实现：
典型写法是用宏统一控制：
#ifdef BUILDING_MY_DLL #define MY_API __declspec(dllexport) #else #define MY_API __declspec(dllimport) #endif MY_API void my_exported_func();
漏掉宏定义或条件判断出错，就容易出现“声明了但链接器看不见实现”。Linux 下类似问题常因未加 -fvisibility=hidden 或未用 __attribute__((visibility("default"))) 显式导出导致。
符号可见性这类问题往往只在构建动态库时暴露，静态链接一般不涉及，容易被忽略。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
