有的项目其实只想让你装个运行时但你要做开发、要编译 C/C 代码那就绕不开 MSVC 编译工具链。尤其是像 Qt 装完之后默认只有 MinGW可某些第三方库、某些 SDK、以及很多需要在 Windows 上编译的 FFmpeg 变体比如带 libx265 的都得靠 MSVC 来搞定。这时候最省事、也最可维护的做法就是用命令行静默安装 Microsoft C (MSVC) Build Tools。这篇内容就是我自己在实际环境里反复摸索出来的完整流程怎么拿官方安装器、怎么拆解命令行参数、怎么实现一次安装到位、怎么做离线布局、怎么在 CI 脚本里集成以及安装完之后怎么验收、怎么避坑。适合三种人看一是不想装完整 Visual Studio 但需要 cl.exe 和 nmake 的开发者二是要在全新机器上批量配置环境的运维三是因为 Qt、FFmpeg、CMake 这类项目被迫切换 MSVC 工具链的兄弟。1. 为什么绕开完整 Visual Studio直接用 Build Tools1.1 你需要 MSVC 的真实场景先说结论MSVC 不是编译器选择困难症而是很多场合下你根本没得选。最典型的是 Qt 开发。你从 Qt 在线安装器里装了 MinGW 版本的 Qt结果去用某个第三方库时发现对方只提供了 MSVC 编译产物或者你需要在 Windows 上调用 Windows SDK 的某些 API或者干脆是想用 Qt 官方预编译包。Qt 官方默认会同时提供 MinGW 版本和 MSVC 版本但如果你装的是 MSVC 版本就必须要有一套对应的 MSVC 编译环境。再比如 FFmpeg。很多人在 Windows 上编译 FFmpeg 都是为了集成 libx265、libx264 这类编码库网上能找到的脚本和教程多数都是优先适配 MSVC 环境因为 MSVC 托管的 vcpkg 依赖库体系最全。你用 MinGW 去跑光是一堆依赖库的 ABI 匹配就能折腾半天。还有一类是 CI/CD。团队里如果要求在 Windows Agent 上编译原生 C 代码给每个 Agent 装完整 IDE 是不合适的又贵又臃肿。Build Tools 就是官方为这种场景推出的精简方案只有编译器和构建工具不带 IDE。此时命令行安装就成了基础设施脚本里必须掌握的一环。1.2 MSVC 和 MinGW 到底差在哪能不能混用很多人第一个问题就是我用 MinGW 不也能编译吗为什么非要 MSVC两者的本质区别在于 ABIApplication Binary Interface。MSVC 编译出来的目标文件、静态库、动态库的符号修饰规则、C 命名规范、结构体布局和异常处理机制SEH跟 MinGW 用的 GNU 工具链完全不一样。链接器看到对方的目标文件后通常会直接报符号不匹配、重定义或者无法解析的外部符号。这意味着你用 MinGW 编译一个 C 静态库然后拿到 MSVC 工程里去链接基本是行不通的。这也是我在 Qt 项目里踩过的最大的坑贪图 MinGW 环境装起来简单结果要接一个纯 MSVC 的 SDK 时没法直接用。后续要么重新编译库要么换工具链代价更大。另外调试信息也有差异。MSVC 生成的 PDB 调试符号配合 Visual Studio / WinDbg 调试体验最好MinGW 默认生成的 DWARF 调试信息在 Visual Studio 里支持度有限。所以只要你的产出物是要给别人用的库或 SDK最好别拿 MinGW 硬撑。我整理了个表方便你根据自己的场景快速判断对比项MSVC Build ToolsMinGW-w64编译器核心cl.exegcc.exeC ABIMSVC ABIItanium/类 GNU ABI链接器link.exeld / lld调试符号PDBDWARFQt 套件匹配Qt 的 MSVC 预编译包Qt 的 MinGW 预编译包第三方商业 SDK大多数厂商只提供 MSVC 版基本没有Windows SDK 集成官方原生支持需要额外配置典型用途Qt 桌面、FFmpeg、驱动、COM、CI开源交叉编译、偏好 GCC 的项目总之它们不是两个等价选项而是两条不同的生态。你一旦选择或者被要求使用 MSVC就老老实实把 MSVC 工具链配好。1.3 Build Tools 和完整 Visual Studio 的关系Build Tools 的全称是 Visual Studio Build Tools它的安装包和安装器跟完整 Visual Studio 用的是同一套机制只是没有包含 IDE 前端和大部分图形化设计工具。它面向的是我不需要写代码的界面我只需要编译器、头文件、库文件、MSBuild、CMake 集成这类需求。为什么不直接在完整 Visual Studio 里勾选一下 C 工作负载不是不行只是浪费。完整 VS 动辄几十 GBBuild Tools 按最小配置装出来大概 3~6 GB 左右对于磁盘紧张或者只需要在无图形界面的环境里跑构建任务的情况来说差异非常明显。还有一点安装方式其实完全一样你甚至可以理解为Build Tools 就是 Visual Studio 安装器的一个目标配置。这也解释了为什么它支持的命令行参数跟 VS 安装器是同一套这个机制会在后面详细拆解。2. 动手前先读懂官方命令行安装器2.1 从正规渠道拿到 vs_buildtools.exe首先要分清两个完全不同但容易混淆的东西Microsoft Visual C Redistributable和MSVC Build Tools。Redistributable 是运行时 DLL 的集合也就是你运行 MSVC 编译出来的程序时需要的 vcruntime140.dll、msvcp140.dll 这些文件它是给最终用户装的东西。而 Build Tools 是开发工具包里面才有 cl.exe 编译器、link.exe 链接器、Windows SDK 头文件等。标题里说的Microsoft C (MSVC) Build Tools是指后者别下载错了。获取方式你有两条路第一种是去微软 Visual Studio 官方下载页面找 Build Tools for Visual Studio 2022 的下载链接文件名通常叫vs_BuildTools.exe。第二种是用 winget 拉取命令winget install Microsoft.VisualStudio.2022.BuildTools。winget 的优势是方便后面升级和卸载但它的本质也是去官方渠道下载同一个安装器并执行。所以两种方法没有本质区别选你习惯的即可。2.2 命令行参数逐个拆解打开终端执行一次vs_BuildTools.exe --help你会看到一大串参数。这里不把参数全部罗列一遍只讲实际安装配置中一定会用到的几个并按我的使用频度排个序参数作用备注--installPath指定安装目录不指定则使用默认路径--add添加某个组件 ID 或工作负载 ID可重复使用是挑选组件的核心参数--quiet静默安装不弹 UI配合--norestart使用--wait安装完成后等待进程退出并返回退出码脚本化时必须加--norestart安装完成后不自动重启配合安装后手动重启--includeRecommended安装每个工作负载的推荐组件用工作负载 ID 时建议加上--includeOptional安装每个工作负载的全部可选组件慎用体积会大很多--layout创建离线安装缓存目录离线安装最核心的参数--force强制更新或覆盖安装修复环境时很实用--nocache安装完成后删除缓存内容节省磁盘空间但会拖慢后续修改这里最容易忽略的是--wait。我遇到过不止一次在 PowerShell 脚本里直接执行$p Start-Process -FilePath vs_BuildTools.exe -ArgumentList ... -Wait -PassThru如果没在参数层面加--wait安装器可能在安装完成后立即让出进程控制权导致脚本在下游步骤里以为安装已经结束实际上安装还在后台进行。加了--wait安装器进程才真正阻塞住后面拿到的退出码才是可信的。2.3 组件 ID 从哪里查、怎么选Build Tools 的本质是组件安装器它的最小粒度叫做组件 IDComponent ID。ID 的命名规则通常是Microsoft.VisualStudio.Component.开头工作负载Workload是Microsoft.VisualStudio.Workload.开头。最常用的工作负载 ID 是Microsoft.VisualStudio.Workload.VCTools它对应的是 Desktop development with C 整套内容中的构建工具部分。加上--includeRecommended后它会把编译器、核心库、Windows SDK、MSBuild、CMake 工具、测试工具等关键的默认项全部装进来。这是我个人最推荐的一步到位的用法因为组件粒度太细反而容易漏装。如果你要更精细地控制体积可以不用工作负载 ID直接指定组件。下面是几个我在实际项目中验证过的常见组件 ID组件 ID用途Microsoft.VisualStudio.Component.VC.Tools.x86.x64MSVC v143 编译器x86/x64核心中的核心Microsoft.VisualStudio.Component.VC.CMake.Project对 CMake 工程的 Visual Studio 集成支持Microsoft.VisualStudio.Component.Windows11SDK.26100Windows 11 SDK具体版本号会随官方迭代变化Microsoft.VisualStudio.Component.Windows10SDK旧版本 Windows 10 SDK版本号后缀可查官方文档Microsoft.VisualStudio.Component.VC.v143.x86.x64.Spectre带 Spectre 缓解措施的 MSVC 编译器Microsoft.VisualStudio.Component.VC.ATLATL 库写 COM/ActiveX 时用Microsoft.VisualStudio.Component.VC.MFCMFC 库做传统桌面应用时用注意Windows SDK 的版本号不是固定的。比如你需要 Windows 11 SDK 21H2 版本查到的可能是Microsoft.VisualStudio.Component.Windows11SDK.22000。所以在脚本里做好版本号变量化是明智的后面我会再提一次。3. 静默安装的第一步实操3.1 最小可用方案直接装 VC 工具集如果你只是想编点 C/C 代码最省心的命令是vs_BuildTools.exe --installPath C:\\BuildTools --quiet --norestart --wait --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended拆解一下这段命令的意图把安装路径固定到C:\BuildTools避免后续脚本里找路径到处猜。注意如果这条命令是放在 PowerShell 里执行C:\BuildTools的字符串转义要注意反斜杠有时会被解释成转义符。稳妥的做法是用--installPath C:\BuildTools配合单引号或者直接用C:\\BuildTools。在我实际使用中cmd 环境一般没问题PowerShell 环境就要多留个心眼。--quiet --norestart --wait是无人值守安装的三件套缺任何一个都可能导致脚本流程不可控。--add Microsoft.VisualStudio.Workload.VCTools是真正的安装目标。--includeRecommended会把该工作负载下的推荐组件一起装上实测下来这是最不容易踩坑的组合。因为你只装一个裸编译器后面编译时缺 Windows SDK 头文件、缺 MSBuild 的概率会很高排查起来很浪费时间。这条命令跑完你的 Build Tools 就基本是一个可以直接用的 C 编译环境了。第一次安装全过程大概 5 到 15 分钟具体取决于网络和机器性能。3.2 缩小体积只装编译器核心和指定的 Windows SDK如果你清楚自己只需要 cl.exe 和 link.exe不想要那么多附加工具可以用更细粒度组件vs_BuildTools.exe --installPath C:\\BuildTools --quiet --norestart --wait --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add Microsoft.VisualStudio.Component.Windows11SDK.26100 --add Microsoft.VisualStudio.Component.VC.CMake.Project从我实际安装后的观察来看这样装出来的占用空间通常会比--includeRecommended少好几个 GB。但代价是后面你如果发现自己需要 ATL、MFC、Spectre 缓解库之类的组件还得重新跑安装命令补装。所以我的经验是第一趟别省得太狠顺手把常用的都加上否则后面一次次补装时间成本远高于节省的磁盘空间。还有一个小细节如果机器上没装任何 Windows SDK编译器在编译标准头文件windows.h时会直接失败。所以 Windows SDK 组件要么靠工作负载的推荐项带上要么就单独指定。只装VC.Tools.x86.x64而不装 SDK 的做法我强烈不建议那会导致第一个测试程序就编译不过。3.3 安装日志和退出码到底怎么看静默安装最怕的就是静默到出错了你不知道。安装器会把日志写到临时目录通常是%TEMP%\dd_setup_时间戳\这类路径下文件名类似dd_setup_日期_时间.log。遇到安装失败第一件事不是重试而是去翻这个日志。另一个陷阱是退出码。--wait参数生效后进程退出码才有意义0 表示安装成功3010 表示安装成功但需要重启计算机才能完全生效其他非零值通常是失败我编写脚本时会显式判断退出码等于 0 或 3010 都算成功否则直接报错退出。很多新手只认 0结果遇到3010就开始疯狂重试这是很常见的问题。如果你用 PowerShell 写安装脚本可以这样处理$proc Start-Process -FilePath vs_BuildTools.exe -ArgumentList --installPath C:\BuildTools --quiet --norestart --wait --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended -Wait -PassThru if ($proc.ExitCode -eq 0 -or $proc.ExitCode -eq 3010) { Write-Host 安装成功无需重启或需重启。 -ForegroundColor Green } else { Write-Error 安装失败退出码$($proc.ExitCode) }这个模式在后续做自动化脚本时可以直接复用。4. 离线安装与 CI 集成4.1 用--layout制作离线安装源很多公司内网环境没有直接访问外网的权限或者网络带宽不稳定这时候在线安装会让人崩溃。微软官方支持的方式是用--layout参数先把完整的安装包下载到本地目录再在内网机器上从本地目录安装。制作离线源的命令如下vs_BuildTools.exe --layout C:\vc_layout --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --lang en-US这个命令会在C:\vc_layout下生成一个完整的安装缓存里面包含引导程序vs_setup.exe以及所有组件包。--lang en-US可以改换成zh-CN但注意如果只指定了英文生成的内容体积会更小因为语言资源包是分开下载的。制作离线源的时机也有讲究。最好在你能访问外网的机器上把整套组件一次性下载好然后再拷贝或分发给内网机器。网上很多人担心 vs_BuildTools.exe 在布局目录里是不是还是在线安装器会不会偷偷去访问外网。实际上--layout生成的特殊引导程序会优先从本地缓存读取组件不再需要联网。你要是不放心在内网机器上执行时可以用 --layout 参数再次指向同一目录加 --force 强制从本地缓存安装。4.2 从离线目录进行安装内网机器上进入布局目录执行vs_setup.exe --installPath C:\BuildTools --quiet --norestart --wait --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --nocache--nocache是我特意加的因为内网机器一般不需要保留组件包安装完就可以把缓存清理掉节省空间。但如果你想保留这些组件以便后续修改安装内容就别加这个参数了。这里有个经验点离线安装时除了安装器本身要完整的组件缓存本机还需要满足 Bootstrap 包的最低 Windows 版本要求。Build Tools 2022 对 Windows 10 及以上系统支持得比较好Windows 7/8 这类老系统装了也不是不能用但官方不会对老旧系统做太多兼容实测。如果团队里还有老系统的机器建议直接把 Build Tools 2019 和 2022 的安装包都准备好根据系统版本选择对应工具链。4.3 在 CI 任务里集成静默安装在 GitHub Actions 或者自建 GitLab Runner 上编译 Windows C 项目时Agent 默认环境未必有 MSVC。此时最好的方式是让流水线自己把 Build Tools 装好。GitHub 官方 Windows Runner 其实已经预装了大量 Visual Studio 工具但如果你用的是自建的裸机 Runner就需要这个安装步骤。一个可复用的 GitHub Actions 步骤可以长这样- name: Install MSVC Build Tools shell: pwsh run: | $installer $env:TEMP\vs_BuildTools.exe Invoke-WebRequest -Uri https://aka.ms/vs/17/release/vs_BuildTools.exe -OutFile $installer $proc Start-Process -FilePath $installer -ArgumentList --installPath C:\BuildTools --quiet --norestart --wait --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended -Wait -PassThru if ($proc.ExitCode -eq 0 -or $proc.ExitCode -eq 3010) { exit 0 } else { exit 1 }这里用了官方短链接aka.ms/vs/17/release/vs_BuildTools.exe。注意这个 URL 是 Visual Studio 官方安装器发布页的重定向入口你在国内访问海外官方源时如果出现网络慢或失败不要绕路去找第三方镜像。正确做法是走公司代理或提前在内网准备离线布局。这里我不展开网络层面的手段只提醒你第三方堆料源往往包含修改过的安装脚本风险极高坚持用官方入口或自己维护的离线源是底线。另外CI 里安装完之后后续步骤要用 MSVC 编译通常还需要执行vcvars64.bat来注入环境变量。因为每个 Runner 会话是干净的建议在同一个 PowerShell 会话里先调用cmd /c \C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat\ set把环境变量加载进来再跑编译否则 cl.exe 和 PATH 根本找不到。5. 安装完成后的验收工具链到底能不能用5.1 找到 cl.exe、vcvars64.bat 和 MSBuild安装路径如果指定为C:\BuildTools那么关键文件的位置是这样的编译器C:\BuildTools\VC\Tools\MSVC\版本号\bin\Hostx64\x64\cl.exe环境变量脚本C:\BuildTools\VC\Auxiliary\Build\vcvars64.batMSBuildC:\BuildTools\MSBuild\Current\Bin\MSBuild.exenmakeC:\BuildTools\VC\Tools\MSVC\版本号\bin\Hostx64\x64\nmake.exe你会注意到版本号是动态的比如 14.40.33807 这类。这就意味着直接用绝对路径调用 cl.exe 会比较脆弱正式的用法是先运行vcvars64.bat。这也是为什么每次编译前都要先加载工具链环境因为编译器会用到一堆通过环境变量传递的路径设置。5.2 写个 Hello World 实测编译安装完成后我习惯立刻做一次最小编译测试。新建一个hello.c#include stdio.h int main(void) { printf(MSVC Build Tools OK\\n); return 0; }然后在命令行里call C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat cl hello.c hello.exe第一次跑的时候几个可能踩到的点如果cl提示不是内部或外部命令说明vcvars64.bat没执行成功或者执行时路径不对。如果cl报 cannot open include file stdio.h说明 Windows SDK 没装全回到第 3 节补装组件。如果链接报错缺某个.lib先检查是否在 x64 的开发环境里。比如默认打开了 x86 环境去连一个 x64 的 lib就会报fatal error LNK1112。这一套流程走通说明 MSVC 工具链的核心链路没问题接下来才能放心跑更大的项目。5.3 让 CMake、Qt、FFmpeg 识别 MSVC 工具链CMake 想用 MSVC不是简单把编译器路径指给CC和CXX而是要让它跑在 Visual Studio 生成器环境下。比如cmake -G Visual Studio 17 2022 -A x64 ..CMake 会自查到 MSVC 环境生成对应的.sln工程。如果你是用 Ninja 生成器则必须先激活vcvars64.bat环境否则连 cl.exe 都找不到call C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat cmake -G Ninja -DCMAKE_BUILD_TYPERelease ..Qt 的场景更有代表性。假设你通过 Qt 在线安装器装了Qt 6.x MSVC 2019 64-bit套件那么 Qt Creator 里需要手动设置编译器。路径指向C 编译器C:\BuildTools\VC\Tools\MSVC\版本号\bin\Hostx64\x64\cl.exeC 编译器同样的 cl.exe调试器C:\BuildTools\VC\Tools\MSVC\版本号\bin\Hostx64\x64\下一般没有调试器调试器要用 Windows SDK 里的cdb.exe或者用 Visual Studio 自带的调试器。所以纯 Build Tools 环境下 Qt Creator 可以编译但调试体验比完整 VS 差一些。FFmpeg 编译也是类似的逻辑。先激活 vcvars64.bat再去跑 configure 和 make这样一来 cl.exe、nmake.exe、lib.exe 就都在 PATH 里了FFmpeg 的构建脚本也能正常识别 MSVC 工具链。很多 FFmpeg 编译报错追根到底就是环境变量没有加载而并不是 FFmpeg 源码本身的问题。5.4 和 MinGW 并存时的目录隔离如果你的机器之前装过 MinGW而且 PATH 里已经加了 MinGW 的 bin 目录那么用命令行编译时很容易出现编译器串台的问题。比如你明明想要 MSVC 的 cl.exe结果命令行优先命中了 MinGW 的 gcc 或者其他工具。解决办法很简单MSVC 的环境不要混进系统全局 PATH应该每次在需要的终端窗口里通过vcvars64.bat临时注入。这样既能保证 MSVC 工具优先级最高又不会影响平时用 MinGW 的终端。这是我个人在同时做 Qt 和 Win32 项目时摸索出来的最舒适的方案各位千万别图省事把两套环境的 bin 目录都加进系统 PATH。6. 配置和升级中的隐藏坑6.1 安装目录、磁盘占用和卸载残留Build Tools 安装器默认安装路径在C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools如果指定到C:\BuildTools反而更简单。但有个坑是如果你以后想用winget upgrade Microsoft.VisualStudio.2022.BuildTools升级winget 可能不认为C:\BuildTools下这套是它管理安装的升级时无法自动处理。所以如果你极度依赖 winget 做日常管理建议安装到默认路径。反过来如果你更看重脚本可控性用自定义路径反而很爽。两边都能用只是默认路径省心自定义路径更灵活。磁盘占用方面最小化安装大约 3~5GB加上推荐组件后有可能到 6~8GB。如果机器空间紧张可以先--layout下载到别的盘安装时间再清掉缓存。--nocache能在安装完成后自动删除缓存包这个参数在空间敏感环境里很救命。卸载残留也是个问题。Build Tools 卸载后如果还挂着 MSBuild、Windows SDK 等组件注册表和安装目录偶尔会有遗留。重装前最好先确认控制面板 - 程序和功能里已经没有对应条目再用--force修复或重装。彻底清理不是必须的但残留的组件 ID 信息可能会干扰下一轮安装校验。6.2 常见失败代码和解决思路命令行安装有时比 GUI 安装更容易翻车因为你看不到界面卡在哪。我见过的几个常见失败原因退出码非 0日志里报网络错误多半是下载中断或代理设置问题。解决思路是重新执行一次或者改用--layout离线方案。日志里反复出现同一个包下载失败通常是微软 CDN 在某些网络环境下不稳定。同样的提示优先重试而不是换下载源因为换源的合规和安全性无法保证。安装完成后编译时找不到 vcruntime 相关头文件说明 VC 运行时库组件没装全用--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --includeRecommended重新执行一次修复即可。安装时提示“另一个安装正在进行中”这是 Windows Installer 或 Installer 服务的会话锁等它结束或者关掉其他和 VS 安装器有关的进程再跑。遇到无法定位的错误最快的排查路径是去%TEMP%下面找最新的dd_setup_*.log搜索error、failed或exit code关键词通常能直接定位到具体的组件包。6.3 组件 ID 版本漂移问题微软对组件 ID 的更新不算频繁但也绝不老实。比如某个 SDK 版本退役后旧 ID 在安装器里可能依然能查到但下载的内容可能被替换成兼容版本而新 SDK 的 ID 后缀版本号变化很大脚本写死了就容易翻车。我的应对方法是在安装脚本里用一个常量文件专门维护组件 ID 列表升级的时候只改那一行同时在安装前跑一次vs_BuildTools.exe --help确认最小可用参数的名称没变。组件 ID 具体对应当前哪个版本去微软官方的“Visual Studio 组件目录”或“Visual Studio 工作负载和组件 ID”页面里查那里一直是唯一可信源。6.4 补装组件和更新工具链的姿势Build Tools 装完之后想补某个组件不需要卸载重装。直接重新执行安装命令换成要新增的组件 IDvs_BuildTools.exe modify --installPath C:\BuildTools --add Microsoft.VisualStudio.Component.VC.MFC --quiet --norestart --wait注意这里的动作是modify针对已安装实例做修改。如果你用的还是旧的引导程序直接再用一次--installPath --add也会进入修改模式效果一样只是我不知道它跑的是引导程序还是安装器逻辑。为了保险我一般用vs_installer.exe或vs_BuildTools.exe配合modify子命令这是官方支持的标准路径。工具链升级同理。Build Tools 内部组件版本如果过旧比如编译时遇到“请升级 MSVC 编译器”的警告你可以重新执行安装命令不加新增组件只更新已安装组件或者用--force强制刷新。升级完记得重新跑一次vcvars64.bat验证版本号确认工具链路径没被改。7. 一些建议命令行安装 MSVC Build Tools 这件事表面看只是敲了一条命令背后其实牵扯到组件管理、离线分发、CI 自动化和生态兼容。我踩过不少坑之后现在形成了一套自己的流程先在能联网的机器上用--layout把组件包下载好再分发到需要安装的机器上离线安装每台机器固定安装路径脚本里随时检查退出码和日志装完立刻用 vcvars64.bat 验证 cl.exe 和 Windows SDK。如果你只是偶尔编译点小项目直接最小化在线安装就够了但如果团队里多台机器都需要这个环境离线布局加统一脚本才是长期省事的方案。最后再分享一个小技巧把安装好的C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat创建成一个快捷方式放桌面上以后开新终端拉取环境只用双击一下省得每次手打路径。这样的小习惯能让你在 MSVC 和 MinGW 之间来回切换时少浪费不少时间。