老有人问这个问题我只是想用 MSVC 编译 C/C 代码为什么要逼着我装一个好几个 GB 的 Visual Studio如果只是跑一下命令行编译、配个 CI、或者让 CMake 有一套干净的 Windows 原生工具链确实是没必要装完整 IDE 的。微软也一直提供独立的 Build Tools 分发包可以只装编译器、链接器、Windows SDK 和标准库头文件整个过程比很多人想象中简单但坑也是有的。这篇文章就专门写清楚Windows 上如何只安装 MSVC 而不安装 Visual Studio从原理、版本选型、图形界面安装、命令行自动化安装到装完之后如何配置环境变量和使用 CMake最后再整理几个我实际踩过的坑。内容很长建议先收藏再慢慢看。1. 为什么能“只装 MSVC”先说清楚 Build Tools 是什么1.1 MSVC 不是一个“软件”而是一套工具链先说点背景。MSVCMicrosoft Visual C严格来说不是某个单独的 exe而是一整套编译工具链的统称主要包括这些组件cl.exeC/C 编译器本体负责把源码编译成目标文件.obj。link.exe链接器负责把目标文件、静态库、动态库链接成 exe 或 dll。nmake.exeMake 工具对应 Makefile 里的 nmake 语法。ml64.exe/ml.exe汇编器编译汇编代码文件。lib.exe静态库管理工具。Windows SDK 头文件、库文件例如windows.h、kernel32.lib、user32.lib等。C/C 标准库MSVC STL对应vcruntime、msvcp系列运行时库。平时我们安装 Visual Studio其实就是在安装 IDE 外壳的同时附带安装了这么一整套工具链。而微软把这一整套工具链单独打包成了“Build Tools for Visual Studio”你安装它就是在不装 IDE 的情况下获得 MSVC 编译环境。所以“仅安装 MSVC”的本质就是安装Build Tools for Visual Studio。1.2 Build Tools 与 Visual Studio 在底层上是同源的有个很容易搞混的点Build Tools 并不是一个功能阉割的替代品它里面装的cl.exe、link.exe和你完整安装 Visual Studio 之后调用的那一套是完全相同的。唯一的区别就是没有那个图形界面的 IDE没有解决方案资源管理器、没有调试器 UI、没有代码编辑器的各种智能化功能。所以在很多自动化场景里Build Tools 是比完整安装 Visual Studio 更合适的选择CI/CD 流水线在 GitHub Actions、Jenkins、Azure Pipelines 等环境里构建 C/C 项目只需要能编译、能链接、能跑测试不需要 IDE。本机手动编译少量代码比如你只是要编译某个开源库的源码cl一把梭就够了。搭配其他编辑器你习惯用 VS Code、CLion、Vim或者公司有统一风格要求就不需要厚重的 IDE。服务器环境Windows Server 上部署编译服务装 Visual Studio 不合适Build Tools 更干净。那什么情况下不建议这么做如果你需要开发、调试、断点查看、性能剖析等完整 IDE 能力或者需要 C# / VB.NET / F# 等非 C 场景Build Tools 就不适合。Build Tools 并不包含 .NET 编译器.NET 开发还是得走完整 Visual Studio 或者单独的 .NET SDK。提示Build Tools 官方支持 C 开发但如果你只是为了编译 C# 程序直接装 .NET SDK 更轻量。2. 安装方式与版本选型动手前先确定方向2.1 支持哪些版本选哪个MSVC 工具链的版本号很绕。先说结论2024 年以后的正常新项目建议直接用Visual Studio 2022 Build Tools全称Build Tools for Visual Studio 2022。它支持 Windows 10/11编译出来的程序兼容性也最好社区生态和 CMake 支持都非常成熟。这里有个非常容易误解的点VS 2022 Build Tools 里的 MSVC 编译器版本并不叫 2022它的编译器内部版本号是 C/C 编译器19.3x系列对应的_MSC_VER宏是 1930 到 1940 左右的范围。你可能会看到cl.exe输出的版本是 “Microsoft (R) C/C Optimizing Compiler Version 19.40”这没问题它对应的就是 VS 2022 的工具集。如果你在用的是老项目需要匹配旧版的 Platform Toolset那就要注意了需求场景推荐安装包新项目、新学习、CMake 构建Build Tools for Visual Studio 2022维护老代码需要 VS 2019 工具集Visual Studio 2019 Build Tools需要 VS 2017 工具集兼容Visual Studio 2017 Build Tools老版本不建议新装只需要 Windows SDK 和库不编译 C单独安装 Windows SDKBuild Tools 也允许你通过 VS Installer 勾选多个版本的 MSVC 工具集。比如你在安装 VS 2022 Build Tools 时可以在单个组件里勾选 “MSVC v143 - VS 2022 C x64/x86 生成工具”也可以额外勾选 “MSVC v142 - VS 2019 C x64/x86 生成工具”。这样同一个 Build Tools 里就能同时存在两套编译器老项目新项目都能编。2.2 安装包怎么下载下载地址务必认准微软官方的 Visual Studio 下载页面而不是第三方站点。你只需要找到 “所有下载” 或 “工具” 区域里面有一项叫“Visual Studio 2022 生成工具”或者英文版叫 “Build Tools for Visual Studio 2022”。它的文件名形如vs_BuildTools.exe这个 exe 本身很小只有几 MB它只是一个引导安装器。真正的大头几百 MB 到几 GB 的组件会在安装过程中按需下载。所以下载vs_BuildTools.exe很快安装过程耗时才比较长。2.3 架构选择x64 还是 x86这里说的不是安装包架构而是你要编译出的目标程序架构。Build Tools 本身支持一个安装包包含 x86、x64、ARM、ARM64 的编译器和链接器。在安装组件时你会看到MSVC v143 - VS 2022 C x64/x86 生成工具MSVC v143 - VS 2022 C ARM64 生成工具如果你是编译本机 Windows x64 程序勾选第一个就够了。如果你还需要交叉编译 32 位程序那个 x64/x86 的包通常同时包含 x86 和 x64 的本地工具覆盖大多数场景。我自己实际安装时选的是 “使用 C 的桌面开发” 工作负载然后在右侧单个组件里关掉了很多用不到的东西比如测试工具、C MFC、C ATL 等。如果你对组件不太熟直接勾选 “使用 C 的桌面开发” 也行它会带上大部分 C 开发需要的默认组件。注意不要图省事把 “使用 C 的桌面开发” 整个删减到只剩编译器。测试工具、CMake 工具等组件很多项目构建时会隐式依赖。3. 实操从零开始装好一套干净 MSVC 环境3.1 图形界面安装流程第一步双击下载好的vs_BuildTools.exe。如果弹 UAC 授权窗口点 “是”。第二步进入 Visual Studio Installer 的组件选择界面。这时候你会看到一个类似完整 VS 的安装界面但它不会安装 IDE。在 “工作负载” 标签页里选择 “使用 C 的桌面开发”。第三步右侧 “安装详细信息” 面板里建议确保这几项是被勾选的MSVC v143 - VS 2022 C x64/x86 生成工具Windows 11 SDK或 Windows 10 SDK视系统而定C CMake tools for Windows如果你要用 CMake适用于最新 v143 生成工具的 C ATL可选一般不需要C AddressSanitizer可选调试某些问题时有帮助如果只是最精简的编译环境也可以只勾 “MSVC v143” 和 “Windows 11 SDK”其余全部不选。但如果你想省事一点建议至少加上 CMake tools因为现在大量开源项目都用 CMake 构建后面省得再手动装。第四步点击右下角 “安装”等待下载和安装。整个过程耗时取决于网速通常在 5 到 30 分钟之间。安装完成后不需要打开任何 IDE也不需要登录账号。直接进入下一步验证。3.2 命令行静默安装如果你的机器要批量安装或者只是维护一个干净环境命令行方式更高效。vs_BuildTools.exe支持各种参数vs_BuildTools.exe --installPath C:\BuildTools --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --quiet --wait解释一下参数--installPath指定安装目录。注意这个目录不能和任何已安装的 Visual Studio 实例重复建议用独立的目录如C:\BuildTools。--add Microsoft.VisualStudio.Workload.VCTools添加 C 工具负载。--includeRecommended包含该负载的推荐组件相当于图形界面里默认打勾的那些。--quiet静默模式不显示 UI。--wait让命令行进程等待安装完成这样脚本能正确拿到退出码。你还可以用--add多次添加单个组件例如--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add Microsoft.VisualStudio.Component.Windows11SDK.22621这样能用更精确的粒度来控制要装什么体积也更小。装完之后脚本退出码为 0 说明安装成功非 0 则失败。这个在 CI 自动化里非常常用。我用这个方式在好几台云服务器和 TeamCity 构建代理上装过 MSVC 环境比每次都开图形界面点要稳定得多。缺点是一次性安装参数写错后排查会稍微麻烦一些所以我建议先用图形界面手动装一次熟悉组件 ID再写自动化脚本。3.3 安装完成之后目录结构长什么样安装完成后你的工具链默认分布在两个地方编译器和标准库C:\BuildTools\VC\Tools\MSVC\版本号\Windows SDK通常装在C:\Program Files (x86)\Windows Kits\10\版本号是一个类似14.40.33807的目录名里面还能看到bin\Hostx64\x64\cl.exe、include、lib等子目录。这个目录结构很有规律以后排查找不到编译器时先来这里找。4. 装好之后怎么用环境变量、CLion、VS Code 与 CMake4.1 vcvars64.batMSVC 环境的关键入口MSVC 不像 GCC 那样装完直接往 PATH 里扔一个gcc。如果你直接打开 cmd 敲cl大概率会提示 “不是内部或外部命令”。这是 MSVC 的既定设计不同架构、不同安装目录下环境变量都不同所以它提供了一个批处理脚本来统一设置环境。这个脚本就藏在安装目录下C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat想开一个能直接用cl的终端先运行call C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat运行完之后再敲cl就能正常输出版本信息了。这个脚本会临时设置 PATH、INCLUDE、LIB 等环境变量所以你不必手动去配置系统全局 PATH也最好不要去配。因为 MSVC 的环境变量是按架构区分的全局固定 PATH 容易搞乱。提示vcvars64.bat适合 x64 原生编译如果你需要编译 32 位程序用vcvars32.bat要搞 x64 交叉编译 x86 或 ARM还有vcvarsx86_amd64.bat等变体。4.2 第一个程序的完整编译实测新建一个hello.c#include stdio.h int main(void) { printf(Hello MSVC without Visual Studio!\n); return 0; }在已经加载过vcvars64.bat的 cmd 里执行cl hello.c正常情况下你会看到cl.exe输出一行版本信息然后生成hello.exe。直接运行它就能看到打印结果。如果想编译 C 和链接动态库建议用cl /EHsc开启 C 异常处理例如cl /EHsc /std:c20 hello.cpp/std:c20是 MSVC 指定 C 标准的参数如果你要 C17 就写/std:c17。4.3 让 CMake 找到 MSVC单独敲cl只是开胃菜真正高频的场景还是 CMake。CMake 找编译器的方式和平台关系很大分两种情况。情形一你从 Visual Studio Command Prompt 或加载过 vcvars64.bat 的终端里运行 cmake这时候 CMake 会直接继承现有的环境变量自动找到 MSVC。比如cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPERelease cmake --build build情形二你在普通命令提示符或 PowerShell 里运行 cmake这种情况下 CMake 默认会尝试找 Visual Studio 实例如果系统里装了 Build ToolsCMake 有能力自动发现它。但 CMake 的自动发现依赖 Visual Studio Installer 在注册表里写入的 instance 信息。Build Tools 装完后同样会写这个信息所以多数情况下能被找到。为了保险你也可以显式指定 CMake 的生成器或者直接指定编译器和工具链cmake -S . -B build -G Visual Studio 17 2022 -A x64用-G Visual Studio 17 2022会让 CMake 生成一个 Visual Studio 解决方案.sln。虽然你没有装 Visual Studio IDE但 CMake 生成的 sln 可以用MSBuild.exe来构建。Build Tools 里带了MSBuild.exe它完全可以构建 sln 工程只是没有图形界面而已。这种用法在 CI 上很常见。如果你更习惯 Ninja也可以指定cmake -S . -B build -G Ninja -DCMAKE_C_COMPILERcl -DCMAKE_CXX_COMPILERcl前提是你已经在一个加载过 MSVC 环境的终端里。4.4 在 VS Code 里配置 C/C 开发VS Code 配合 C/C 扩展是一个非常轻量又舒服的选择。装好 Build Tools 之后不需要再装任何插件来模拟编译器只需要在 VS Code 里正确指向编译器路径即可。C/C 扩展的c_cpp_properties.json里compilerPath可以设置成{ compilerPath: C:/BuildTools/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe }不过这个路径里的具体版本号每次升级都会变比较麻烦。更省事的办法是直接用“Developer Command Prompt”或“Developer PowerShell”启动 VS Codecall C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat code .这样 VS Code 继承的环境里已经有完整的 INCLUDE 和 LIBC/C 扩展会自动检测到 cl.exe根本不用手动配置路径。我在几台机器上都是这么干的升级 MSVC 组件后也不受影响。CLion 用户同理Toolchain 里选择 Visual Studio会自动检测到 Build Tools 安装实例。如果检测不到再手动指定vcvars64.bat所在路径。5. 可能踩的坑高频报错与排查思路5.1 “Cannot open include file: stdio.h: No such file or directory”这个报错几乎每个刚装完 Build Tools 就手动敲cl的人都会遇到。原因很简单你直接运行了cl.exe但它不知道系统的 INCLUDE 路径在哪里找不到 C 标准库头文件stdio.h和windows.h等。解决办法就是在使用前先加载vcvars64.bat。如果加载了依然报错先确认你的 Build Tools 安装目录是不是包含 Windows SDK 组件。有时候你只勾了 MSVC 工具集没有勾 Windows SDK就会导致标准库头文件不完整。图形界面里重新运行安装器添加 “Windows 11 SDK” 或 “Windows 10 SDK” 组件后再试。5.2 “LNK1104: cannot open file kernel32.lib”链接阶段的报错本质和上一个类似LIB 环境变量缺失。kernel32.lib位于 Windows SDK 的 lib 目录下。加载 vcvars64.bat 之后会自动设置如果还是报这个错多半是 SDK 组件没装或者安装的是 SDK 但 vcvars64.bat 没有正确识别。重新检查 SDK 组件是否选中。5.3 Build Tools 安装到一半提示“无法安装”常见原因有两个。一个是磁盘空间不足Build Tools 完整安装占用可能超过 6 GBC 盘如果剩不到 10 GB 容易中途失败。另一个是旧版本 Visual Studio Installer 的残留问题比如之前装过 VS 2019 又卸载不干净。排查步骤打开C:\Program Files (x86)\Microsoft Visual Studio\Installer运行setup.exe强制更新 Visual Studio Installer 到最新版。清理%TEMP%目录。尝试用管理员身份重新运行vs_BuildTools.exe。如果依旧失败可以在安装命令行里加--force参数部分版本支持不一定保证成功。5.4 编译出的程序在其他电脑上运行报缺少 DLLMSVC 编译出的 exe 默认可能依赖动态运行库VCRUNTIME140.dll、MSVCP140.dll。目标机器没装 VC Redistributable 就会报错。解决办法有两种编译时使用静态链接运行库MSVC 中对应/MT参数Release或/MTdDebug。这样 exe 会包含运行时库不需要目标机器额外装依赖。也可以发布安装包时带上 “Microsoft Visual C Redistributable” 安装包在目标机器上装一次。在 CMake 里对应参数是set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)不过要小心静态链接运行库会让代码里如果同时混用了不同版本的 CRT可能出现内存分配释放不匹配的问题。常规小工具用/MT省心大型库项目要看上游是否支持静态 CRT。5.5 想卸载 Build Tools 却找不到入口由于 Build Tools 没有 GUI很多人卸载时不知道去哪里。正确方式仍然是使用 Visual Studio Installer。如果你当初安装时保留了 Visual Studio Installer打开它找到 “已安装” 列表里的 “Visual Studio Build Tools 2022”点 “卸载” 或 “修改”。如果你不小心把 Visual Studio Installer 也删了可以去微软官网重新下载vs_BuildTools.exe或vs_installer.exe它会自动进入修改/卸载界面。5.6 一个隐藏坑PATH 里同时有 MinGW 的 gcc 和 MSVC这是很多混合环境用户会遇到的问题。如果你之前装过 MinGW-w64它的gcc.exe在 PATH 里而 MSVC 的cl.exe不在 PATH需要 vcvars64.bat 临时加入那么 CMake 在普通终端里跑的时候大概率会优先用 MinGW生成 Makefile 或用 Ninja 进行 GCC 编译而你本意是想用 MSVC。解决办法在需要 MSVC 的终端里先加载 vcvars64.bat 再执行 cmake并且用-G参数明确指定生成器或者直接给 CMake 传-DCMAKE_C_COMPILERcl -DCMAKE_CXX_COMPILERcl。5.7 MSVC 与 MinGW 的区别速查既然热词里也总在对比 MSVC 和 MinGW我顺带整理一下帮助边用边判断对比项MSVC (Build Tools)MinGW-w64 / GCC编译器cl.exegcc.exe / g.exe默认 ABIMSVC ABI和 Windows 原生库兼容好GNU ABI大量开源库直接源码编译也能跑标准库MSVC STLlibstdcGCC依赖运行时VCRUNTIME/MSVCP DLL可静态链接libgcc/libstdc DLL也可静态链接调试器生态Windows 下常配合 VS 调试器或 WinDbgGDB 生态更通用CMake 支持可用 Visual Studio Generator 或 Ninja可用 MinGW Makefiles 或 Ninja对 Windows SDK 的兼容官方支持最优先兼容性尚可有时会有宏定义差异适合场景Windows 桌面专属、调用 Win32 API、微软生态跨平台可移植、开源项目、Linux 习惯如果你主要是做跨平台项目源码里用了很多 GCC 特性比如__attribute__、特定内联汇编语法那么 MSVC 会遇到编译错误这时要么加兼容宏要么直接用 MinGW。反过来说如果你要调用 DirectX、Windows 原生 SDK 等 APIMSVC 更稳。6. 一次完整的自动配置脚本从零到 CMake 构建最后分享一份我常用的 PowerShell 脚本它可以在干净的 Windows 机器上静默安装 Build Tools 并构建一个 CMake 项目非常适合拿到新机器后一键初始化环境。脚本里用到了最精简的组件 ID适合 CI/CD# 1. 下载引导安装器 Invoke-WebRequest -Uri https://aka.ms/vs/17/release/vs_BuildTools.exe -OutFile $env:TEMP\vs_BuildTools.exe # 2. 静默安装 C 工具链和 Windows SDK $args ( --installPath, C:\BuildTools, --add, Microsoft.VisualStudio.Workload.VCTools, --includeRecommended, --quiet, --wait, --norestart ) $process Start-Process -FilePath $env:TEMP\vs_BuildTools.exe -ArgumentList $args -Wait -PassThru if ($process.ExitCode -ne 0) { Write-Error Build Tools 安装失败退出码: $($process.ExitCode) exit 1 } # 3. 在子进程中加载 vcvars64.bat 然后执行 cmake 构建 $cmd call C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPERelease cmake --build build cmd /c $cmd注意--wait参数必须和-Wait配合否则 PowerShell 脚本会在安装完成前继续执行导致后续找不到编译器。这是我实际踩过的一个坑。提醒上面脚本里的vcvars64.bat路径是默认安装目录。如果你自定义了--installPath脚本路径也要改。在 CI 里还有更规范的做法直接用ilabs.vswhere这类工具去查找安装实例自动解析对应的vcvars64.bat路径而不是硬编码C:\BuildTools。但硬编码在小范围自用场景里最直观没毛病。7. 最后的几个小建议根据我多次在纯净 Windows 环境、云服务器上安装 MSVC 的经验再说几个细节操作习惯优先使用 vcvars64.bat不要手动改系统环境变量。我见过一些人为了让cl全局可用把 MSVC 的 bin 目录直接加到系统 PATH 里结果要么是找不到头文件要么就是升级工具链后路径失效。vsvars 脚本就是微软设计的正统用法每次开一个编译终端执行一下成本很低。安装时磁盘空间给足。我建议至少预留 10 GB 以上别只看下载体积。实际安装后包含工具链、SDK、缓存占用比你想象的大。养成看 clang-cl 的习惯。Build Tools 里还自带clang-cl.exe它本质上是 LLVM 的 clang 编译器但接受了 MSVC 风格的命令行参数并能复用 MSVC 的头文件和库。如果你想在保留 MSVC 生态的同时用上 clang 的诊断信息可以试试。用法上也是先加载 vcvars64.bat然后clang-cl /std:c20 hello.cpp编译完的产物和cl生成的没本质区别。升级时使用 Visual Studio Installer 定期检查。Build Tools 的更新逻辑和 Visual Studio 一样都是在安装器里点 “更新”千万别跑到官网手动下载新版本装到另一个目录否则机器上会有两套 MSVCCMake 偶尔会选到旧版后期很头疼。现在你可以在不碰 Visual Studio IDE 的情况下用上完整、干净的 MSVC 工具链了。装完之后建议先跑一个最简单的 hello world再跑一次 CMake 构建确认整条链路没问题再开始正式项目。如果还有安装或使用上的具体报错欢迎对照上面第 5 节逐条排查。