简介微软Visual Studio Code简称VS Code是微软推出的免费开源代码编辑器长期活跃于Web前端、服务端脚本、桌面与移动应用等各类开发场景既适合初学者熟悉编码流程也适合专业开发者进行多项目协同与复杂调试其强大的扩展生态允许用户随时按需定制工具链。这份压缩包提供了完整的VS Code程序资源共收录7094个文件涵盖JavaScript、TypeScript等语言文件、JSON配置、Markdown文档、License许可文本以及大量扩展依赖、工具链组件与辅助脚本压缩后约64.63MB目录结构基本沿用原生布局便于在离线环境获取、按需检索与二次定制这些文件共同构成了可运行的开发环境并保留了语言服务与调试器所需的关键依赖。目前已有820人学习下载适合需要本地化保存或搭建开发环境、研究编辑器内部构成、补充安装扩展依赖的用户。资源中不仅包含代码编辑器主体还涉及内置Git版本控制、IntelliSense智能补全、多语言调试适配、扩展市场相关模块、集成终端配置以及Live Share协作组件等用户可据此深入了解VS Code的功能组织方式快速复现常用开发特性为日常编码、项目版本管理与团队协作提供可靠的工具支撑。1. VS Code 不是编辑器是开发者工作台它到底在替我们解决什么很多人第一次打开 Microsoft 出品的 VS Code会觉得它不过是个记事本加强版——装完打开一片空白连个编译按钮都找不到。但真正用顺手的人都明白这是一套能自己拼装的工作台跑 C 程序、做 STM32 嵌入式、接 AI 编程助手、连远程服务器排查问题全部收在同一个窗口里。它和传统 IDE 最大的差异在于不替你规定工作流而是让插件生态替你拼出适合自己项目的那套流程。这篇笔记写给三类人刚学 C 语言的学生、想从老式 IDE 里解放出来的嵌入式工程师以及想低成本接入 AI 编程助手的开发者。路径是真实可复现的装什么、怎么配、坑在哪一步步说清楚。2. 本地环境从 0 到 1安装、C 语言编译和 Code Runner 的最小配置2.1 下载安装三个勾选项决定你后面少走多少弯路VS Code 的下载页面有两个版本用户安装版和系统安装版。新手最容易忽略这个选择。用户安装版装在当前用户目录下不需要管理员权限公司电脑受限时也能装系统安装版装到 Program Files所有登录用户共享。我的建议是无脑选用户安装版理由是后续升级扩展、装工具链时碰到的权限问题会少一大半卸载也干净不用跟 UAC 弹窗较劲。安装界面里有几个默认勾选项很多人直接一路 Next回头才发现命令行里敲 code 打不开编辑器。真正值得留意的就三项把“添加到 PATH”勾上这样终端里能直接用 code 命令打开工程“通过 Code 打开”和“添加到资源管理器目录上下文菜单”看个人习惯我通常会勾右键就能打开项目目录文件关联那项建议选上以后双击 .c 文件默认用它打开省得再手动关联。安装选项作用我的建议用户安装版免管理员权限装在用户目录推荐权限坑最少添加到 PATH终端可用code命令必勾否则后悔药都没有添加到资源管理器上下文菜单右键直接打开目录建议勾日常效率提升明显装完先别急着搜扩展。打开终端敲code --version能正常输出版本号就说明环境没问题。这一步是验证 PATH 是否生效很多后续配置都是从这里开始的。2.2 用 Code Runner 跑通第一个 C 程序编译器、executorMap 与中文编码装完 VS Code 不代表能跑 C。很多人卡在这一步编辑器装好了但点运行没反应其实缺的是一个 C 编译器。Windows 上最常见的选择是 MinGW-w64它会把 gcc、gdb 一起打包进来编译和调试都靠它。装完要确认一件事把 MinGW 的 bin 目录加进系统 PATH。验证方式很简单新开一个终端输入gcc --version看到版本信息才算真的装好了。然后装 Code Runner 扩展。这扩展的作用就一条选中或打开文件点右上角三角形直接编译运行。默认配置在 Windows 下跑 C 语言时对中文不太友好输出窗口经常是一堆乱码根源是 gcc 默认按 UTF-8 处理源文件而 Windows 终端习惯用 GBK。我现在的配置是这样{ code-runner.executorMap: { c: cd $dir gcc $fileName -o $fileNameWithoutExt -fexec-charsetGBK $dir$fileNameWithoutExt }, code-runner.runInTerminal: true, code-runner.saveFileBeforeRun: true }executorMap里的$dir表示当前文件所在目录$fileName是文件名$fileNameWithoutExt是不带扩展名的文件名。关键是-fexec-charsetGBK它让编译出的程序按 GBK 输出中文Windows 控制台就不会乱码。runInTerminal设为 true 是让程序跑在 VS Code 内置终端里这样能正常读键盘输入saveFileBeforeRun会在运行前自动保存避免改完代码忘了保存、跑的还是旧版本。第一次运行如果报“gcc 不是内部或外部命令”不是 VS Code 的问题是编译器路径没进 PATH。新装完 MinGW 之后已经打开的 VS Code 要彻底重启一次环境变量才会被重新读取。这一步卡住过的人不在少数。2.3 扩展清单哪些装完即用哪些要避开VS Code 的扩展市场鱼龙混杂同名的、仿冒的都不少。我按用途整理了一份日常必装清单照着装基本不会出错扩展名用途什么时候需要C/C微软官方语法高亮、IntelliSense、调试支持写 C 或 C 就装Code Runner单文件编译运行练习算法、写小工具时PlatformIO IDE嵌入式工程编译、烧录、串口监视做 STM32、Arduino 开发时Continue接入 DeepSeek 等大模型 API 的 AI 助手想用 AI 辅助写代码时Remote-SSH连接远程服务器改代码服务器开发、部署排查时Chinese Language Pack中文界面对英文界面不敏感可不装Marp for VS Code用 Markdown 写幻灯片做技术分享、内部培训时这里有个需要避开的坑尽量只装同一用途的扩展。比如 C 语言相关的智能提示装了 C/C 官方扩展就别再装其他 C 语言提示插件它们会同时竞争补全结果就是互相覆盖弹出来的代码提示反而变慢。还有人问写 LaTeX 该用 TeXStudio 还是 VS Code我的回答是如果只是写论文和文档VS Code 装个 LaTeX Workshop 完全够用还能和 git 集成换来换去反而没必要。3. 嵌入式开发用 PlatformIO 把 STM32 工程搬进 VS Code3.1 为什么把 STM32 工程从 Keil 挪到 VS Code三条硬理由很多从学校一路用 Keil 过来的工程师第一次听到在 VS Code 里做 STM32 会皱眉。我的看法是如果你的项目只需要一个人、一块开发板、一个下载器Keil 没问题但一旦涉及多人协作、跨平台、代码评审Keil 的短板就很明显了。第一Keil 的工程文件是私有格式进 git 之后每次操作都会产生大量无意义的 diffCode Review 基本没法做。第二Keil 在 Windows 之外的平台上跑不起来团队里有人用 macOS 或 Linux 就完全没法参与。PlatformIO 解决的就是这些问题。它的工程就是一个文件夹加一个platformio.ini配置文件所有依赖和工具链都由它自动管理可以用 git 正常追踪。底层还是 GCC 工具链编译出来的固件该烧照样烧但对工程的管理方式现代了很多。另一个明显的改善是代码提示VS Code 里看 STM32 寄存器定义、跳转到 HAL 库源码比在 Keil 里按 F12 要顺滑得多整个库的索引是实时的。3.2 platformio.ini 逐行解读board、framework 与烧录参数PlatformIO 的核心理念是“配置即工程”。新建项目时它会问三件事开发板型号、开发框架、项目目录。以最常见的蓝丸 F103C8 为例一份最小可用的配置文件长这样[env:bluepill_f103c8] platform ststm32 board bluepill_f103c8 framework arduino upload_protocol stlink monitor_speed 115200platform字段指定芯片厂商平台写 STM32 就是ststm32它决定了工具链和 SDK 的下载来源。board字段是关键它对应一块具体的开发板PlatformIO 会从板级配置里读出芯片型号、Flash 大小、烧录方式等参数。framework选arduino是走 Arduino 封装适合快速原型生产级项目我一般换成stm32cube用 HAL 库裸写可控制性强很多。烧录相关有两个参数要留意。upload_protocol指定下载器协议ST-Link 就写stlink如果用的是串口烧录比如板载 USB 转串口的 DFU 模式要改成对应的协议或直接去掉让 PlatformIO 自动识别。monitor_speed是串口监视器的波特率必须和固件里初始化串口时设的波特率一致最常见的值是 115200 和 9600设错了串口输出全是乱码。lib_deps不是每个项目都需要但用 Arduino 框架时基本躲不开。它声明的第三方库会在首次编译时自动下载省去手动翻 GitHub 找 zip 的麻烦。写法是用户名/库名版本号比如bblanchon/ArduinoJson^7.0.0。这里提醒一句第一次编译 STM32 工程会非常慢因为 PlatformIO 要下载 ARM 工具链、OpenOCD 和整个 HAL 库十分钟到半小时都正常不是卡死了耐心等就行。3.3 编译、烧录、串口监视三条 pio 命令和没板子时的替代方案PlatformIO 装好后VS Code 底部会出现一行快捷按钮像“勾号”“右箭头”“插头”三个图标对应的是编译、烧录、串口监视。但命令行永远是更可靠的排查手段报错信息比图标友好得多。我常用的三条命令pio run # 编译工程 pio run -t upload # 编译并烧录 pio device monitor # 打开串口监视器第一条命令是纯编译生成固件文件不接硬件也能跑适合在 CI 或无板子环境下验证代码能否通过编译。第二条会读取upload_protocol指定的烧录方式执行编译后调用工具把固件写入芯片。第三条打开串口监视器能看到板子通过串口打印的调试信息退出快捷键是CtrlC。烧录失败是新手最容易崩溃的时刻。现象往往是pio run -t upload报Failed to connect或Cannot connect to target。原因分为几种ST-Link 驱动没装好Windows 设备管理器里能看到黄色感叹号接线松动SWD 的四根线接触不良还有一种是板子处于低功耗休眠状态。这类问题经常没明确提示像玄学一样我的排查顺序是先查驱动、再换线、最后按一下板子上的复位键重试。如果手头还没有开发板又不想干等硬件到货可以先用 Wokwi for VS Code 的仿真扩展。它能在 VS Code 里直接模拟一块 STM32 或 Arduino 板子LED 亮灭、串口输出都能看到基本行为验证够用。我在写验证性质的串口测试代码时经常先在 Wokwi 里跑通再上真板子少烧几次板子也少等快递。4. 接上 AI 编程助手Continue DeepSeek 的完整配置记录4.1 先定路线本地模型还是 DeepSeek 云端 APIAI 编程助手现在已经不是要不要装的问题而是选哪条路线的问题。两条主流路子一是本地起一个模型用 Ollama 跑二是注册云服务商拿 API 来调用。两者的取舍很清楚。本地模型的好处是免费、离线、代码不出机器隐私上没负担代价是显存不够时模型小、效果差8GB 显存跑起来的模型在代码补全上的表现只能说能用。云端 API 的效果好得多DeepSeek 的 deepseek-chat 在代码理解和补全上比同价位的本地小模型强几个档次按 token 计费日常辅助写代码一个月几块钱人民币是常态。我的建议是主力用云端 API本地模型作为网络不可用时的兜底。原因很简单API 方式不需要你维护模型、不用管显存和模型版本扩展层面配置一次就完事换模型只改一行配置。而本地模型每次换版本要重新拉模型文件、处理依赖库折腾的精力远超省下的几块钱。4.2 Continue 接入 DeepSeekconfig.json 的完整配置Continue 是 VS Code 生态里对国内用户比较友好的 AI 助手扩展。它不绑定某一家云厂商而是通过配置文件指定用哪家模型DeepSeek 就是最常见的配置之一。安装扩展后左侧会出现 Continue 的图标第一次打开会引导创建配置文件。它的全局配置是一个 JSON 文件点击扩展面板里的齿轮图标可以打开。一份可用的 DeepSeek 配置长这样{ models: [ { title: DeepSeek Chat, provider: deepseek, model: deepseek-chat, apiKey: ${env.DEEPSEEK_API_KEY} } ], tabAutocompleteModel: { title: DeepSeek Coder, provider: deepseek, model: deepseek-coder, apiKey: ${env.DEEPSEEK_API_KEY} }, customCommands: [ { name: explain, prompt: 用中文解释当前选中的代码指出潜在风险和优化点。, description: 解释选中代码 } ] }models数组里声明可用的模型。provider填deepseekContinue 内置了对 DeepSeek 的支持apiKey建议不要直接把密钥写进配置文件用${env.DEEPSEEK_API_KEY}这种环境变量引用密钥只在当前用户的环境变量里存在不会因为分享配置文件而泄露。tabAutocompleteModel是可选配置它控制按 Tab 时的行内补全这里指定一个专门用于补全的模型避免自动补全走对话模型导致响应偏慢。配置文件的参数里有个细节值得多说两句。如果你是代理中转用户或者想试其他兼容 OpenAI 接口的服务需要加一行apiBase: https://api.deepseek.com/v1来覆盖默认请求地址。DeepSeek 官方在这里是正常工作范围内的不需要任何特殊网络配置。配置保存后重启 VS Code在 Continue 面板里选中 DeepSeek Chat 模型随便问一句能返回内容就说明链路通了。第一次请求会偏慢属于冷启动后面会快起来。4.3 Copilot、Cursor、Windsurf、Trae 怎么选一张表看懂差异把 Continue 配好后很多人还是会纠结要不要干脆换 Cursor 或者 Trae我的看法是看你的团队形态。下表是几个主流方案的差异都是基于公开信息和实际使用感受整理的方案形态补全质量适配 VS Code 工程适合人群VS Code Continue DeepSeek扩展中上原生想留在 VS Code、控制成本GitHub Copilot扩展强官方深度集成愿意付费、追求稳定补全Cursor独立 IDE强可导入但配置要迁移想要开箱即用 AI 功能Windsurf独立 IDE强类似 Cursor偏 Agent 式多步操作Trae独立 IDE中上类似 Cursor习惯中文界面、尝鲜如果你已经用 VS Code 搭好了一套环境扩展、任务、调试配置都调好了我的建议是留在 VS Code 里加 Continue没必要为了 AI 功能把整个环境搬到另一个 IDE。Cursor 本质上是 VS Code 的一个分支十年前叫“把 VS Code 改造成 AI IDE”的路线今天依然是这样但换来换去的过程里快捷键、settings.json、tasks 配置全要重新磨合成本不小。Copilot 的补全质量确实是目前最稳的但它按月订阅且只对单个用户生效团队内共享不方便。至于 Claude 这类模型Continue 同样支持在models数组里增加一个anthropicprovider 的配置项即可不影响现有 DeepSeek 配置。5. 高频问题排查远程连接失败、头文件报错与中文乱码5.1 远程开发报 failed to fetch服务器端到底卡在哪一步用 Remote-SSH 连服务器时弹窗报“未能下载 VS Code 服务器 (failed to fetch)”这个报错几乎每个远程开发的人都见过。现象是本地 VS Code 检测到远程没有服务端程序尝试下载时失败连接中断。原因在 VS Code 的机制远程开发需要在目标机器上放一个名为vscode-server的目录它和本地版本一一对应版本号都挂在同一个 commit 上。下载失败通常是目标机器访问微软下载通道的网络不稳定或者下载过程中连接被重置。解决思路分两步。第一步是换网络环境重试办公楼和家庭宽带对同一个下载域名的可达性差别很大切换后多数情况能解决。第二步是手动补齐服务端本地 VS Code 的关于页面能看到当前 commit 号从微软官方渠道下载对应 commit 的 server 压缩包解压后放到~/.vscode-server/bin/对应commit目录然后重连。手动放置时目录结构要对bin下面是一长串 commit 哈希里面直接放服务端文件。放错位置会反复报同一错误检查方式是看远程机器上该目录是否存在且文件完整。5.2 头文件 not found编译器路径与 tasks.json 的关联性C 语言项目报fatal error: stdio.h: No such file or directory是另一类高频事故。现象是 VS Code 编辑器里语法高亮正常Run Code 的按钮也能点但一运行就报找不到头文件。原因是编辑器用的编译器和实际编译用的编译器不是同一套VS Code 的 C/C 扩展会自己扫描系统里的编译器路径而 Code Runner 是调 shell 命令执行gcc两者找到的可能不是同一个安装位置。排查时先打开终端敲where gccWindows 下会列出所有出现在 PATH 里的 gcc 可执行文件路径。如果同时存在 MinGW 和别的工具链装进来的多个 gcc问题就出在这里——Code Runner 用的gcc是 PATH 里排前面的那个而 C/C 扩展的 IntelliSense 用的可能又是另一个。解决方法是只保留一套编译器把多余的从 PATH 里移除。另一个相关场景是打开老项目时 tasks.json 里写死了编译器路径比如写的是C:/MinGW/bin/gcc.exe换个机器路径变了就报错。我一般建议tasks.json里直接用命令名gcc而不是绝对路径从 PATH 里解析这样换机器不用改配置。5.3 中文乱码文件编码和终端代码页两层处理中文乱码分两种一种是编译运行后控制台输出乱码一种是编辑器里打开的源码本身乱码。前者主要是字符集问题上一章讲 Code Runner 时提到的-fexec-charsetGBK就是解决方案也可以反向操作把终端代码页切到 UTF-8在终端里执行chcp 65001然后源文件保持 UTF-8、编译参数去掉-fexec-charset。两条路都能通但别混用——源文件是 UTF-8、编译参数又指定 GBK、终端还在用 UTF-8三重叠加必然乱。最省心的组合是源文件统一 UTF-8 编码终端用chcp 65001编译时加-finput-charsetUTF-8明确告诉 gcc 输入编码。编辑器里打开旧项目源码全是乱码是另一类问题。VS Code 默认用 UTF-8 读文件遇到 GBK 编码的旧文件就会显示成乱码。这时点击右下角状态栏的“UTF-8”字样选择“通过编码重新打开”选中“中文 (GBK)”就能正常显示。如果想彻底解决重新保存时选“通过编码保存”为 UTF-8然后把文件统一转码。转码是件需要谨慎的操作改编码会动文件内容最好在 git 里确认 diff 只有编码变化再提交这是很多团队翻车的地方。5.4 格式化把代码改坏无关扩展的副作用格式化功能本身是好用的但扩展之间互相抢格式化权限时会出很尴尬的事。现象是保存文件后整个代码的缩进、换行、引号全变了甚至把原本能编译的代码改出语法错误。原因是安装了多个带格式化能力的扩展VS Code 默认会用最近装的那个处理保存格式化的动作而它的格式风格跟你项目的.clang-format配置不一致。解决思路是主动指定格式化工具。在 VS Code 设置里搜defaultFormatter把默认格式化器设为 C/C 扩展或项目对应的工具不同语言可以分别指定。另一个重要选项是formatOnSave我建议改成 true 的同时配好.clang-format让格式稳定可复现。如果项目是老代码改动格式会引发大量无意义的 diff那就直接关掉 formatOnSave只保留手动格式化快捷键在进入大规模重构时再打开。6. 最后一公里一份能断点调试的 launch.json 与我的调试习惯6.1 从编译到断点一份最小可用的 launch.jsonCode Runner 能跑通但遇到逻辑复杂的问题还是要靠断点。VS Code 里给 C 程序加断点只需要在.vscode目录写一个launch.json并保证编译时加了-g参数。以 MinGW 的 gdb 为例{ version: 0.2.0, configurations: [ { name: Debug C, type: cppdbg, request: launch, program: ${fileDirname}/${fileBasenameNoExtension}.exe, args: [], stopAtEntry: false, cwd: ${fileDirname}, externalConsole: false, MIMode: gdb, miDebuggerPath: C:/mingw64/bin/gdb.exe, preLaunchTask: build-c } ] }program指向编译生成的可执行文件注意和 tasks.json 里输出路径保持一致否则调试器找不到程序。preLaunchTask的值必须和tasks.json里某个 task 的label完全一致它的作用是点击调试按钮时先自动执行编译任务保证调试时跑的是最新的代码。miDebuggerPath是 gdb 的绝对路径Windows 下反斜杠要写成C:/这种正斜杠形式。externalConsole设为 false 时程序和控制台都嵌在 VS Code 里方便一起看但如果程序需要读特殊键盘输入可以改为 true用独立的系统控制台运行。现在的调试工作流已经固化成我自己的习惯了先pio run验证能编译再按 F5 进入调试断点打在怀疑的函数入口检查和预期不符的变量。遇到平台相关的 bug先在 Wokwi 里复现一遍再回真板子确认。这套流程被身边同事拿去后反馈是“终于不用靠串口打印猜代码了”。也希望这份配置记录能帮你省下摸索的时间把精力留在真正难的问题上。本文还有配套的精品资源点击获取
