这不是编译错误，是链接阶段的符号冲突，本质是同一个符号（函数、变量等）在多个.obj文件里被定义了，链接器无法确定使用哪一个；常见原因包括头文件中误写变量定义、非inline函数实现置于头文件、重复包含.cpp文件、运行时库配置不一致等。
直接说结论：这不是编译错误，是链接阶段的符号冲突，本质是同一个符号（函数、变量等）在多个 .obj 文件里被定义了，链接器不知道该用哪一个。
头文件里写了变量定义，最常见也最隐蔽的坑
比如在 config.h 里写了 int g_debug = 1;，然后被 A.cpp 和 B.cpp 同时包含——这两个源文件各自编译后，都会生成一个带 g_debug 定义的 .obj，链接时必然报 LNK2005。
- 声明和定义必须分开：
config.h中只写extern int g_debug;；唯一一个.cpp（如main.cpp）里写int g_debug = 1; - 别在头文件里给
extern变量赋初值，extern int g_debug = 1;仍是定义，不是声明 - 如果变量只在单个
.cpp内使用，直接用static int local_flag = 0;，它不会导出符号，自然不冲突
头文件里写了非 inline 函数实现
像这样：
// utils.h
int add(int a, int b) { return a + b; } // ❌ 每个包含它的 .cpp 都会生成一份定义
一旦被两个以上源文件包含，就触发 LNK2005。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 加
inline是最轻量的解法：inline int add(int a, int b) { ... }，编译器会尝试内联，且允许多重定义 - 更规范的做法是：头文件只放声明
int add(int a, int b);，实现在单独的utils.cpp里 - 类内定义的成员函数默认是
inline，但若在类外定义（哪怕在头文件里），就必须加inline或挪到.cpp
误用 #include "*.cpp" 引入实现文件
有人为了“图省事”，在 main.cpp 里写 #include "stack.cpp"，结果 stack.cpp 本身又被单独编译成 stack.obj，而 main.obj 里又塞了一份它的代码——链接器看到两份同名函数，立刻报错。
- 永远不要
#include任何.cpp文件 - 正确做法是把接口抽成
.h，实现留在.cpp，再让项目把.cpp加入编译列表 - 如果真想合并文件（比如写单文件 demo），那就删掉
stack.cpp的独立编译项，只保留main.cpp一个源文件
运行时库或第三方库链接顺序/配置不一致
比如项目设为 /MT（静态链接 CRT），但某个引入的 .lib 是用 /MD（动态链接）编译的，两者都定义了 operator new、_DllMain@12 等符号，就会撞出 LNK2005。
- 检查所有模块的「C/C++ → 代码生成 → 运行时库」设置是否完全一致（
/MT对/MT，/MDd对/MDd） - 检查「链接器 → 输入 → 忽略特定默认库」是否误填了关键库（如
libcmt.lib） - 若混用 MFC 和 CRT，确保链接顺序是 MFC 库在前、CRT 库在后（VS 2019+ 通常自动处理，但老项目或手动
.lib列表仍需留意）
真正难排查的往往不是语法错误，而是符号来源不透明——比如某个宏展开后悄悄定义了变量，或者预编译头（stdafx.h 或 pch.h）里混进了实现代码。遇到顽固的 LNK2005，先用 dumpbin /symbols xxx.obj 查看哪个 .obj 真的包含了冲突符号，再顺藤摸瓜。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
