简介：Microsoft Windows SDK 7.1 面向需要在 Windows 7 与 Windows Server 2008 R2 上构建、调试和部署原生应用的 C++ 开发者，提供 Windows API 开发所需的安装入口与配套说明，适合希望补齐 Win32 开发环境、查阅 SDK 版本信息的学习者。压缩包为 rar 格式，共 4 个文件，体积约 102KB；其中 setup.exe 与 winsdk_dvdx86.msi 承担安装启动与组件引导，Autorun.inf 用于光盘式自动运行配置，ReleaseNotes.Htm 则汇总版本说明与注意事项，整体更偏向 32 位 SDK 的安装引导和资料入口，而非完整离线开发包。已有 1370 人浏览学习，可帮助读者快速定位安装程序、了解发行说明，并配合完整 SDK 获取头文件、库、编译链接工具及调试工具，减少环境搭建时的查找成本。
1. Windows SDK 7.1 与 C++：一条被冻结却还在服役的工具链
去年接了个老项目，源码里还挂着#include <windows.h>加#pragma comment(lib, "user32.lib")的写法，工程文件是.vcxproj，工具集写死v100。机器上装着新版 IDE，打开就报工具集缺失。折腾一圈发现，能救场的还是那份 Windows SDK 7.1 下载包——它自带一套完整的 C++ 编译器与 Windows 7 头文件库，命令行下cl一敲就能出 exe。这东西不属于"新项目该用"的范畴，但对维护 2010 年前后的 C++ 代码、复现老式 Win32 示例、给遗留 DLL 补一个能跑的构建环境，它是少数几个不用改一行源码就能接上的方案。适合谁？手里有老工程要编译、需要 VC10 工具链做二进制兼容验证、或者想对照 Windows 7 时代的 API 行为的人，都值得留一份。
2. 拆开安装目录：SDK 7.1 里的 C++ 组件与查找规则
拿到安装包之后先别急着点下一步。这套 SDK 的目录结构和后来的 Windows 10 SDK 差别很大，不先弄清 Bin、Include、Lib 三段各放什么，后面环境变量一配错，报错信息能把你带到完全无关的方向上去。默认安装路径是C:\Program Files\Microsoft SDKs\Windows\v7.1\，下面这几层是 C++ 开发真正会用到的部分。
2.1 Bin 目录：cl、link、rc、mt 与 SetEnv.cmd
Bin目录是这个 SDK 的心脏。根目录下放着SetEnv.cmd，子目录x86、x64、ia64里各有一套针对目标架构的工具。x86 目录里的cl.exe版本号是 16.00.30319.01，对应 VC10，也就是 Visual Studio 2010 那一代编译器；link.exe、lib.exe、dumpbin.exe、rc.exe、mt.exe都在同一层。做交叉编译时，Bin\x86\amd64\cl.exe是宿主为 x86、目标为 x64 的那一份，这一点和后来统一用一套编译器加-m64参数的思路完全不同。
SetEnv.cmd的作用是把这一堆路径一次性拼进当前命令行会话的PATH、INCLUDE、LIB三个变量里。它的参数不多，最常用的是/x86、/x64、/ia64选目标架构，/debug或/release选运行时库链接方式。这个脚本必须在cmd.exe里call，不能直接在 PowerShell 里执行——它写的是批处理语法，PowerShell 解释不了里面的set逻辑。
提示：
SetEnv.cmd会覆盖当前会话已有的INCLUDE和LIB。如果你机器上同时装着新版 SDK，先开一个干净的 cmd 窗口再调用，别在已经配好别的工具链的会话里混着用。
Bin下面还有两个容易被忽略的目录。Bin\NETFX 4.0 Tools放的是 .NET Framework 4 相关的工具，纯 C++ 项目用不上，但安装时默认会勾上。Bin\rc里是资源编译器，后面会提到它和新版 SDK 的rc.exe有参数兼容问题。
2.2 Include 与 Lib 的平铺布局：和 8.0 之后完全不同的查找规则
这是最容易翻车的地方。Windows SDK 7.1 的Include目录是平铺的：Windows.h、WinBase.h、WinUser.h、CommCtrl.h这些头文件直接躺在Include\根下，只有一个gl子目录单独放 OpenGL 相关头文件。到了 Windows SDK 8.0 之后，头文件被拆进um、shared、winrt三个子目录，INCLUDE需要分别指向它们。
这个差异带来的直接后果是：网上搜到的很多"配置 Windows SDK 环境变量"的教程是 8.0 之后的写法，照抄过来写成Include\um，在 7.1 上就是找不到windows.h。正确的写法是只加两个路径：
set SDKROOT=C:\Program Files\Microsoft SDKs\Windows\v7.1 set INCLUDE=%SDKROOT%\Include;%SDKROOT%\Include\glLib目录同理，根目录下是按目标架构分的子目录：Lib\x86、Lib\x64、Lib\ia64。LIB变量要指向具体那一层，而不是Lib根目录。如果你同时需要链接 VC 运行库，LIB里还得带上 VS2010 的VC\lib和VC\lib\amd64，否则libcmt.lib、msvcrt.lib这些会报找不到。
| 变量 | 7.1 的正确取值 | 8.0 之后的取值（别照抄） |
|---|---|---|
| INCLUDE | %SDKROOT%\Include加%SDKROOT%\Include\gl | %SDKROOT%\Include\um等 |
| LIB | %SDKROOT%\Lib\x86或x64 | %SDKROOT%\Lib\winv6.3\um\x86 |
| PATH | %SDKROOT%\Bin与%SDKROOT%\Bin\x86 | %SDKROOT%\Bin\x64等 |
2.3 组件勾选：五个必装项与三个可以放弃的项
安装向导里的组件树展开后项目不少，但真正和 C++ 相关的不多。我的习惯是只留下面这几项，其余全部取消，能省掉一大半安装失败的概率，尤其是在 Windows 10 之后的系统上。
| 组件 | 是否勾选 | 理由 |
|---|---|---|
| Windows Native Code Development → Compilers | 必选 | 提供 cl.exe 与 link.exe，没有它这套 SDK 就只剩头文件 |
| Windows Native Code Development → Windows Headers and Libraries | 必选 | Win32 API 头文件与导入库 |
| Windows Native Code Development → Windows Debugging Tools | 建议选 | 老版本 cdb/windbg，调试老二进制时比新版调试器更认旧符号 |
| .NET Framework 4 | 取消 | 系统上通常已有更高版本，安装包里这一项会触发降级检测失败 |
| Visual C++ 2010 Runtime Libraries | 可选 | 只影响再发行库，编译阶段不需要 |
| Samples | 可选 | 示例代码单独一个包，做 API 对照时有用，不影响编译 |
装到这一步，如果安装程序在 .NET Framework 4 那一步卡住回滚，基本就是系统自带的 .NET 版本比安装包里的高，安装器拒绝"降级安装"。解决办法在后面的避坑章节里细说。
3. 安装顺序与版本选择：VS2010、SDK 7.1、7.1A 的三套组合
这套工具链有个很硬的依赖关系：SDK 7.1 的安装程序检测到机器上已经装了 Visual Studio 2010 时，会额外执行一步"IDE 集成"，把 SDK 的平台信息注册进 VS 的项目系统；如果检测不到，它只装命令行部分。这个检测和注册的顺序决定了你在 IDE 里能不能选到 Windows 7 平台。
3.1 为什么必须先装 VS2010 再装 SDK
先装 VS2010，再装 SDK 7.1，安装程序会往C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\下补平台描述文件，VS 里新建 C++ 项目时才能在"平台"下拉里看到对应的 SDK 选项，MSBuild 也能通过PlatformToolset=v100找到正确的头文件与库路径。
反过来先装 SDK 再装 VS，SDK 的集成逻辑没机会执行，结果就是命令行能用、IDE 里选不到。这个问题不会报错，只是"选项消失了"，很多人会误以为是 VS 装坏了。补救办法是用安装包的"修复"模式再跑一遍，或者在控制面板里对 SDK 7.1 选"更改"、把 IDE 集成那一项重新勾一次。
还有一层版本顺序：VS2010 有 RTM 和 SP1 两个编译器版本，cl分别是 16.00.30319.01 和 16.00.40219.01。SDK 7.1 安装包里自带的是 RTM 那一版，装完之后可能把 SP1 的编译器覆盖回去。我的做法是 VS2010 → VS2010 SP1 → SDK 7.1，装完 SDK 后敲一次cl看版本号，如果掉回 30319 而项目又依赖 SP1 的修复，就再对 SP1 做一次修复安装。这一步花不了几分钟，但能避免后面查一个莫名其妙的编译器行为差异。
3.2 7.1 与 7.1A：DirectX 头文件的那点事
安装介质的文件名里带不带 A，决定了它包含哪些头文件。7.1 对应 Windows 7 正式版的 API 集合；7.1A 是在其基础上追加了一批与 DirectX 相关的内容，用于 Windows 8 预览阶段的部分开发场景。两者的编译器和 Win32 头文件是一致的，差别集中在图形相关的部分。
| 对比项 | SDK 7.1 | SDK 7.1A |
|---|---|---|
| VC10 编译器 | 包含 | 包含 |
| Win32 头文件与库 | 完整 | 完整 |
| DirectX 相关头文件 | 不含独立 DirectX SDK 内容 | 追加了部分图形接口内容 |
| 适用场景 | 老 Win32/MFC 工程维护、VC10 构建 | 需要那批图形头文件的场景 |
| 与 VS2010 的 IDE 集成 | 支持 | 支持方式相同 |
多数维护老 C++ 工程的人用 7.1 就够了，DirectX 部分单独装一份对应年代的 DirectX SDK 更干净，混着装反而容易出现同名头文件谁先被找到的问题。只有确认工程里#include的那几个图形头文件在 7.1 里找不到时，才需要考虑 7.1A。
3.3 没有 VS2010 的机器上搭一套纯命令行工具链
有些场景不需要 IDE，比如在构建机上只跑编译，或者临时开一台干净虚拟机验证二进制兼容性。这种情况下只装 SDK 7.1 也能干活，但要清楚缺什么：没有 VS2010 就没有VCTargets，MSBuild 无法解析v100工具集，.vcxproj工程构建不了。能用的路径是手写批处理直接调cl和link，或者用 CMake 生成 NMake 工程。
纯命令行方案的完整流程是这样：
@echo off rem 只装 SDK 7.1、没有 VS2010 时的最小构建脚本 set SDKROOT=C:\Program Files\Microsoft SDKs\Windows\v7.1 set PATH=%SDKROOT%\Bin;%SDKROOT%\Bin\x86;%PATH% set INCLUDE=%SDKROOT%\Include;%SDKROOT%\Include\gl set LIB=%SDKROOT%\Lib\x86 cl /nologo /EHsc /W3 /MD /DUNICODE /D_UNICODE %1 /link /SUBSYSTEM:CONSOLE这段脚本里PATH的顺序很关键，Bin\x86必须在PATH靠前的位置，否则可能先命中系统里其他版本的cl。INCLUDE按上一节说的平铺路径写，LIB指向x86子目录。/MD表示链接动态运行库，如果你要把 exe 拷到没装运行库的机器上跑，换成/MT静态链接更省事。
提示：只装 SDK 不装 VS 时，
LIB里没有 VC 的运行库目录，/MD和/MT都会因为找不到libcmt.lib之类的文件失败。这时候要么把 VS2010 的VC\lib路径补进LIB，要么改用不含 C 运行库依赖的极简程序做验证。
4. C++ 跑通第一个 Win32 窗口：命令行与 MSBuild 两条路
环境配好之后得有个能验证的东西。我一般不用控制台 Hello World，因为那验证不了user32.lib、gdi32.lib这些 GUI 相关的库路径，也验证不了/SUBSYSTEM:WINDOWS这个链接参数。直接上一个最小 Win32 窗口，一次把编译、链接、资源、子系统四件事都过一遍。
4.1 SetEnv.cmd 到底改了什么：环境变量的四段式
在深入代码之前，先把这个脚本干的事说清楚。它做的事情可以拆成四段：把Bin与架构对应的子目录插进PATH；把Include与Include\gl拼进INCLUDE；把Lib\<arch>拼进LIB；再设置一批辅助变量，比如WindowsSdkDir、VCINSTALLDIR之类，供 MSBuild 和后续脚本读取。
调用方式是在 cmd 里：
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /release/release影响的是默认的运行时库选择，/debug会优先链接调试版运行库。切换目标架构时不要试图在同一个窗口里连调两次/x86和/x64，脚本是追加式的，第二次调用会把两套路径混在一起，链接阶段就会出现架构冲突。我的习惯是一个架构开一个 cmd 窗口，用完就关。
4.2 手写 cl 加 link：最小窗口程序的完整编译链
先准备源文件，保存为win32_min.cpp。这个程序不弹消息框，而是注册窗口类、创建窗口、跑消息循环，覆盖的 API 面足够宽，能顺带验证RegisterClassEx、CreateWindowEx、GetMessage这几组符号在导入库里都存在。
// win32_min.cpp - 用 SDK 7.1 的 VC10 编译器构建的最小窗口程序 #define WIN32_LEAN_AND_MEAN #include <windows.h> // 窗口过程：只处理销毁消息，其余交给默认处理 LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { if (msg == WM_DESTROY) { PostQuitMessage(0); return 0; } return DefWindowProcW(hWnd, msg, wParam, lParam); } int WINAPI wWinMain(HINSTANCE hInst, HINSTANCE hPrev, LPWSTR cmdLine, int nShow) { const wchar_t* cls = L"MinWndClass"; WNDCLASSEXW wc = { sizeof(WNDCLASSEXW) }; wc.lpfnWndProc = WndProc; wc.hInstance = hInst; wc.lpszClassName = cls; wc.hCursor = LoadCursorW(NULL, IDC_ARROW); wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); if (!RegisterClassExW(&wc)) return 1; HWND hWnd = CreateWindowExW(0, cls, L"SDK 7.1 Build Check", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 640, 400, NULL, NULL, hInst, NULL); if (!hWnd) return 2; ShowWindow(hWnd, nShow); UpdateWindow(hWnd); MSG msg; while (GetMessageW(&msg, NULL, 0, 0) > 0) { TranslateMessage(&msg); DispatchMessageW(&msg); } return (int)msg.wParam; }编译命令分两步写，比一步到位更容易看出问题出在编译期还是链接期：
rem 第一步：只编译，产出 obj cl /nologo /c /EHsc /W3 /MD /DUNICODE /D_UNICODE win32_min.cpp rem 第二步：链接，显式指定子系统和导入库 link /nologo /SUBSYSTEM:WINDOWS /OUT:win32_min.exe win32_min.obj user32.lib gdi32.lib kernel32.lib参数逐个说明。/c表示只编译不链接，/EHsc启用标准 C++ 异常处理模型，/W3是警告等级，/MD链接多线程动态运行库，/DUNICODE和/D_UNICODE让 Windows API 的宏展开走宽字符版本——这个程序里显式调用了带W后缀的函数，但头文件里很多宏依赖这两个定义，漏掉会出现LPCSTR和LPCWSTR不匹配的编译错误。
链接阶段/SUBSYSTEM:WINDOWS告诉链接器这是一个 GUI 程序，入口是wWinMain而不是main，漏掉这个参数会报LNK2019: 无法解析的外部符号 WinMain。三个.lib里user32.lib提供窗口相关符号，gdi32.lib是习惯性带上以防后续加绘图代码，kernel32.lib一般由编译器默认链接，显式写出来更保险。
4.3 用 MSBuild 4.0 与 v100 工具集构建工程
命令行跑通只证明工具链完整，工程文件能不能构建是另一回事。VS2010 的 MSBuild 位置在.NET Framework目录下，不在 SDK 里：
rem 先用 SetEnv 配好基础环境，再调 MSBuild call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /release "%WINDIR%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" ^ win32_min.vcxproj /p:Configuration=Release /p:Platform=Win32 /v:m工程文件里最关键的是这一小段属性组，PlatformToolset必须写v100，CharacterSet写Unicode才能和源码里的W后缀函数对上：
<!-- win32_min.vcxproj 中的配置属性组 --> <PropertyGroup Label="Configuration"> <ConfigurationType>Application</ConfigurationType> <PlatformToolset>v100</PlatformToolset> <CharacterSet>Unicode</CharacterSet> <UseOfMfc>false</UseOfMfc> </PropertyGroup>如果这台机器只装了 SDK 7.1、没装 VS2010，MSBuild 会在解析v100时抛MSB8020，因为C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\这套规则文件是 VS2010 装的，不在 SDK 里。这时候别硬凑，回到 4.2 的手写命令，或者装一份 VS2010 的 C++ 生成工具。
4.4 产物验证：dumpbin 看子系统，依赖扫描看运行库
exe 出来之后别急着双击。先用dumpbin确认两件事：子系统是不是 WINDOWS，依赖的 DLL 是不是你预期的运行库版本。
rem 查看 PE 头的子系统字段 dumpbin /headers win32_min.exe | findstr /i subsystem rem 列出导入的 DLL，确认没有意外依赖 dumpbin /dependents win32_min.exe正常输出里子系统一项应该是Windows GUI，依赖列表里应该能看到USER32.dll、GDI32.dll、KERNEL32.dll，以及/MD链接时引入的MSVCR100.dll。如果依赖里出现了VCRUNTIME140.dll，说明链接时命中的是别的版本运行库，八成是LIB路径里混进了新版 VS 的目录。这一步在跨机器部署时特别有用，比到了目标机上弹"缺少 DLL"再回头查省事得多。
5. 避坑与排查：五类翻车现场
这套工具链的坑基本都集中在"版本共存"和"路径顺序"两件事上，症状看起来五花八门，归因之后其实很集中。下面五条是我自己踩过、也在别人机器上复现过的，按现象、原因、解决三段写。
第一条：VS2010 里新建 C++ 项目找不到 Windows 7 平台选项。
现象是 IDE 的"平台"下拉里只有 Win32，没有 SDK 对应的条目，命令行却一切正常。原因是安装顺序反了，先装 SDK 后装 VS，SDK 的 IDE 集成注册步骤没有执行。解决方式是找到 SDK 7.1 的安装项，选"更改"，把与 IDE 集成相关的组件重新勾选并走一遍；或者按 VS2010 → SP1 → SDK 7.1 的顺序重来。这一步不涉及卸载 VS，修复模式一般十分钟内能完成。
第二条：Windows 10 之后的系统上安装程序跑到 .NET Framework 4 那步报错回滚。
现象是进度条走到一半弹窗提示某个组件安装失败，整个安装回滚，SDK 目录是空的。原因是系统自带 .NET Framework 版本高于 4.0，安装包里的安装器检测到已存在更高版本后拒绝执行。解决方式是在组件树里把.NET Framework 4整项取消勾选，只保留 Windows Native Code Development 下的编译器、头文件库和调试工具，再继续安装。如果仍然失败，把 setup.exe 的兼容性模式设为 Windows 7 再运行一次。
第三条：编译时报fatal error C1083: 无法打开包括文件: "windows.h"。
现象是编译器找不到最基础的头文件，但 SDK 明明装好了。原因是INCLUDE指向了错误层级，比如照抄了 8.0 之后的教程写成Include\um，而 7.1 的头文件是平铺在Include根下的。解决方式是把INCLUDE改成%SDKROOT%\Include;%SDKROOT%\Include\gl，然后在同一个 cmd 窗口里用echo %INCLUDE%确认输出，再重新编译。不要在新开的窗口里查，set的作用域只在当前会话。
第四条：链接 x64 目标时报LNK1112: 模块计算机类型"x86"与目标计算机类型"x64"冲突。
现象是编译阶段过了，链接阶段报架构不匹配。原因是PATH里同时存在 x86 和 x64 两套工具，先命中的是 x86 的cl.exe，或者LIB里混进了Lib\x86。解决方式是一个架构一个干净的 cmd 会话，调用SetEnv.cmd /x64之后用where cl确认命中的是Bin\x86\amd64下的那一份，LIB只保留Lib\x64和对应的 VC 库目录。混着调两次SetEnv.cmd是这个问题最常见的来源。
第五条：VS2012 及以后版本打开老工程报MSB8020: 找不到 v100 的生成工具。
现象是工程能加载，一构建就报工具集缺失。原因是v100的规则文件和编译器只随 VS2010 及其生成工具分发，新版 IDE 不再内置。解决方式有两条：一是用.NET Framework\v4.0.30319\MSBuild.exe配合SetEnv.cmd在命令行构建，绕开新版 IDE 的工具集解析；二是在构建机上装一份 VS2010 的 C++ 生成工具，让VCTargets目录重新出现。两条路都能跑通，区别是前者不需要 IDE，后者能在新 IDE 里点按钮。
6. 把 SDK 7.1 固化成可复现的构建入口
命令行能用之后，下一步是让它可重复。每次构建都手动call SetEnv.cmd再敲一长串参数，迟早会漏掉某个变量。我的做法是写一个薄封装，把环境准备和编译参数封进去，再配一个环境快照脚本，用于在别的机器上对比差异。
封装脚本放在工程根目录，命名为build.bat：
@echo off setlocal rem build.bat - 固定 SDK 7.1 的构建入口，参数 1 为源文件，2 为输出名 set "SDKROOT=C:\Program Files\Microsoft SDKs\Windows\v7.1" if not exist "%SDKROOT%\Bin\SetEnv.cmd" ( echo [ERROR] SDK 7.1 not found at %SDKROOT% exit /b 1 ) call "%SDKROOT%\Bin\SetEnv.cmd" /x86 /release >nul if errorlevel 1 exit /b 2 cl /nologo /EHsc /W3 /MD /DUNICODE /D_UNICODE /Fe"%~2" "%~1" ^ /link /SUBSYSTEM:WINDOWS user32.lib gdi32.lib if errorlevel 1 exit /b 3 echo [OK] built %~2这个脚本有三个作用。第一，SDKROOT写死但先做存在性检查，路径不对时立刻报错，而不是等到cl报一堆找不到头文件的错。第二，SetEnv.cmd的输出重定向到nul，避免它刷屏干扰编译日志。第三，用errorlevel分级返回，1表示 SDK 缺失、2表示环境准备失败、3表示编译失败，接到 CI 里能直接定位问题阶段。
参数上%~1和%~2是去掉引号后的原始参数，/Fe指定输出文件名，其余和前面手写命令一致。调用方式就是build.bat win32_min.cpp win32_min.exe。
跨机器复现时，光有脚本还不够，得知道两台机器的环境差在哪。下面这段 PowerShell 把当前会话里和构建相关的变量抓出来存成文本，方便 diff：
# dump_env.ps1 - 导出构建相关环境变量，用于跨机器比对 $keys = 'PATH','INCLUDE','LIB','WindowsSdkDir','VCINSTALLDIR' $out = foreach ($k in $keys) { $v = [Environment]::GetEnvironmentVariable($k) if ($v) { "$k=$v" } } $out | Set-Content -Encoding UTF8 env_snapshot.txt Write-Host "saved $($out.Count) variables to env_snapshot.txt"注意它读的是当前进程的环境变量，所以必须先在一个已经call过SetEnv.cmd的 cmd 里启动 PowerShell，否则抓到的全是空的。比对时重点看INCLUDE和LIB的分号分隔顺序，顺序不同就可能导致头文件或库命中不同版本，这类差异在报错信息里往往看不出来。
| 变量 | 排查时的关注点 | 典型错误值 |
|---|---|---|
| PATH | Bin\x86是否在其他cl.exe之前 | 混入新版 VS 的VC\Tools\MSVC路径 |
| INCLUDE | 是否为平铺的Include加Include\gl | 写成Include\um |
| LIB | 是否只有单一架构子目录 | 同时含x86与x64 |
| WindowsSdkDir | 是否指向v7.1根目录 | 指向Windows Kits\10 |
还有一个容易忽略的点：资源编译器。SDK 7.1 的rc.exe在Bin下，而新版 Windows SDK 的rc.exe在Windows Kits\10\bin\<版本>\x86下，两者的命令行参数不完全兼容，尤其是/fo的写法差异。构建带.rc资源的工程时，如果PATH里新版rc排在前面，会出现"资源编译成功但输出文件位置不对"的怪现象。我的习惯是在build.bat里显式用绝对路径调用"%SDKROOT%\Bin\rc.exe"，不依赖PATH顺序。
从那以后我每次接手一个老 C++ 工程，第一件事不是打开 IDE，而是先在命令行里把cl的版本、INCLUDE的内容、LIB的架构这三样打印出来，确认环境和工程年代对得上再动手。这一步花两分钟，能省掉后面半天对着LNK2019猜谜的时间。希望帮到你。
本文还有配套的精品资源，点击获取
