编译阶段一个警告都没有，一进链接就蹦出来一行：LNK2019: unresolved external symbol "int __cdecl add(int,int)" (?add@@YAHHH@Z) referenced in function main。语法没问题，是链接器找遍了所有.obj和.lib，没找到add的实现。
LNK2019的麻烦在于它只说找不到，不说为什么找不到。常见原因就那七八种，挨个排除比盯着报错发呆快。
先把报错里的修饰名解出来
报错末尾那个括号里的?add@@YAHHH@Z是C++的名字修饰，里面藏着函数签名。看不懂很正常，用VS自带的undname.exe反解析：
undname ?add@@YAHHH@Z
输出是int __cdecl add(int,int)。这一步的价值在于确认调用约定和参数类型对不对。期望的是extern "C"的add，这里却显示带参数修饰的C++符号，方向就清楚了。undname.exe在VC\Tools\MSVC目录下，进Developer Command Prompt for VS 2022就能直接敲。
定义所在的cpp根本没进工程
这是最常碰上的一种。头文件加了、函数声明写了、实现也敲完了，但那个.cpp从来没被加进.vcxproj。VS里表现为解决方案资源管理器的文件图标上有个小红叉，或者压根看不到这个文件。
直接翻.vcxproj确认：
<ItemGroup> <ClCompile Include="add.cpp" /> </ItemGroup>
少了这行，文件就只是躺在磁盘上，跟编译没关系。右键项目、添加、现有项，重新加一次即可。
只声明没定义
类里写了void foo();，.cpp里忘了写实现，或者写了但签名不一致（一个带const一个不带），链接器当成两个不同符号处理。
类的静态成员变量也属于这一类。头文件里写static int count;只是声明，必须在某个.cpp里给一次定义：
// Foo.h
class Foo { static int count; };
// Foo.cpp
int Foo::count = 0;
C++17起可以写成inline static int count = 0;，省掉.cpp里那行。项目属性里的C++语言标准要设成ISO C++17或更高，VS 17.11、17.12、17.13，默认还是C++14，老工程升级过来经常卡在这一步。
库没链进去
用了第三方库，头文件包含没问题，却没把.lib告诉链接器。两处要填：链接器、常规、附加库目录，填.lib所在目录；链接器、输入、附加依赖项，填xxx.lib。Debug与Release、x86与x64是四套独立配置，改了一个平台不等于改了全部，之前遇到过改完Debug能编、切到Release又报同一条LNK2019。
不想进属性页挨个点，写在代码里更快：
#pragma comment(lib, "ws2_32.lib") #pragma comment(lib, "../thirdparty/xxx.lib")
extern "C"没加
C++调C写的库，头文件必须用extern "C"包起来，否则编译器按C++规则生成修饰名去库里找，而库里导出的是C风格的无修饰名，永远对不上。现象很有特点：报的符号是带问号的那种。
#ifdef __cplusplus
extern "C" {
#endif
int c_func(int a);
#ifdef __cplusplus
}
#endif
反过来C调C++也一样处理，但导出层得用C++编译器编。
用dumpbin确认库里到底有什么
怀疑库不对，别猜，直接看它导出的符号表：
dumpbin /symbols xxx.lib | findstr add dumpbin /exports xxx.dll
查出来的名字和报错里的修饰名逐字符比对。差异哪怕只有一个字符，比如__stdcall的_add@8和__cdecl的_add，链接器也认不出来。
x86上调用约定不一致是重灾区：__stdcall会把函数名修饰成_add@8，@后面是参数总字节数。x64统一了调用约定，这类问题在64位下自动消失，所以同一个工程32位能编、64位报LNK2019的情况也见过。
让链接器把搜索过程打出来
实在看不出问题，开/VERBOSE看它在哪些库里找过：
项目属性 → 链接器 → 命令行 → 附加选项: /VERBOSE:LIB
输出会列出每一个被搜索的库路径。要找的库压根没出现在列表里，是附加库目录没配对；出现了却没匹配上符号，是库版本不对。
模板实现放在cpp里
模板的实例化发生在编译期，定义写在.cpp里，别的翻译单元看不见实现，链接时就找不到。声明和定义都得放进头文件，或者在.cpp末尾显式实例化：
template class MyClass<int>;
入口函数对不上
写的是main，子系统却设成了Windows，报LNK2019 unresolved external symbol _WinMain@16。反过来写wWinMain而子系统是控制台，报_main。项目属性、链接器、系统、子系统，控制台程序选/SUBSYSTEM:CONSOLE。
还有一种更隐蔽：工程类型建错了，该建静态库却建成了应用程序，没有main就会报这个。
MSVC 14.40、14.41、14.42，LNK2019的报错格式没变过，上面这套排查顺序都适用。核实到2026年9月，Visual Studio 2022的17.13上实测一致。