桃子胖VS Code安装这件事，光看标题会觉得有什么好写的？下载、下一步、完成，三分钟搞定。但实际接触下来，我见过太多人在第一步就卡住：官网下载慢到怀疑人生、装完没有右键菜单、远程连服务器报 failed to fetch、配 Python 解释器找不到环境、C++ 调试一运行就提示 launch program does not exist。这些坑单拎出来都不大，但凑在一起能把一个下午全耗掉。这篇东西不打算给你复读一遍安装向导截图，而是把 VS Code 从下载到日常开发环境搭好这条路上最容易出问题的点，逐个拆开讲清楚，顺便把最近大家问得最多的一些玩法也串进来。不管你是刚入门的萌新，还是想快速搭好 Python、C++、Java 环境的折腾党，又或者正在研究怎么把 Claude Code 接进 VS Code 用本地 Ollama 模型，这篇文章应该都能对得上。
1. 装之前先把版本看清楚，后面能少走弯路
1.1 Stable 和 Insider，选 Stable 就对了
VS Code 官网首页只有一个显眼的下载按钮，但稍微往下翻点，会发现还有 Insiders 版本。很多人会手滑装成 Insiders，或者被某些教程带着去尝鲜。这里直接给结论：日常使用、写作业、做项目，一律用 Stable 版。Insiders 是每天更新的预览版，功能确实走在前面，但稳定性没法保证，插件兼容性也经常出幺蛾子。我曾经在 Insiders 上遇到过格式化插件直接罢工的情况，折腾半天发现是预览版改了底层接口，换回 Stable 一切正常。
官网会自动检测你的操作系统，Windows 用户进去大概率看到的是 Windows User Installer。这个后面细说，先记住一点：如果不是系统管理员且不需要给所有账号装 VS Code，用 User Installer 是最省心的选择。macOS 用户下载 zip 包解压就能用，把 Visual Studio Code.app 拖进 Applications 文件夹就完事。Linux 用户有 deb 和 rpm 两种包，也可以用 Snap 装，个人体验是 deb 包最稳，少一些权限和沙箱方面的奇怪问题。
1.2 User Installer 和 System Installer 的区别
Windows 下这两个安装在本质上的作用是区分用户级和系统级。User Installer 只装在当前用户目录下，不需要管理员权限，不会弹 UAC 确认框，而且安装路径在 %LocalAppData%\Programs\Microsoft VS Code。System Installer 则是传统方式，装到 Program Files 下，环境变量写入系统级，所有 Windows 账户都能用。
日常个人电脑强烈推荐 User Installer，因为 VS Code 更新频率太高了，几乎每个月都要来一版，用户级安装没有权限卡脖子的问题，更新流程顺滑很多。公司电脑如果统一用管理员账号管理，System Installer 也问题不大。另有一个实际问题：仓库里下载的 VSCodeUserSetup-x64 这类文件，双击后默认是不勾选“添加到 PATH”的，很多人装完发现终端敲 code 命令无效，就是漏了这个点，后面安装选项部分会重点提。
1.3 下载慢和失败的处理思路
官网下载慢是国内的常态问题，这个不是 VS Code 本身的问题，而是官方 CDN 在部分地区速度不太理想。如果你遇到下载卡住或者文件一直拿不到，可以考虑几个思路：一是换时间段重试，避开晚高峰；二是去微软官方 GitHub Releases 仓库找对应版本的安装包，那个下载通道通常更稳；三是用浏览器插件或下载工具做普通的多线程下载，不要挂什么乱七八糟的加速器，反而容易下一半断掉。下载完成后建议先校验一下文件大小和官网标称是否一致，如果差得多，直接删掉重新下载，别凑合用，安装包损坏会带来各种诡异问题。
另外穿插一个最近很常见的问题报错：正在下载 VS Code 服务器 卡住，或者直接报 localdownloadfailed (failed to fetch)。这个场景基本出现在你用 Remote-SSH 连远程 Linux 服务器的时候。VS Code 的远程开发机制是：本地客户端连上服务器后，会自动在服务器端下载一个 vscode-server 组件，然后真正的插件、语言服务都在远端跑。下载失败常见原因是远端服务器访问微软官方下载地址超时。最省事的解决办法是手动下载对应的 vscode-server 包，传到服务器上解压到目标目录。具体方法后文操作实操章节展开，这里先有个概念就行。
提示：装 VS Code 本体和配置远程开发是两件事。很多人把远程连不上归咎于安装有问题，其实本体装得再顺，Remote-SSH 组件的下载逻辑一样会卡网络。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装过程哪些选项必须勾，哪些可以忽略
2.1 Windows 安装向导关键选项逐个过
双击安装包进入向导，一路 Next 到最后会看到“选择附加任务”这一步，这里的勾选项直接决定了装完后的使用体验。
- 创建桌面快捷方式：按个人习惯，我一般勾上，任务栏固定另外拖一个官方图标，无伤大雅。
- 将“通过 Code 打开”操作添加到目录上下文菜单：强烈建议勾选。装完之后在文件夹上右键直接就有 VS Code 入口，比先开软件再通过菜单打开项目高效太多。
- 将“通过 Code 打开”操作添加到文件上下文菜单：同上，建议勾。这样右键单个文件也能直接开。
- 将 Code 注册为受支持的文件类型的编辑器：对于大多数普通开发者来说，可勾可不勾。如果勾了，以后双击
.txt、.json等文件会默认用 VS Code 开，习惯因人而异。 - 添加到 PATH：这个必须勾。装完在任意终端输入
code就能唤起 VS Code，是后面很多操作的基础。漏勾了也不慌，可以在开始菜单里找到“Visual Studio Code”，用管理员身份打开命令面板执行Shell 命令: 在 PATH 中安装 code 命令。 - 启动 Code 后…… 不选任何框即可，这通常是安装器引导打开软件的一些附加项，没有实质用途。
强烈提醒一句：如果是升级旧版本，安装向导通常会保留之前的配置和插件，不用提前卸载。有人为了方便，重装系统后装了个干净版，发现之前的设置全没了，这是因为 VS Code 的配置和插件默认在用户目录下，不在安装目录里。卸载软件并不会清除 AppData 里的用户数据，想彻底清掉需要手动删 %AppData%\Code 和 %AppData%\Code - Insiders（如果你装过 insiders 版的话）。
2.2 免安装版的适用场景
热搜词里的“vs code 免安装”指的就是官方提供的 zip 压缩包版本。解压即用，不用走安装向导，适合放在 U 盘里随身携带，或者在无管理员权限的电脑上临时使用。
zip 版有个麻烦是右键菜单和 PATH 不会自动配置，需要自己手动操作。最简单的做法是装好并启动一次 VS Code 后，按 Ctrl+Shift+P 打开命令面板，输入 shell，找到“在 PATH 中安装 code 命令”，执行一次就能在终端里用。右键菜单“Open with Code”也可以通过 Similar 方式，安装注册表关联项。
但 zip 版也不是没缺点。每次更新都要重新下载整个包，不能像安装版那样自动增量升级；文件和系统的一些深度整合（比如文件关联、协议唤起）会弱一些。所以我的建议是：日常主力电脑老老实实用安装版，免安装版留给特殊场景，比如在公司锁死软件的电脑上临时顶一下。
2.3 语言设置：第一时间切中文
VS Code 默认英文界面，不少教程让用户去装“Chinese (Simplified) Language Pack”扩展，这是官方做的语言包，安装后右下角会提示重启以切换语言。点击右上角“Change Language and Restart”即可。
关于这个语言包，两个细节值得留意。第一，语言包本质上是一个普通扩展，但它会更改 VS Code 的 locale 启动参数，本质上打开了 VS Code 内部完整的中文本地化资源，覆盖菜单、设置项、命令面板、右键菜单等几乎所有界面文字。第二，有人喜欢中英文混用，可以在设置项 locale.json 中改为 "locale": "zh-cn" 或 "en" 来回切换，文件位置在 %AppData%\Code\User\locale.json。重启后生变，不需要卸载插件。
设置了中文之后，经常有人对着中文菜单找不到英文对应的设置项，比如 editor.formatOnSave 中文显示为“在保存时设置文件格式”，如果搜不到建议临时切回英文界面去对比，这也是踩坑后的一个实惠技巧。
3. 高频开发环境配置：Python、C/C++、Java 一条龙
3.1 Python 开发环境为什么总说“装好了但没法跑”
VS Code 装 Python 环境的常规姿势是：先装 Python 扩展，然后在命令面板里执行 Python: Select Interpreter，选择你电脑里已经装好的解释器路径。但新手经常遇到的问题顺序是：扩展装了、代码写了，按运行按钮提示没有安装 Python 或在环境中找不到 Python。
原因大概率是 VS Code 没找到解释器。打开命令面板选解释器时，如果列表是空的，先确认你是不是真的装了 Python。正版安装包装完后，Windows 开始菜单能找到“Python 3.x”，在终端敲 python --version 有输出，才算装好。另一个多发的坑是：装了 Python 但选择解释器时列表里只有一个 Python 3.x，没有虚拟环境选项，是因为 VS Code 只扫描了当前工作区的 .venv 目录，虚拟环境没建在当前项目下。
为了开发顺手，稍微给个规范化建议：每个项目最好建自己的虚拟环境，不要在全局环境里 pip install 乱装。VS Code 的 Python 扩展会自动识别，然后运行调试时就会自动切换到对应环境。想跑脚本时可以直接右键 Run Python File，或者用右上角三角形按钮，选择当前解释器即可。
提示：VS Code 里代码能跑出来，并不代表你的 Python 路径配置是对的。如果
pip list出来一堆东西，但代码里 import 模块仍报 ModuleNotFoundError，多半是选择了不同的解释器，这一步在排错时优先级最高。
3.2 C/C++ 环境配置：装好编译器才是核心
VS Code 本身不是编译器。你在里面写 C 语言，如果没有装 gcc、g++ 或者 cl.exe，再怎么调插件也不可能运行。这是最核心的一个认知。我们常说的“VS Code 配置 C++ 环境”，本质上是装三个东西：编译器、C/C++ 扩展、调试器。编译器在 Windows 上最常见的是 MinGW-w64 的 gcc，macOS 自带 clang（装了 Xcode Command Line Tools），Linux 直接 apt install gcc g++ 即可。
安装完编译器后，关闭并重新打开 VS Code，此时打开一个 .c 文件，C/C++ 扩展会自动弹出提示，让你选择使用哪种编译器。选 gcc 后，VS Code 会生成 c_cpp_properties.json 配置文件，里面指定编译器路径和 includePath。如果没弹提示，也可以命令面板执行 C/C++: Edit Configurations (UI) 手动指定。
C/C++ 另一个经典坑是：按 F5 调试时提示 launch program does not exist。这个报错出现在 launch.json 里程序的路径不对应实际生成的 exe 上。最常见的情形是：代码所在目录没生成 exe，要么是编译失败了，要么是输出路径设置和 launch.json 的 program 不一致。排查思路就一条：确认你已经成功编译出 exe，再对照 launch.json 里的 program 路径是否指向了这个 exe。VS Code 的任务配置 tasks.json 默认会把 exe 生成到工作区根目录，但在某些配置下把输出路径改到了 build 文件夹，而 launch.json 没同步，于是就会触发该错误。对于这种问题，建议直接在 launch.json 的 program 字段里指定绝对路径来验证，不要一味依赖变量展开。
C/C++ 自动补全方面，得益于 C/C++ 扩展自带的 IntelliSense，写代码时头文件补全、函数签名提示都挺硬核。但很多人装了插件之后发现补全不出来，多半是 includePath 配置不对，编译器头文件找不到，VS Code 里会看到绿色波浪线。可以用命令面板执行 C/C++: Log Diagnostics 查看编译器路径是否正确，再在 c_cpp_properties.json 里把 "compilerPath" 改为 gcc 全路径，把 "intelliSenseMode" 设成 linux-gcc-x64 或 windows-gcc-x64 对应平台。
3.3 Java：别再用记事本跑 Java 了
VS Code 跑 Java 需要安装 Extension Pack for Java，这是一个封装了好几个扩展的合集，包括 Language Support for Java、Debugger for Java、Test Runner for Java、Maven for Java 等。安装后，打开一个 Java 文件，它会提示你选择 JDK。
如果本机装了 JDK 但 VS Code 提示找不到，需要在设置里指定 java.jdt.ls.java.home 这个配置项（最新的版本改成了 java.jdk.path，看版本而定）。这里值得说明的是，VS Code Java 的运行机制是用一个 Java 语言服务器（基于 Eclipse JDT）来提供语法高亮、代码导航、编译错误提示等功能，所以语言服务器本身也需要一个 JDK 来跑，这就是为什么即使你设置了 java.home 还是可能遇到版本不兼容的报错。
比较稳妥的版本搭配是 JDK 17 以上（现在很多项目已经切到 21），VS Code Java 扩展最近几个大版本都基于 JDK 17 构建，老项目用 JDK 8 虽然能在编译通过，但 JDT 语言服务可能启动不起来。一个经验是：给项目配 JDK 1.8 不影响用 JDT 本身跑在 JDK 17 上，你需要在用户设置里把 java.jdt.ls.java.home 指到 JDK 17，同时把项目级 settings.json 里的 java.configuration.runtimes 配置成多个 JDK 路径，这样才能做多版本切换而不用反复改系统环境变量。
3.4 Vue 和 JS 开发的一点补充
热词里有 VS Code + Vue，这个简单说两句。装 Vue 官方扩展 Volar 就行，注意现在 Volar 已经内置在 Vue Language Features (Volar) 扩展里，旧版的 Vetur 不推荐在新项目里用，两者会冲突。另外因为 Vue 单文件组件依赖 TypeScript 语言服务，打开 .vue 文件可能会提示启用 Takeover Mode，这个模式挺好用，可以让 Volar 接管整个项目所有 JS/TS 文件的分析，性能更好。按提示操作，把工作区的 vitest 或项目的 TS 关掉就行，前提是项目本身没有单独依赖 TypeScript 编译流程。
4. 别只顾着装本体，插件才是 VS Code 的灵魂
4.1 你一定会用到的几个基础插件
- Chinese (Simplified) Language Pack：中文界面。刚装的必配。
- Python：微软官方的 Python 扩展，提供调试、IntelliSense、环境管理、交互式窗口等。
- C/C++：微软官方 C/C++ 扩展，提供语法高亮以及智能感知。装了这个以后 C 语言自动补全就基本齐了，不需要额外装什么特殊补全神器。
- Code Runner：一个轻量运行代码的工具，支持几十种语言一键运行。适合快速写测试片段，但不适合替代正式调试器。C++ 建议配合 tasks.json 做编译链路。
- Prettier - Code formatter：前端格式化和代码规范利器，支持 JS/TS/CSS/HTML/JSON/Markdown 等。新版本还有人追问 plaintext 如何格式化，在 VS Code 里 Prettier 默认不会格式化纯文本文件，如果需要给 txt 做自动折行等操作，可以装一个 “Rewrap” 插件。
4.2 挑插件别不看发布时间和下载量
VS Code 插件市场其实鱼龙混杂，有些名字看起来跟官方很像，实际是第三方的，甚至会在后台收集数据。选插件的经验准则可以归纳为三条：第一，优先搜微软官方仓库或者企业官方（如 Python、Vue、Go、Docker 等）发布的扩展；第二，检查最近更新时间，超过一两年没更新的插件，大概率已经不适合新版 VS Code；第三，看下载量和用户评分，同时把差评里的关键字扫一眼，很多插件的问题在差评里一目了然。
有个真实案例：C/C++ 扩展如果没有刻意禁止自动更新，在 VS Code 升级大版本后可能因为签名失效而报错，导致整个语言服务和所有 C 语言代码的标红、补全功能瘫痪。解决办法是在插件页里禁用/启用插件，或者更新到插件最新版本，大概率能修复。
4.3 AI 辅助编程：Copilot Chat、Claude Code 与本地模型接入
最近一年 AI 编程辅助的热度已经盖过了传统插件。GitHub Copilot Chat 是微软官方提供的 AI 结对编程工具，目前需要账号且部分功能收费，但它能提供代码补全和对话式问答。另外一个更灵活的新玩法是 Claude Code for VS Code——你可以把它理解成在 VS Code 内接入 Claude 的编码代理能力，但注册和 API 费用问题会让一部分人望而却步。于是就有了热搜里看到的“Claude Code 插件接入本地大模型 Ollama”这种组装方案。
思路本质上不复杂：VS Code 里装好 Claude Code 的扩展，API Base URL 指到本地跑着的 Ollama 服务（默认地址是 http://localhost:11434），选对模型之后，插件就不再请求云端 API 而是请求本地模型。好处是隐私安全、不烧 token，坏处是本地模型（比如 qwen2.5-coder、llama3.1 系列这些）的代码能力跟云端大模型相比还是有明显差距，适合处理基础的代码解释、短路重写、单元测试生成，不太适合高难度的跨模块重构。
具体设置时，先确保本机安装 Ollama，拉下来一个代码模型，然后跑 ollama list 查看服务是否正常。接着在 Claude Code 扩展的配置项里把 API Base URL 改成 http://localhost:11434/v1，把 API Key 改成任意占位字符串（本地不校验），最后在模型名称处填你拉取的模型 tag，比如 qwen2.5-coder:14b。如果扩展连不上 Ollama，先在终端里 curl http://localhost:11434/v1/models 验证服务是否可直接访问，排除 Ollama 没启动或端口占用的问题。
这类“套壳接入本地模型”的模式不只 Claude Code 可以用，之前很多 ChatGPT 类扩展同样支持改 Base URL。从工具选型角度上，我更建议你把它当作一个可玩性高的沙盘，而不是指望一个 7B 的本地模型解决复杂生产任务。真要面向关键开发流程提效，还得靠官方 API。
Minimax Code 也是时下热门配置项，本质上是把 Minimax 的大模型能力接进 VS Code 做对话与补全。配置思路跟上面一致：装对应插件、在设置里填 API Key、填 Base URL，基本都能通。个人体会是这类国内大模型的代码补全风格更贴中文需求，对中文注释的理解相对自然。
5. 实操中要掌握的三个核心细节
5.1 远程开发时 vscode-server 下载失败的完整解法
Remote-SSH 是 VS Code 最值得用的功能之一，尤其现在许多人的开发环境跑到 Linux 云服务器或嵌入式工作站上。启动远程窗口时，VS Code 会在远端用户目录下自动部署 ~/.vscode-server。如果这个下载环节卡住，最常见错误就是标题里提起的 localdownloadfailed。
处理这种问题，我常用的一个偏方是绕过自动下载，手动部署。过程如下：先在本地找到和远端平台对应的 vscode-server-linux-x64.tar.gz，如果本地也没有自动缓存，就去官网（CDN 链接通常是 https://update.code.visualstudio.com/commit:提交ID/server-linux-x64/stable）手动下载。下载完成后，用 scp 或 SFTP 传到服务器，然后解压。随后还需要在 ~/.vscode-server/bin 里把解压出来的新版文件夹名字改成与 commit ID 对应的名称，才可以被识别。实际上推荐的替代办法是：把下载好的 tar.gz 放到服务器临时目录，让它自动安装时能复用本地文件——如果不怕折腾，直接把它传到远端，解压到 ~/.vscode-server/bin/<commit-id>，VS Code 第二次连接的时候会检测到文件存在就不再重复下载了。
这个问题的核心原因是远端服务器访问微软官方更新服务不稳定。无论如何，处理思路都一样：让远端组件从可信可用路径获取，而不是依赖它自动跨网下载。
5.2 NRF Connect SDK Toolchain 下拉项无法选中的处理
最近嵌入式开发场景里常有人提到 VS Code 的 nRF Connect SDK 扩展里 toolchain 下拉可以看到 v3.1.1，但点了没反应。这个问题我遇到过，大概率是扩展没有检测到对应的工具链安装路径。原因是 nRF Connect SDK 扩展能读到的 toolchain 列表来自你手动配置的安装路径或者环境变量 NRF_TOOLCHAIN_PATH。
解决方法是在 nRF Connect 扩展的设置项中指定 toolchain 的安装目录，让它能找到 nrfutil 工具。这里常用的做法是装完 nRF Connect SDK 和 toolchain 后，在 VS Code settings.json 里配置：
json复制{
"nrf-connect.toolchain.path": "C:/ncs/toolchains/v3.1.1",
"nrf-connect.sdk.path": "C:/ncs/v3.1.1"
}
路径填对后，重新启动 VS Code，下拉选项就能正常选中了。另外 Windows 下这个扩展经常受路径长度限制影响，建议 nRF Connect SDK 的目录不要太深，不要放在桌面之类的带空格的路径下。
5.3 批量处理注释和代码格式化的快捷键
开发过程中高频用的快捷键，很多人用了一两年还不知道。批量给 Python 代码加注释或取消注释，Windows/Linux 快捷键是 Ctrl+/，macOS 是 Cmd+/，这也是全键盘最实用的快捷键之一。拿 Python 来说，选中多行代码后直接按一次就是整段注释，再按一次就会取消注释，比手动在每行前面敲 # 高效得多。
VS Code 格式化快捷键默认是 Shift+Alt+F，如果装了 Prettier，保存时格式化可以通过修改配置实现：
json复制{
"editor.formatOnSave": true
}
如果你希望某些特定扩展对特定格式生效，比如 JSON/JavaScript/HTML/CSS 用 Prettier，纯文本不用，那需要在 settings.json 里专门配置 formatter，建议用 [plaintext] 语言标识单独关掉格式化。这里就不展开所有语言的代码片段了，领会思路即可。
6. 配置文件与常见坑位速查
6.1 Linux 下用户级配置文件默认路径
Linux 下 VS Code 的全局设置文件，不同版本和渠道路径略有差异，社区版本（从 code.visualstudio.com 下载的 deb）用户级配置路径为：
- 用户设置文件：
~/.config/Code/User/settings.json - 用户代码片段目录：
~/.config/Code/User/snippets/ - 插件安装目录：
~/.vscode/extensions
如果用的是 Snap 包装的 VS Code，路径会变成 ~/snap/code/current/.config/Code/User/，因为 snap 环境每个应用都做了沙盒隔离，这也是为什么不太推荐在 Linux 上常用 Snap 版的原因之一，路径变得不直观，原生文件监听、终端集成偶尔也会出小问题。
知道路径的作用不仅在于手动改配置，还可以备份整个 User 文件夹来做配置迁移，换新电脑时把 settings.json、keybindings.json 和 snippets 目录拷过去，就省去重新配置的时间。
6.2 常见报错速查表
| 报错/现象 | 可能原因 | 解决思路 |
|---|---|---|
| 远程连接报 failed to fetch，vscode-server 下载失败 | 远端无法访问 VS Code 官方下载地址 | 手动下载对应 commit 的 server 包，解压到 ~/.vscode-server/bin 下 |
| C++ 按 F5 报 launch program does not exist | launch.json 里的 program 路径不对或没有编译 exe | 先确认编译产物存在，再检查 program 路径与实际输出路径一致 |
| 设置中文无效，界面还是英文 | 语言包未启用或 locale 配置文件没生效 | 按 Ctrl+Shift+P 输入 Configure Display Language，选择 zh-cn |
| Python 代码运行报“没有指定解释器” | 扩展未找到本机 Python | 确认 Python 已装且能跑，命令面板 Python: Select Interpreter 手动指定 |
| 终端敲 code 命令没反应 | 安装时未加入 PATH | 命令面板执行 Shell 命令：在 PATH 中安装 code 命令 |
| C 语言代码没有智能补全 | includePath 或编译器路径配置不对 | 打开 c_cpp_properties.json，设置 compilerPath 和 includePath |
| VSCode 打开 vue 提示多种 TS 服务冲突 | Vetur、Volar、内置 TS 共存 | 旧项目用 Vetur，新项目卸载 Vetur 只留 Volar |
| 莫名其妙出现一堆波浪线和错误，但代码运行正常 | IntelliSense 引擎或配置与当前代码库不匹配 | 查看输出面板里的错误日志，通常 IntelliSense 的日志会直接指出找不到哪个头文件 |
6.3 用户数据同步、备份与迁移
VS Code 登录微软或 GitHub 账号后，设置和插件列表可以云同步，这个功能在“设置同步”里默认开启。但这个同步也有坑：它同步的是设置文件、快捷键、用户片段与扩展列表，不同机器上扩展版本不一致可能导致行为不同，同步过来之后也建议运行一段时间让扩展都自动更新。
如果想要可追溯的完整配置备份，更建议直接把前面提到的 User 目录完整拷贝出来，包括 settings.json、keybindings.json、snippets 目录一并打包。切换电脑恢复配置时，最好不要直接覆盖正在运行的 VS Code 的配置文件，等 VS Code 关闭后再赋值，避免进程锁定或者热加载冲突。插件可以不用手动恢复，执行一下 code --install-extension 批量导入扩展名列表，前提是之前备份过扩展列表，也可以用命令 code --list-extensions > extensions.txt 导出。
7. 一些实际使用后的心得总结
7.1 VS Code 绝不是 Electron 应用里的花瓶
很多人一听 VS Code 是 Electron 套壳就开始嘲讽性能。但实际用下来，它在编码主流程的性能优化上其实很下功夫：编辑器核心使用平台原生 WebView 渲染，文件索引和搜索进程独立。问题更多的出现在插件过多或者插件质量差时，特别是那种一装就监控全项目文件变更的扩展，会把 CPU 干满。以前排查过一个 CPU 占用持续 100% 的工作区，最后定位到某个语法高亮扩展，禁掉后立刻恢复正常。养成习惯：新装插件后留意一段时间进程占用，或者定期跑一次 Developer: Open Process Explorer 看扩展的内存占用分布。
7.2 学习 VS Code 的路径不需要太陡
VS Code 的使用学习可以分阶段：第一阶段只把它当编辑器，装几个插件就开始写；第二阶段配置 tasks.json 和 launch.json，掌握编译和调试的完整闭环；第三阶段研究 snippets、多 cursor 编辑和自定义快捷键，真正把编码速度提上去。如果把所有功能都堆到第一天学，反而容易劝退。
7.3 遇到问题先看输出面板
最后分享一个解决 VS Code 各种疑难杂症的通用方法。任何功能不对劲时，第一个动作不要是百度，而是菜单栏“帮助 -> 切换开发人员工具”或者直接看“视图 -> 输出”面板。VS Code 的输出面板中，不同扩展会建立自己的输出通道，比如 Python、C/C++、Git 等。报错的真正原因，大多数时候会以红色堆栈形式出现在对应通道里。哪怕报错全是英文乱七八糟的，也能搜到关键线索，再带着具体错误去搜索，比泛泛地搜“vs code 插件 不能用”有效率得多。说实话，我在用 VS Code 的这几年里，遇到 80% 的疑难报错，最后都是靠那个英文错误信息找到答案的，剩下的 20% 才是凭经验猜一下路径和版本兼容问题。
装了这么多年 VS Code，我最大的体会其实是不要把“安装环境”和“使用开发工具”混为一谈。VS Code 装起来确实快，但那只是把壳子立起来了；后面的编译器、解释器、代码分析器、远程服务器组件，才是真正需要动手搭的部分。以后遇到任何报错，先冷静拆一下报错发生在哪个环节——是扩展没起来、是语言服务找不到环境、还是远端组件没有落地？理清这条链路，VS Code 就再也拦不住你干活了。