VSCode插件目录搬家与高效管理：从C盘爆满到AI编程实战

想写这篇文章的冲动源于上周帮同事处理的一次“C盘又爆了”事故。他的VSCode装了六十多个插件扩展目录把用户目录直接撑到了十几个GWindows系统更新都跑不动了。我打开他的插件列表一看光是各种语言包、主题、代码片段插件就占了三分之二其中不少装完就再也没用过。那天我顺手帮他做了一次插件大扫除又把扩展目录整体迁到了D盘C盘瞬间腾出十来个G。回头聊起来才发现很多人根本不知道VSCode插件到底存在哪也不知道怎么改这个路径更别提用完插件之后的管理和排错了。这篇文章就围绕“插件地址修改”和“插件使用”这两个点展开把默认目录的位置、搬家的几种思路、改插件源地址的操作以及最近高频使用的AI编程、远程开发、语言环境类插件的配置和踩坑全部过一遍。适合正在被C盘空间困扰、刚接触VSCode插件机制、或者装了插件经常出问题不知道怎么排查的人。1. 先搞懂VSCode插件到底住在哪儿以及为什么要给它搬家1.1 默认插件目录和它暴露出的三个问题如果从来没有刻意设置过VSCode插件默认安装在用户目录下。Windows上是C:\Users\你的用户名\.vscode\extensionsmacOS和Linux是~/.vscode/extensions。这个目录存放了所有通过扩展面板安装的插件每个插件对应一个或几个子目录里面是插件本体、依赖包、编译产物。这个默认设计在大多数情况下没问题但三个场景会很烦人第一个是C盘空间。Windows系统盘本来就紧插件里有不少“重量级”选手比如Pylance、C/C扩展、各种AI助手插件单个就能占几百MB装多了轻松突破10G。代码提示、格式化、语法检查这些都要实时加载体积大还不只是因为安装包大很多插件会缓存索引、模型、日志越用越肥。第二个是系统迁移和重装。重装系统或者换电脑之后插件目录默认随用户配置文件一起丢失虽然VSCode账号同步能恢复已安装插件列表但插件配置、缓存、本地登录态都丢了每台机器都得重新登录一遍AI助手、重新设置一遍路径很糟心。第三个是权限和网络环境问题。公司域环境里用户目录可能被组策略限制或者挂载在网络盘上插件写入慢、权限不足导致安装失败的情况我都见过。有些绿色版、便携版VSCode用户更希望所有数据都跟着安装目录走走到哪带到哪。所以“改插件地址”这件事本质上不是花活而是为了给系统盘减压、方便迁移、绕开权限问题。早处理比晚处理省事。1.2 三种“改地址”的主流思路对比围绕“插件地址修改”主流做法有三类适用的场景完全不同。第一类是启动参数--extensions-dir在启动VSCode时指定插件目录适合便携化、多版本共存、临时切换目录的场景但对普通用户来说有个明显问题只有通过指定参数启动的窗口才会用新目录直接双击文件关联打开的窗口不生效容易造成“插件时有时无”的错觉。第二类是目录软链接中文Windows里叫目录联接Junction。先把默认插件目录整体搬到目标磁盘然后在原位置创建一个指向新目录的链接。对VSCode和插件来说路径完全没变但实际数据已经搬家。这是最“无感”的方式也是我帮同事采用的方式。第三类是修改插件市场源地址。这句话里的“地址”指的是扩展市场服务地址也就是VSCode去哪个地方拉取插件列表、下载安装包的地址。正常情况下用官方源没问题但在某些网络环境下官方源慢得离谱装个插件等半天还失败。这时可以修改安装目录下resources\app\product.json文件把扩展市场相关字段指向可正常访问的镜像源。这三个方向并不冲突可以组合使用。我建议按这个优先级来日常个人电脑用软链接公司电脑或便携版用--extensions-dir网络状况确实不理想时再考虑改市场源。2. 插件目录修改实操从启动参数到软链接2.1 命令行参数--extensions-dir 的用法与适用场景--extensions-dir是VSCode内置的启动参数可以直接在命令行用也可以写进快捷方式的目标路径里。命令行方式是code --extensions-dir D:\VSCodeExtensionsWindows下如果想把默认快捷方式也带上这个参数右键快捷方式选择“属性”在“目标”末尾追加C:\Program Files\Microsoft VS Code\Code.exe --extensions-dir D:\VSCodeExtensionsLinux和macOS同理在/usr/bin/code或应用快捷方式里加参数即可。这个方式的优点是完全不影响原目录启动哪个目录用哪个目录特别的适合多版本插件环境隔离。比如我同时用稳定版和Insiders版就给Insiders单独指定一个测试插件目录互不污染。但缺点也很明显一是“入口依赖”只有从带参数的快捷方式启动才生效如果你从开始菜单、文件右键、资源管理器打开目录的方式进入VSCode那些入口并不带参数就会回到默认目录看起来像“插件全部消失了”实际上是换了个空插件目录在跑二是新建目录是空的之前默认目录里已经装过的插件不会自动跟过来需要在扩展面板里重新装一遍。如果你本来就是空白环境用这个参数最干净。2.2 Windows下软链接方案最无感的搬家如果插件已经装满了一堆不想重装软链接方案更合适。步骤如下第一步完全退出VSCode确保所有窗口关闭。不退出就移动目录文件被占用会直接失败。第二步把默认插件目录改名备份注意不是删除ren C:\Users\你的用户名\.vscode\extensions C:\Users\你的用户名\.vscode\extensions_old第三步在目标盘创建新目录并移动原内容mkdir D:\VSCodeExtensions move C:\Users\你的用户名\.vscode\extensions_old\* D:\VSCodeExtensions\第四步在默认原位置创建目录联接mklink /J C:\Users\你的用户名\.vscode\extensions D:\VSCodeExtensions此时原位置的extensions文件夹其实只是一个“入口”实际内容都指向D盘。验证方式是在命令行执行dir C:\Users\你的用户名\.vscode会看到extensions后面有JUNCTION标记说明成功了。Linux/macOS下操作更简单mv ~/.vscode/extensions /data/vscode-extensions ln -s /data/vscode-extensions ~/.vscode/extensions注意ln -s参数顺序是“目标位置在前链接名在后”写反了就是无效链接。这套方案为什么好用因为对VSCode、插件、更新器来说路径始终是C:\Users\你的用户名\.vscode\extensions其实数据都落在D盘。自动更新插件时VSCode会先往目录里写临时文件再替换这个流程在junction下完全透明不用担心更新把链接冲掉。有个细节值得注意mklink /J创建的是目录联接Junction不是符号链接Symlink目录联接不需要管理员权限对普通用户更友好。如果系统提示找不到mklink用管理员身份打开CMD再试。2.3 顺手改掉插件市场源地址product.json 里的小文章“插件地址修改”如果指的是下载源改法在product.json里。VSCode安装目录下有一个文件Windows: C:\Program Files\Microsoft VS Code\resources\app\product.json Linux: /usr/share/code/resources/app/product.json macOS: /Applications/Visual Studio Code.app/Contents/Resources/app/product.json用编辑器打开找到extensionsGallery字段这个字段就是扩展市场地址的定义所在。需要修改的核心项是serviceUrl和itemUrl一个负责拉取插件列表和安装包一个负责打开扩展详情页。原版默认类似这样extensionsGallery: { serviceUrl: https://marketplace.visualstudio.com/_apis/public/gallery, itemUrl: https://marketplace.visualstudio.com/items }改的时候先备份原文件再替换为在你当前网络环境下可以正常访问的镜像源地址保存后完全重启VSCode才生效。这个方式的坑在于VSCode自动更新时可能会把product.json一起覆盖回官方配置更新完需要重新改文件必须是合法JSON逗号、引号稍微错一位VSCode可能直接起不来另外它影响的是整个应用所有用户、所有工作区都会走这个源不是“只给某个项目换源”的粒度。我的经验是官方源在正常网络环境下完全够用不用折腾。只有当你确认官方源长期无法访问或慢到不可接受时才建议改。改之前确认镜像源的维护状态有些源年久失修插件列表老旧还不如官方源慢一点但数据完整。改完之后在扩展面板搜一个比较常见的插件比如Chinese能正常出现结果说明配置生效了。2.4 改完之后必须做的一件事验证与排错不管是换目录还是换源改完都要验证三层第一层插件列表是否完整。打开扩展面板看已安装插件是否都出现。如果用的是--extensions-dir新目录这里大概率是空的属于预期。第二层插件是否真的能加载。随便打开一个你有语法高亮或代码补全的文件看语言服务是否正常再打开一个Python或C文件试试跳转定义、悬停提示确认底层运行宿主没有报错。如果扩展面板里显示“This extension has failed to activate”多半是插件目录权限不对或者复制目录时漏了隐藏文件。第三层重启之后状态是否保持。软链接方案重启VSCode后一切照旧--extensions-dir方案假如你忘了改快捷方式从别的入口启动就会退回默认目录。这个最容易迷惑人尤其是我见过有人改了参数第二天开机双击文件打开编辑插件全没了以为被清理了实际是两个入口用了不同目录。排错时先确认两件事一是code --version能正常输出版本看命令是否在PATH里二是在VSCode里打开命令面板CtrlShiftP执行Developer: Toggle Developer Tools在控制台看有没有扩展宿主进程报错比盲猜快得多。3. 最近高频使用的几类插件实测AI编程、远程开发、语言环境3.1 把AI助手接进VSCodeDeepSeek、Claude Code、Codex的实际配置热词里出现最多的一类就是AI编程插件。这里说清楚现在VSCode里的AI助手插件基本分成两个流派。一派是官方深度集成比如Claude Code插件、OpenAI Codex插件安装登录后直接在侧边栏对话可以对当前文件做修改然后生成diff另一派是聚合型框架比如Continue、Cline它们本身不提供模型而是通过配置对接不同模型服务DeepSeek就可以这样接进去。Claude Code插件的使用路径一般是在扩展商店安装后在插件设置里配置API Key或者用官方账号登录。配置完成之后重点是给AI一个清晰的上下文。我在项目根目录放一个说明文件把项目架构、构建命令、代码风格约定写进去插件会自动读取对话质量明显比没写给规则时高一个档次。实际用下来让它重构小函数、补测试、解释一段没注释的老代码都是很顺手的场景。Codex插件的逻辑类似登录之后在对话框里可以直接提需求它还能读出当前文件内容。我第一次用这个插件回头改自己三周前写的脚本让它“给这几段加防御性检查并且不改变主流程”出来的改动基本可以直接用。不过它操作代码时建议逐个hunk确认别一键全接受AI一激动把格式全重排历史记录看着脑壳疼。DeepSeek接入VSCode最常见的是配合Continue或Cline。以Continue为例在它的配置里添加一个provider指向DeepSeek的接口{ provider: deepseek, apiKey: sk-你的密钥, server: https://api.deepseek.com, models: [ { title: DeepSeek Chat, provider: deepseek, model: deepseek-chat } ] }Cline的设置更图形化一些在设置界面把API Provider切换成DeepSeek填入API Key和基础地址https://api.deepseek.com即可模型名填deepseek-chat或deepseek-reasoner。这类聚合型插件有两个值得注意的地方一个是API Key的保存位置不要直接写进项目的配置文件里然后提交到Git仓库我自己就吃过这个亏好在发现及时换了key另一个是模型名称务必按官方文档来填错模型名在调用时会直接报错。我的实测结论AI插件的价值不在于“写代码多快”而在于“查代码多快”。一个冷门的第三方SDK报错让AI去读堆栈和库源码比我挨个翻文档快得多。但因为模型能力、上下文长度的差异涉及业务逻辑核心的改动还是得自己把关节。3.2 SSH远程与WSL插件“装在哪”的另类答案远程开发插件的地址逻辑和本地完全不同。装上Remote-SSH、WSL、Dev Containers这些远程扩展之后本地VSCode和远程端各有一套插件体系。关键的认知是远程端的插件是安装在远程机器上的不是安装在本地扩展目录里的。你通过Remote-SSH连上一台Linux服务器在扩展面板里看到的插件默认是SSH目标机器上的插件目录里的内容。这就意味着你在本地C盘改了插件目录对远程开发场景没有影响远程端依然有自己的扩展位置一般是Linux用户目录下的~/.vscode-server/extensions。这个设计的合理性在于语言服务、格式化工具、调试器本身跑在远程端必须和远程代码在一起。比如连上服务器改Python代码本地VSCode只是编辑器前端真正提供代码补全的Pylance是在远程端运行的。配置Remote-SSH时最常用的是~/.ssh/config文件在VSCode里通过Remote-SSH: Open SSH Configuration File直接编辑写清楚Host、HostName、User、Port就行。连上之后在左下角绿色区域能看到当前主机名切换远程窗口和本地窗口一目了然。WSL场景也是同理。装好WSL插件后要从WSL窗口里打开项目目录而不是在PowerShell里对\\wsl$\Ubuntu\...路径操作。用WSL打开目录后VSCode会启动一个WSL端的扩展宿主工具链用的是Linux版本/mnt/c/xxx这种路径是Windows文件系统挂载操作速度比纯Windows底下跑Linux工具舒服得多。之前有同事在WSL里跑C/C说代码提示出不来检查之后发现他虽然在WSL窗口打开了目录但C/C扩展装在了本地Windows端WSL端那边插件列表里是空的。这个坑很典型远程开发时本地和远程的插件要分别检查本地装了不代表远程有。3.3 Python、C/C、Java语言环境配置里最容易被卡住的点语言类的插件主要解决的是“智能提示、编译运行、调试”三件事。Python环境配置的核心是解释器选择。装好Python扩展和Pylance之后按CtrlShiftP执行Python: Select Interpreter选择当前项目对应的虚拟环境或conda环境。很多人遇到“代码能运行但没提示”“跳转定义跳了个寂寞”的问题八成就是解释器选错了Pylance在拿系统自带的Python去解析项目里的venv包。如果项目里有自定义包目录Pylance默认扫描不到需要在settings.json里补上{ python.analysis.extraPaths: [ ./src, ./lib ] }C/C环境配置则要看IntelliSense模式。装好C/C扩展后打开C文件时右下角会提示选择代码模式。提示不出来或代码高亮正常但没有补全最常见的原因是缺少compilerPath配置。可以在.vscode/c_cpp_properties.json里显式指定{ configurations: [ { name: Linux, includePath: [${workspaceFolder}/**], compilerPath: /usr/bin/gcc, cStandard: c11, intelliSenseMode: linux-gcc-x64 } ], version: 4 }Windows上编译器路径通常是C:\MinGW\bin\gcc.exe或C:\msys64\ucrt64\bin\gcc.exe具体看你装的是MinGW还是MSYS2环境。Java环境我遇到最多的不是装环境而是乱码。Windows下用VSCode跑Java控制台输出中文乱码根源是源码文件编码、编译器编码、控制台编码三者不一致。通常在settings.json里这样处理{ java.debug.settings.consoleEncoding: GBK, java.inlayHints.parameterNames.enabled: none }如果项目用的是Maven或Gradle编译源码时强制指定UTF-8会更稳妥一些避免代码里再出现中文乱码。这一串问题排查下来本质就是对“编码”概念的理解。统一编码之后再遇到乱码就不用玄学重启了。3.4 日常效率插件汉化、Markdown、二维码分享地址除了编程相关日常使用中有一批“提升体验”的插件出现频率很高。中文汉化是最基础的。搜索安装Chinese (Simplified) (简体中文) Language Pack安装后右下角会弹窗提示重启重启后界面就是中文了。如果没弹窗在命令面板里执行Configure Display Language手动切换zh-cn。Markdown相关插件我用得比较多的组合是Markdown All in One加Markdown Preview Enhanced。前者提供自动格式化表格、目录生成、快捷键后者提供更强大的预览。写技术文档、做项目README时能直接在VSCode里预览渲染效果比来回上传到编辑器看省事。还有一个场景被热词提到局域网真机调试时要把电脑上的调试地址分享给手机。有些插件可以直接把当前调试地址转成二维码手机扫一下就能打开。手机和电脑必须在同一个局域网这时候如果你电脑上有一个“Network Unavailable”的状态显示就会遇到下文要说的排查问题。真正装插件的时候我的原则是先看插件最近更新时间超过两三年没更新的插件即使下载量很高也很难适配新版本VSCode容易成为问题源头。其次看扩展面板里的小字“已验证”和安装量这两个指标比搜出来的博客推荐靠谱。4. 插件用起来之后的常见翻车现场排查思路与修复记录4.1 无法跳转到定义八成不是代码的问题“Ctrl点击跳转不了定义”是我被问过最多的问题之一。先放下直觉这个问题的排查链路其实很有规律。先确认插件是不是装了。不同类型代码需要不同的语言服务器Python靠PylanceC/C靠Microsoft C/C扩展JavaScript/TypeScript靠内置TypeScript语言服务。扩展面板里搜不到对应插件跳转自然是废的。再确认语言服务器真的在这个文件上工作。看VSCode右下角状态栏Python文件会显示当前解释器路径C文件会显示IntelliSense模式如果显示“Select Interpreter”或者“Select IntelliSense Mode”说明语言服务器还没就位先点它配置。还有一种很隐蔽的情况文件在磁盘上已经改了但编辑器里还是未保存状态跳转时索引仍是旧的。先CtrlS保存后再跳转。跨文件夹跳转则要确认目标文件夹被包含在同一工作区里否则VSCode不会为工作区外的文件建立索引。如果这些都没问题试一下F12键盘快捷键因为有些主题或插件会把右键菜单里的“转到定义”给替换掉。最后提醒一下settings.json里如果把某个语言服务器的enabled设为false即便插件还开着也不会干活。这种“设置层面关闭”的问题最让人迷惑检查顺序放在最后但往往就是它。4.2 Python函数参数提示不出来问题出在哪热词里有一条“vscode查看函数参数python”。正常情况下在Python代码里输入函数名加左括号的瞬间Pylance会弹出一个参数提示框高亮当前参数按CtrlShiftSpace可以手动唤起。如果这个提示就是不出现按顺序排查三个设置{ editor.parameterHints.enabled: true, editor.hover.enabled: true, python.analysis.typeCheckingMode: basic }第一项控制参数提示第二项控制悬停信息第三项虽然不直接管提示但关闭off时Pylance的分析力度很弱自定义函数经常不认得。还有一个经常被忽略的点函数定义如果写在另一个.py文件里只有当你所在的项目被Pylance正确识别为同一个Python环境跨文件参数提示才会正常。用Python: Select Interpreter重新选一下解释器几乎能解决一半的“Pylance失灵”问题。4.3 Windows下Java控制台乱码的最终解法Java乱码看似是VSCode的锅其实大部分是Windows命令行代码页的问题。老式中文Windows的控制台默认编码是GBK代码页936而Java源码和编译器默认UTF-8两边编码不一致中文输出自然变“锟斤拷”。我的通用做法是三步第一步源码文件统一用UTF-8保存右下角状态栏可以看到文件编码点击可以切换保存时选“Save with Encoding”为UTF-8。第二步在项目构建工具里指定UTF-8。Maven在pom.xml里加properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /propertiesGradle在build.gradle里加tasks.withType(JavaCompile) { options.encoding UTF-8 }第三步处理运行输出。Java扩展的调试控制台默认会用JVM的系统字符集中文Windows下容易走GBK。在VSCode的settings.json里设置Java控制台编码为GBK让它适应系统环境{ java.debug.settings.consoleEncoding: GBK }改完重启VSCode重新跑一遍控制台乱码基本消失。这一步和第二步的UTF-8不冲突一个是站在文件角度定标准一个是站在控制台展示角度匹配系统。4.4 一个关于network状态显示异常的排查思路热词里有一条我很有共鸣“network: unavailable却不显示本地的ip”。我在一次局域网真机调试时遇到过类似现象调试服务确实启动着手机也能通过IP访问但某个插件面板上却始终显示不可用本地IP列表空荡荡。先说结论这类问题绝大多数不是网络真的断了而是插件检测网络时依赖的API拿不到结果。排查链路是这样的。先确认本机IP物理存在Windows上执行ipconfig看以太网或Wi-Fi适配器是否有IPv4地址。如果IP存在再检查网络位置类型在“设置-网络和Internet-属性”里把网络配置文件改成“专用网络”Windows防火墙对专用和公用网络的默认放行策略不同公用网络经常拦掉一些本机服务监听。再看插件设置里绑定的host地址。很多本地服务插件默认绑定127.0.0.1也就是只回环不对外这时候局域网其他设备自然访问不到插件也会认为本机没有可用局域网IP。要对外访问和正常检测需要把绑定地址改成0.0.0.0表示监听所有网络接口。比如Live Server的配置里就有一项liveServer.settings.host默认是127.0.0.1改成0.0.0.0后手机才能访问。还有一个坑在WSL环境里。如果你的代码跑在WSLWindows的IP和WSL的Linux IP是不同的两个地址WSL里运行的服务器要对应WSL网络命名空间里的IP。用ip addr查看WSL内的IP而不是直接在Windows的ipconfig里找。WSL 2默认NAT模式下还得在Windows防火墙里做端口转发或配置镜像网络否则Windows其他程序可能也扫不到它。4.5 Win7还能用VSCode吗老版本用户的现实选择热词里出现了“vscode win7”和“vscode win7版本”说明还有人坚守Windows 7。这部分用户需要知道一个硬事实VSCode从1.70版本之后不再支持Windows 7。这意味着什么第一新版本VSCode根本安不上Win7会提示系统版本过低。第二即便回退安装了1.70.x的老版本扩展市场里越来越多的新插件也在要求更高版本的VSCode老的编辑器根本拉不到新插件更新比如部分新出的AI插件明确要求VSCode 1.85以上。第三老的VSCode版本可能自带一些过期的依赖库安全性也是个问题。现实选择只有两条一是继续用1.70.x最后几个支持Win7的版本同时把插件清单固定在一个相对老但够用的组合里不要指望新功能二是能升级系统还是尽早升级Win7在现代开发工具链里的支持面越来越窄。我们不能替用户做决定但如果目标只是学Python或C语言基础语法老版本VSCode加对应老版本插件也够用只是要接受它像一座“数字化遗迹”能跑但不再生长。5. 给插件目录搬家之后的收尾工作备份、批量恢复与性能控制5.1 用命令行导出和恢复插件清单插件目录搬完家不代表插件管理就万事大吉。我习惯把插件清单当作配置文件一样管理随时可以一键重建环境。列出所有已安装插件的IDcode --list-extensions可以把结果存成文件code --list-extensions extensions.txt在另一台机器或者重装系统后批量恢复Windows PowerShell下这样执行Get-Content extensions.txt | ForEach-Object { code --install-extension $_ }macOS或Linux下这样执行cat extensions.txt | xargs -L 1 code --install-extension这个方式恢复的是插件清单但插件的设置不会跟过来。如果你的插件配置也需要迁移可以用VSCode内置的Settings Sync功能登录账号后同步设置、快捷键、代码片段和已安装插件列表。不过从我实际体验看同步偶尔会遇到合并冲突尤其是多台电脑配置不一致时会弹出一个“哪个版本要覆盖另一个”的选择框这种时候选“当前机器为主”还是“云端为主”得根据具体场景判断别乱点。5.2 直接复制插件目录的注意事项有些人图省事直接把整块extensions目录压缩打包带到另一台机器这确实能恢复插件本体但有几个跨环境的坑。跨操作系统基本不通用。插件目录里有和平台相关的二进制文件、动态链接库把Windows目录搬到Linux里C/C扩展的编译工具链、Python扩展的解析器绑定都会出问题。同操作系统之间复制尽量保持目录结构完整压缩和解压时不要改路径VSCode对插件目录里的符号链接也很敏感。复制时还要避免只复制一部分。插件目录下除了插件本体还有.obsolete、临时缓存文件只复制部分子目录可能导致插件列表里出现“损坏的扩展”提示。我的建议是能用--list-extensions清单重装的就优先用清单重装确实需要整体搬目录的只在同平台、同架构、同版本环境的机器间操作并且复制完整目录。5.3 插件太多拖慢启动先分清CPU杀手和磁盘杀手插件管理还有一个容易被忽视的点性能。VSCode启动时扩展宿主进程会加载启用的插件插件越多冷启动时间越长。我发现很多人的插件装在“备用”其实一年都用不上一次。判断哪些插件在拖慢速度可以装一个Startup Time之类的性能统计插件或者直接按CtrlShiftP执行Developer: Show Running Extensions看扩展宿主进程的CPU占用。实测下来大体积的AI插件、远程开发插件、语言服务器插件是启动大头主题插件和代码片段插件几乎可以忽略。分类处理不常用的但偶尔需要的插件禁用而不是卸载需要时右键启用这样既不占启动时间也保留配置明确不再使用的直接卸载卸载按钮在扩展页面的齿轮菜单里。我最后分享一个个人习惯每个月末尾快速过一遍扩展面板按“最近更新”排序看看有没有插件长期没更新顺便清理那些安装日期很久但一次都没用过的。这个习惯让我的VSCode一直保持启动三秒内的状态。C盘空间问题解决了插件质量跟上整个编辑体验会清爽很多毕竟工具这回事终究是越用越顺手。