信浮沉我见过太多人和 Visual Studio Code 的第一次交手，败在安装之后的半小时里。安装包下载下来了，双击也没报错，界面也打开了，但关了窗口想从终端敲一个 code 命令，系统直接提示“不是内部或外部命令”；等意识到环境变量没配上，又发现当初选 User Installer 还是 System Installer 时压根没在乎过。等终于能启动编辑器，打算配置 C 语言环境，才发现编译器版本、工作区、tasks.json 这些东西在欢迎页上根本没有解释。
这篇东西就是围绕“安装这个看似简单的动作”写的。很多教程会把下载、下一步、完成压缩成三段话，但现实里的安装问题往往出在细枝末节：架构选错、PATH 没勾、装完不知道如何验证、打开后不懂怎么开始写代码。我会把 Windows 下从官网下载到真正能跑 C 程序的前前后后讲完整，顺便把 Vue 开发、AI 插件、单片机扩展这类延伸场景里的安装思路串一下。刚接触 Visual Studio Code 的读者完全可以照做，已经装过但总觉得哪里不对劲的，也可以对照检查一遍。
1. 下载安装包之前，先花两分钟确认系统架构和安装模式
1.1 为什么我不建议从“高速下载站”拿安装包
Visual Studio Code 的官网地址是 https://code.visualstudio.com/，打开之后网站会根据你当前的操作系统自动弹出对应的下载按钮，Windows 用户看到的是一个 .exe 安装包。如果在搜索引擎里搜“vscode 下载”，前几条结果经常是各种“软件园”“高速下载站”，界面做得跟官网很像，但下载按钮绑定的是自家下载器，装完 VS Code 后顺带给你塞几个全家桶，这种事我在帮朋友清理电脑时见得太多了。
官网访问慢的时候，我的建议是换个网络环境稍后再试，或者直接复制官方下载链接到下载工具里。不要为了图省事去第三方站拿“绿色版”“精简版”，这类包经常缺失签名、更新困难，甚至被改过安装目录逻辑，出问题后排查成本很高。安装 VS Code 本身只要几十秒，真正需要警惕的不是速度，而是来源。
1.2 64 位、ARM64 还是 x64：一行命令看清 CPU 架构
下载页面上的版本一般会写 User Installer x64、System Installer x64，部分设备还会看到 ARM64 选项。多数人的电脑是 x64 架构，选那个写着 64 bit 的就行，但如果你用的是 Windows ARM 设备，比如一些骁龙处理器的轻薄本，下载 x64 版虽然也能运行，但属于模拟执行，安装没问题，性能和后续扩展的体验多少会打折扣。
想知道自己的电脑架构，最快的方式是按下 Win + R，输入 cmd 回车，在终端里执行：
bash复制echo %PROCESSOR_ARCHITECTURE%
输出是 AMD64 就下载 x64 版，输出是 ARM64 就下载 ARM64 版。注意这里 AMD64 说的不是 AMD 家的 CPU，它指的就是 x64 指令集，Intel 和 AMD 的处理器都适用。
提醒一句：32 位操作系统已经非常少见，VS Code 的 32 位安装包也基本退出下载页了。如果电脑内存只有 2GB 以下还在跑 32 位系统，建议先解决硬件或系统版本问题，否则即便装上 VS Code，打开稍微大点的项目也会被内存拖垮。
1.3 User Installer 与 System Installer 到底差在哪
官网同时提供两种 Windows 安装包，这是下载页面上最容易让人困惑的一对选择。
- User Installer：安装到当前用户目录下，默认路径是
%LOCALAPPDATA%\Programs\Microsoft VS Code。不需要管理员权限，安装完自动更新更顺畅，个人日常开发用这个最省心。 - System Installer：安装到系统盘的
Program Files目录里，需要管理员权限，安装后这台电脑上的其他 Windows 用户也能共用。适合公司统一管控或多用户机器，但代价是每次自动更新都可能触发 UAC 弹窗。
我的建议是：除非你明确需要“给这台机器的所有账户都装上”，否则一律选 User Installer。它在权限和更新体验上更轻盈，而且因为安装目录就在用户文件夹下，很多 VS Code 扩展在读写文件时不会碰到 Program Files 的权限限制。
官网还提供 .zip 便携版，解压后直接运行 Code.exe，配置和系统隔离，适合放在 U 盘里随身携带或者做离线部署。缺点是什么都要手动更新，而且不参与系统注册表项，右键菜单、PATH 都需要自己弄。
下面这张表可以帮你快速决策：
| 安装包类型 | 是否需要管理员权限 | 默认安装位置 | 适合场景 |
|---|---|---|---|
| User Installer | 否 | 当前用户 AppData 目录 | 个人日常开发 |
| System Installer | 是 | Program Files | 多用户共用机器 |
| zip 便携版 | 否 | 自行解压位置 | U 盘携带、离线部署 |
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装向导里的勾选项，每一个都值得认真对待
2.1 “加到 PATH”没勾，后面每天都会难受
VS Code 安装向导走到“选择其他任务”这一页时，会看到一组复选框，其中第一项通常写着“将‘通过 Code 打开’操作添加到文件资源管理器目录上下文菜单”，下面还有“将‘通过 Code 打开’操作添加到文件资源管理器文件上下文菜单”“将 Code 注册为受支持文件的编辑器”等。真正最关键的一项被放在列表偏下方，可能叫“添加到 PATH”。
PATH 是 Windows 查找可执行文件的路径集合。如果不勾选，VS Code 自身能用，但你在终端里执行 code 命令时，系统不知道去哪里找这个程序。日常使用中我习惯直接在 PowerShell 里 cd 到项目目录，然后敲 code . 打开整个工作区，少了 PATH 这一步，这个操作就废了，每次都得回到桌面双击图标再手动打开文件夹。
如果你已经漏勾了，不用重装。打开 Windows 的“编辑账户的环境变量”窗口，在用户变量里找到 Path 一项，检查里面有没有 VS Code 的 bin 目录。User Installer 默认对应的路径是：
text复制%LOCALAPPDATA%\Programs\Microsoft VS Code\bin
如果没有，手动新增这一行，然后重新打开终端让它重新加载环境变量。System Installer 则对应 C:\Program Files\Microsoft VS Code\bin，按实际安装位置调整。
2.2 右键菜单“通过 Code 打开”是高频入口
安装向导里还有两个看起来差不多的勾选项，一个是“将‘通过 Code 打开’操作添加到文件资源管理器目录上下文菜单”，另一个是“将‘通过 Code 打开’操作添加到文件资源管理器文件上下文菜单”。它们分别解决两类操作：
- 在文件夹上右键，菜单里直接出现“通过 Code 打开”，省去先启动编辑器再选文件夹；
- 在单个文件上右键，可以直接用 VS Code 打开该文件。
这两项我建议都勾上，对提高日常操作效率帮助非常大。它们的实际效果就是给 Windows 右键菜单增加两个入口，不涉及任何后台驻留或系统性能损耗，实在不想要随时可以从设置里移出。
2.3 注册为受支持文件的编辑器与资源管理器目录菜单
“将 Code 注册为受支持文件的编辑器”这一项，作用是让 VS Code 成为 .txt、.json、.js、.html、.py 等文件的默认打开程序。双击一个 .js 文件时，系统会直接用 VS Code 打开。
很多教程会把这个选项和“默认让 VS Code 打开所有代码文件”混为一谈，实际上它只影响注册表中 VS Code 支持的关联类型，不会强制接管你已经分配给其他编辑器的文件。即便勾了，也可以后续在 Windows 的默认应用设置里改回去。
至于“在 PATH 中安装”旁边的其他微调项，比如是否创建桌面快捷方式、是否添加“打开方式”菜单等，重要性偏低，按自己喜好选就行。有一点和建议：不要把每个复选框都无脑全勾，也不要把所有都取消。桌面图标本身不是必须，开始菜单里可以随时找到；但 PATH 和右键菜单这两项，属于框架级配置，不要跳过。
2.4 自定义安装路径时的两个注意点
VS Code 官方默认安装位置没有任何问题，没必要为了“整齐”强行改目录。如果你确实有把软件统一放 D 盘的习惯，有两点需要注意：
- 安装路径不要选在需要管理员权限才能写入的目录，比如
C:\Program Files下的子文件夹，除非你用的是 System Installer。 - 路径里的空格和中文其实都能正常工作，但我不推荐故意去放中文目录。个别命令行工具和执行脚本对非 ASCII 路径处理得并不好，尤其是你以后要在 VS Code 终端里调用编译工具链或包管理器，路径越简单越少踩坑。
我自己习惯把 User 版本装到 D:\dev\VSCode 这种纯英文短路径下。安装完之后到环境变量里看一眼 Path 是否自动出现了 D:\dev\VSCode\bin，确认无误再进下一步。
3. 装完别急着关闭：用三种方式确认 VS Code 已经就绪
3.1 命令行验证：code -v 是最快的试金石
安装成功后，有人喜欢双击图标，看到窗口弹出就说“装好了”。但这只能说明程序能启动，并不能证明它已经和系统命令行打通。真正规范的就绪检查，是打开一个新的 cmd 或 PowerShell 窗口，执行：
bash复制code -v
正常输出通常是一组版本号和编译信息，类似：
text复制1.96.2
c3f126316369cd610563c75b1b1725e0673adfb3
arm64
如果你执行后提示“code 不是内部或外部命令”，大概率就是上面说的 PATH 没有生效。先不要慌，重新打开一个终端窗口再试一次；如果还不行，检查环境变量列表里有没有 VS Code 的 bin 路径。环境变量修改后，已经打开的终端窗口不会自动刷新，必须开新窗口。
还有一个更带场景感的测试方法：先在某个练习目录里创建一个空文件夹，然后在终端 cd 进入它，执行 code .。此时应该弹出一个新的 VS Code 窗口，并且左侧资源管理器直接定位到这个目录。能完成这步，说明编辑器的命令行集成已经可用，后面使用终端进行 Git 操作、跑打包脚本、启动开发服务器时都会顺畅很多。
3.2 图形入口验证与首次启动可能遇到的问题
命令行确认没问题后，再从开始菜单或桌面图标启动 VS Code。首次打开的欢迎页会提供“新建文件”“打开文件夹”“克隆 Git 仓库”等快捷入口，左侧竖排的活动栏包含资源管理器、搜索、源代码管理、运行与调试、扩展管理等功能图标。
少数电脑会出现安装向导提示成功、但双击图标完全没反应的情况。这时候先别急着重装，打开终端执行：
bash复制code --disable-gpu
如果这样能启动，大概率是显卡驱动或 GPU 加速导致的兼容问题。可以更新显卡驱动，或者在 VS Code 启动参数里永久禁用 GPU 加速。另一个可能原因是旧的用户配置损坏，可以加 --user-data-dir 参数指定一个新的配置目录来验证：
bash复制code --user-data-dir=D:\temp-vscode-data
能正常启动，说明编辑器安装本身没问题，是用户配置或扩展拖了后腿。
3.3 验证扩展是否可安装，区分“安装成功”和“可以正常工作”
VS Code 的核心价值很大程度上靠扩展承载。安装完成后的最后一道验证，是打开扩展面板，搜索任意一个知名扩展，比如 Chinese (Simplified) Language Pack，点击安装。如果能顺利下载并启用，说明网络与扩展机制正常；如果点击安装后一直转圈，或提示无法连接到扩展市场，就需要检查系统代理设置、DNS 或网络环境。
这一步能区分两个概念：安装成功只是文件到位，可以正常工作则是扩展管理、外部命令、网络请求都走得通。建议从“装完 VS Code”到“开始写代码”之间，务必跑完命令行验证和扩展安装验证这两个动作，能在后续节省大量排查时间。
4. 第一次打开 VS Code：界面语言、中文插件和基础习惯
4.1 先装简体中文语言包
VS Code 默认界面是英文，如果英语不熟练，第一步应该把界面语言切成中文。在左侧扩展面板搜索 Chinese (Simplified) (简体中文) Language Pack，认准发布者为 Microsoft 的扩展，安装后右下角会出现“更改语言并重启”的提示，点击后整个界面就变成中文。
如果你想手动切换，可以使用快捷键 Ctrl + Shift + P 打开命令面板，输入 Configure Display Language，选择“中文(简体)”后重启。VS Code 的界面语言本质上只是用户配置里的一个 locale 字段，安装语言包之后切换非常轻量，不用重装软件。
顺带提一个点：微软在 VS Code 生态里还有几个扩展名称中包含 “Language Pack”，包括 French Language Pack、Japanese Language Pack 等，它们之间互不冲突。你只需要装简体中文那个，不需要把其他语言包一并收拾进去。
4.2 字体、自动保存和侧边栏
界面中文化之后，我建议先做三件小事，它们不会改变功能和逻辑，但会让之后的使用体验明显舒适。
第一，调整字号。打开设置界面（Ctrl + ,），搜索 editor.fontSize，把默认的 14 改到 16 或 18。新手的眼睛在长时间盯代码时很容易疲劳，大一号的字体会缓解很多。
第二，开启自动保存。在“文件”菜单里勾选“自动保存”。编辑文件后不用每次 Ctrl + S 手动保存，切到其他窗口时自动写入磁盘。写临时脚本或者记笔记时，这是非常实用的行为，也不用担心哪天忘记保存导致改动丢失。
第三，熟悉一下左侧的活动栏里每个图标的大致含义。从上到下依次是资源管理器、搜索、源代码管理、运行与调试、扩展。你不需要背诵每个功能，只要知道“打开文件找资源管理器、全局搜索用放大镜、Git 操作在源代码管理”这个基本对应关系就够了。
4.3 工作区到底是什么
VS Code 不像 Visual Studio 那样要求先“新建项目”。它默认以文件夹为单位工作：文件夹就是工作区，文件夹下的文件树直接显示在资源管理器里。
所以装完之后想写代码，正确的打开方式是先建立一个文件夹，比如 C:\dev\learn，然后通过“文件”>“打开文件夹”选中它，在这个窗口里新建 index.html、hello.c、test.py 都没问题。这也是为什么很多老手习惯用 code . 从终端打开当前目录——工作区模型极大降低了“从零开始”的心理门槛。
但也要注意，VB、Java 等传统 IDE 用户刚转到 VS Code 时，经常觉得“连项目都不能建，这编辑器也太简陋了”。其实是思维模式不同：VS Code 不强迫你按特定目录结构组织代码，它通过扩展和任务系统来适配不同语言的项目结构。理解了这一点，就不会在第一个窗口里不知所措。
5. 装完怎么用：用 C 语言环境配置跑通第一个最小程序
5.1 选择 MinGW-w64 并加到 PATH
安装 VS Code 本身不包含 C/C++ 编译器，所以很多人遇到的第一道坎就是“代码写好了，点运行却没反应”。处理思路是让系统里先有一个可用的 GCC 编译器。Windows 上最常见的选择是 MinGW-w64。
我推荐使用 WinLibs 或 MSYS2 方式安装。WinLibs 会提供一个绿色解压包，把它解压到例如 D:\mingw64，然后打开“编辑账户的环境变量”，在 Path 中新增一行：
text复制D:\mingw64\bin
保存后开一个全新的终端窗口，执行：
bash复制gcc -v
能看到类似 gcc version 13.x.x 的输出，说明编译器就绪。注意一定要开新窗口，旧终端读不到刚改的环境变量。
5.2 用三个文件搭出可运行的最小工程
我这里刻意不引入 tasks.json 和 launch.json，因为对刚装完编辑器的人来说，配置这两个文件的挫败感太强。先用最笨但最可靠的方式跑通：
第一步，在 VS Code 里新建文件，保存为 hello.c，写入：
c复制#include <stdio.h>
int main() {
printf("Hello, VS Code\n");
return 0;
}
第二步，按下 Ctrl + \`` 打开 VS Code 内置终端，确认当前路径已经停留在 C 文件所在目录。如果不在，先用 cd` 切过去：
bash复制cd C:\dev\learn
第三步，执行：
bash复制gcc hello.c -o hello.exe
编译成功后，继续执行：
bash复制hello.exe
如果控制台输出 Hello, VS Code，整个 C 语言最小闭环就走通了。
这里不配置调试器的原因很简单：新手阶段先理解“源码 — 编译 — 运行”的链条，比直接按 F5 看魔幻结果更重要。等你能熟练使用终端编译，再引入 C/C++ 扩展的 tasks 和调试配置，会顺畅得多。
5.3 C 程序编译常见问题
实际跑的过程里最常碰到三类报错，我按出现频率排一下：
- 提示
gcc不是内部或外部命令。这依旧是 PATH 没生效，回到 5.1 检查编译器路径。 - 编译时找不到
stdio.h，通常是 MinGW 解压不完整或路径包含空格导致 include 路径没识别。重新解压到纯英文短路径能解决大部分问题。 - 控制台输出的中文变成乱码。多半是源码文件保存为 UTF-8，而 Windows 默认控制台代码页是 GBK。可以在终端执行
chcp 65001切到 UTF-8，再重新运行编译产物。
我把 C 语言放在安装教程的场景里讲，是因为它最能检验“安装”这个概念的完整性。VS Code 本身只是编辑器，配合编译器才能在 C 语言开发上工作；如果你以后准备写 JavaScript 或 Python，逻辑也是一致的：编辑器负责编辑，运行环境负责解释执行。
6. 从安装到开发场景：前端与嵌入式的两个延伸方向
6.1 Vue 项目必装插件清单
VS Code 装好之后，很多人第一个真正要面对的项目可能是 Vue 前端。默认状态下，.vue 文件没有语法高亮，代码提示也约等于零。你需要打开扩展面板，安装如下扩展：
- Vue - Official：Vue 3 的官方语言支持扩展，2024 年以前叫 Volar，现在官方推荐的名称是 Vue - Official，提供模板表达式提示、组件属性补全和类型检查。
- ESLint：项目代码里只要有
.eslintrc或eslint.config文件，安装它后会在编辑器里直接标红不符合规范的代码。 - Prettier - Code formatter：统一格式化代码风格。建议在设置里开启
editor.formatOnSave，这样每次Ctrl + S会自动整理格式。 - Auto Rename Tag：修改 HTML 或 Vue 模板的开始标签时，自动同步修改对应的闭合标签。
- Path Intellisense：补全 import 和 url 中的文件路径，减少手打路径的笔误。
这些扩展和 Vue 项目本身是两回事，不要指望装完插件就能自动生成项目。实际开发时，你仍然需要先把项目目录通过“文件”>“打开文件夹”加载进 VS Code，然后在终端里执行 npm install 安装依赖，最后运行 npm run dev 启动开发服务器。
6.2 STM32CubeIDE for VS Code 与 Keil 工程导入的背景
热搜词里有个相对进阶的方向，是在 STM32CubeIDE for Visual Studio Code 中导入 Keil 工程。这里简单说明一下背景和边界。
ST 官方已经推出基于 VS Code 的 STM32 开发扩展包，试图把单片机开发流程整合进 VS Code，包括工程生成、编译、烧录和调试。你可以通过扩展面板搜索 STM32 相关扩展来安装。不过它和纯网页前端项目的“装完扩展就能用”不一样，单片机平台大多依赖 ARM 编译工具链、调试器驱动和 STM32CubeCLI，装扩展只是第一步，接下来要花时间配置工具链路径和设备描述文件。
至于“从 Keil 导入工程”，本质是让 VS Code 理解 Keil 使用的工程文件格式与构建命令。大多数情况下，直接拿一个 .uvprojx 文件丢给 VS Code，并不会自动变成可编译任务，而需要先完成工程结构的适配和工具链映射。这个方向适合已经会使用 Keil、对构建系统有基本概念的读者继续研究；如果刚接触 VS Code，建议还是从 5.2 节那种简单 C 工程起步，先把编辑器、编译器和终端之间的关系理顺。
6.3 AI 编程助手插件的安装位置与 API Key 配置
最近很热的话题是把 Claude Code、Codex 这类 AI 编程助手接到 VS Code 里。大体逻辑是：打开扩展面板，搜索对应名称的官方扩展，安装后用命令面板唤出登录或配置入口，填入你自己的 API Key 或完成 OAuth 登录，就能在侧边栏或编辑区调用 AI 能力。
我自己使用时的建议是：API Key 这类敏感信息，不要直接写进项目里的 .vscode/settings.json，更不要提交到 Git 仓库。优先使用系统环境变量，或者扩展自身的密钥管理配置项，很多翻车现场都是把密钥写死在前端代码里导致泄露。如果你同时装了多个 AI 扩展，注意它们在命令面板里的快捷键会不会冲突，比如默认的 Ctrl + I 在某个版本里可能被多个扩展争用，遇到冲突时手动改掉其中一个就行。
从“安装 VS Code”到“配置 AI 编程助手”，中间隔着大量基础设置，但对新手来说，最有价值的路径不是一开始就追求最全的配置，而是先确保编辑器能启动、命令行能调用、代码能跑起来。把这三点像地基一样打牢，后面每加一层扩展、每换一个新场景，都是在已有的稳定框架上做增量，而不是反复推倒重来。