VS Code 清理：扩展、缓存和旧工作区留下的垃圾

VS Code 把 GB 藏在哪

VS Code 存的所有东西都在 %APPDATA%\Code 下面，四个子文件夹干了大部分囤积的活。User\workspaceStorage 为你打开过的每个文件夹——包括已删除的项目——各留一份状态目录，而且没有任何东西会自动修剪它。Cache、Code Cache 和 GPUCache 是 Chromium 的惯犯，不停重建、随时可安全清空。logs 为你启动过的每个会话写一个新文件夹，CachedExtensionVSIXs 则把扩展更新的安装包留到早就没人需要之后。

再加上 %USERPROFILE%\.vscode\extensions——更新后孤儿旧版本扩展有时还会活在那里——重度使用的编辑器安装就能一声不吭地超过 5 GB。这些位置没有一个存着你的设置或快捷键——那些在 User\settings.json 里，任何缓存清理都碰不到。

%APPDATA%\Code\User\workspaceStorage —— 打开过的每个文件夹的项目级状态；老机器上最大的单一囤积点
%APPDATA%\Code\Cache、Code Cache、GPUCache —— Chromium 缓存，删除安全，下次启动重建
%APPDATA%\Code\logs —— 每个会话一个文件夹；从没东西修剪它
%APPDATA%\Code\CachedExtensionVSIXs —— 更新后被留下的扩展安装包
%USERPROFILE%\.vscode\extensions —— 更新后残留的孤儿旧版扩展
Local History 的 .history 文件夹 —— 若启用了该扩展则位于项目内部；旧快照会在仓库里堆积

扩展才是真正的性能税

存储只是问题较小的一半。每个扩展都加载进共享的 extension host 进程，而那些大块头——Pylance、C/C++、TypeScript 服务器这类语言服务器，加上 linter 和主题——不管你用不用，各自都要吃掉几百 MB 内存。启动也会被拉长：Developer: Startup Performance 命令能精确显示哪个扩展花了多少毫秒，而这些数字总能吓到装了六十个扩展的人。

用 code --list-extensions 做次盘点，然后该卸载就卸载、别只是禁用——被禁用的扩展仍躺在磁盘上，有时甚至照样加载。Profiles 功能是单体安装的诚实解法：一个精简的默认配置，加上 Python、写作、纯终端等各自独立的配置，每个只带自己需要的扩展。

一套能坚持下来的清理流程

一年两次足够：关掉 VS Code，删掉 Cache、Code Cache、GPUCache、logs 和 CachedExtensionVSIXs 的内容，并整个清空 workspaceStorage——你丢的是任务历史这类工作区级状态，不是设置。什么都不会被重装或重置。编辑器会在下次启动时重建所需内容，清理后的第一次启动慢几秒，仅此一次。

想保持精瘦，就把扩展当已安装的程序而不是贴纸：每一个都得有当前存在的理由。迁往新机器前，先做一次清理——否则你会把 2023 年就死掉的项目那三年的 workspaceStorage 也拷过去。