最近接手了同事的一台电脑他抱怨VS Code越来越“卡”我打开一看好家伙最近打开的文件夹和工作区列表攒了几百条光找自己的项目就得翻半天。他问我能不能把这些历史记录清掉我把几种方法都试了一遍发现这里面的门道远比想象中多值得写出来给同样被困扰的人。先说清楚这个问题的本质VS Code把“文件夹和工作区”的历史记录存在了一个SQLite数据库文件里而不是大家熟悉的settings.json。所以很多人改了半天配置文件发现没用就是因为找错了地方。这篇文章我打算从原理讲到实操覆盖Windows、macOS和Linux三种系统把单条删除、批量清理、数据库直改、防止自动记录这几个层面都过一遍看完你就能彻底掌控VS Code的“记忆”。1. 先搞懂VS Code把历史记录藏在了哪里1.1 打开过的文件夹和工作区到底存在哪个文件里VS Code的配置体系分三层用户级、工作区级和文件夹级。平时大家熟悉的settings.json属于用户级配置存的是编辑器外观、快捷键、扩展设置这些内容。但“最近打开的文件夹和工作区”这类动态产生、频繁更新的数据被单独存到了state.vscdb这个数据库里。具体位置按操作系统区分Windows%APPDATA%\Code\User\globalStorage\state.vscdbmacOS~/Library/Application Support/Code/User/globalStorage/state.vscdbLinux~/.config/Code/User/globalStorage/state.vscdb如果你用的是Insider版或其他分支路径里的Code要换成Code - Insiders之类原理一样。state.vscdb是一个SQLite数据库文件VS Code用它来存各种各样的状态信息最近打开的文件列表、窗口布局、面板状态、扩展的持久化数据等。它遵循一个固定的键值结构表名叫ItemTable里面有两个核心字段key存键名value存序列化后的值。我们关心的历史记录对应的key一般是workbench.files.openedEditorsList和workbench.files.history前者记录打开过的编辑器后者记录打开过的文件夹和工作区。我第一次找到这个文件的时候还很惊讶一个以轻量著称的编辑器底层居然用了数据库存状态。后来一想这设计其实很聪明SQLite查询和写入效率高而且结构化的存储方式比解析JSON更利于增量更新。这也解释了为什么VS Code打开再多的历史记录都不卡——数据库查询根本不是瓶颈。1.2 为什么这些记录这么“顽固”很多人在网上搜“如何删除VS Code历史记录”搜到的答案五花八门有说改settings.json的有说删storage.json的有说把整个Code文件夹删掉的但这些方案要么没效果要么后患无穷。记录“顽固”的原因在于VS Code的多层缓存机制。当你通过界面“移除”某条记录时VS Code只更新了state.vscdb里的列表字段但UI上展示的欢迎页、快速打开列表、文件菜单的最近记录都从不同的数据源读取有时候内存里的缓存还没刷新你看到的记录就像没删掉一样。还有一个更隐蔽的点VS Code会为每个文件夹或工作区生成一个workspaceStorage目录里面存放该工作区的独立状态。即使你从历史记录里删掉了这个文件夹的入口它在workspaceStorage里的数据仍然占用磁盘空间。这就是为什么有些人的VS Code越用越臃肿——表面上看历史记录没几条实际上积累的工作区缓存已经有一两GB了。理解了存储机制清理思路就清晰了操作state.vscdb里的数据决定“显示与否”操作workspaceStorage目录决定“数据是否残留”两者配合才能彻底干净。2. 不碰配置文件也能删记录的两种常规操作2.1 单条记录移除右键菜单的操作细节如果你只需要删掉某一条不想要的记录完全没必要去动数据库VS Code自带的界面操作就够了。但这里有个细节很多人没注意到在不同界面移除记录的入口位置不一样。从欢迎页移除启动VS Code后欢迎页底部会显示“最近”列表把鼠标悬停在某一条记录上右侧会出现一个叉号图标点一下就能移除。这个操作最直观但它只对“出现在欢迎页上的条目”生效。从文件菜单移除点击顶部菜单栏的文件→打开最近的Windows/Linux或File→Open RecentmacOS在弹出的子菜单里每条记录右侧也有叉号。这里和欢迎页的区别在于文件菜单展示的记录更多但部分版本不会显示叉号需要按住Shift再点记录才能调出移除选项。我测试过几个版本1.70之后的版本大多可以直接点叉号老版本则必须配合Shift键操作这点容易踩坑。从资源管理器移除如果你当前正打开着某个文件夹想把它从历史里抹掉可以右键点击资源管理器顶部的文件夹名称选择“从最近打开中移除”。这个操作只影响历史记录文件夹本身仍然打开着关掉窗口后才会真正“消失”。界面操作适合处理零散的几条但如果历史记录已经积累了几十上百条一段一段地移会让人崩溃这时候需要下面的批量方案。2.2 批量清理通过快捷键和面板组合操作VS Code内置了一条命令可以清空所有历史记录但入口藏得比较深。按CtrlShiftPmacOS是CmdShiftP打开命令面板输入开发人员: 清空最近打开的文件历史记录英文版是Developer: Clear Recent Files History回车执行即可。执行完这条命令后界面上的记录会立即清空。这个命令的作用范围比界面右键更广它同时清理了workbench.files.openedEditorsList和workbench.files.history两个键的数据算是一次性清理的“官方途径”。如果你连命令面板都不想用可以直接在settings.json里把workbench.startupEditor改成none这样每次启动VS Code就直接进入空白编辑器不展示欢迎页自然也就看不到“最近打开”那一栏了。但这个设置只是“眼不见为净”并不真正删除历史数据数据库里的内容依然在。适合那些看到历史列表就心烦、打算眼不见心不烦的人。2.3 关闭启动时自动恢复的开关和使用习惯紧密相关的是自动恢复机制。VS Code默认会在重启后自动打开上次未关闭的窗口和文件这个功能由window.restoreWindows设置控制默认值是all。如果你经常一次性打开十几个文件夹又不希望它们全被记下来可以改成none启动时永远空白或one只恢复上次活动的一个窗口。这里有个容易混淆的点window.restoreWindows控制的是“启动时恢复哪些窗口”而开头提到的workbench.files.history控制的是“历史列表里记录什么”两者功能不同但都影响你看到的“最近打开”内容。我见过不少人在改restoreWindows后发现历史记录还在以为是设置没生效其实是改错了开关。3. 进阶玩法直接编辑state.vscdb数据库3.1 找到并备份state.vscdb界面操作和内置命令虽然方便但控制粒度还是不够细。比如你可能只想去掉某个特定路径的记录或者想把整个历史列表替换成自己的一份清单这时候就需要直接操作数据库。操作数据库的第一步是备份。虽然SQLite的更新操作本身不会破坏数据结构但VS Code作为运行中的程序可能在毫秒级内对同一文件进行读写。我建议在动手前先做两件事彻底退出VS Code不只是关窗口要确认托盘图标也没了把state.vscdb以及同目录下的state.vscdb.backup如果有的话复制一份到安全位置备份命令参考# Windows PowerShell Copy-Item $env:APPDATA\Code\User\globalStorage\state.vscdb $env:APPDATA\Code\User\globalStorage\state.vscdb.bak # macOS / Linux cp ~/Library/Application\ Support/Code/User/globalStorage/state.vscdb ~/Library/Application\ Support/Code/User/globalStorage/state.vscdb.bak备份的好处不用多说数据库文件操作不同于文本文件一旦写错了又没有备份VS Code可能启动后各种状态错乱虽然大概率不会坏到必须重装但恢复成本远高于提前复制一份。3.2 使用DB Browser for SQLite清理历史记录修改SQLite数据库我推荐用DB Browser for SQLite因为它免费、跨平台、支持可视化操作比命令行直观得多。安装后打开state.vscdb切到“浏览数据”标签页选择ItemTable你会看到两列数据key和value。在key字段里搜索history你能找到类似workbench.files.history的条目。选中这一行在value字段里就能看到完整的JSON数组里面包含所有历史记录。这个JSON的结构大致长这样{ entries: [ { folderUri: file:///D:/Projects/MyApp, label: MyApp, remoteAuthority: null }, { folderUri: file:///D:/Projects/Other, label: Other, remoteAuthority: null } ] }要清理可以直接把value改成{entries:[]}也可以只删掉你不想要的entries里的某个对象。改完之后点击“写入更改”关闭DB Browser重新打开VS Code就能看到效果。这个方案最大的优势是精确。界面操作只能“全部移除”或“右键单条移除”直接改数据库则可以做到“保留一部分、清空另一部分”甚至可以在外部批量编排好一份路径列表再粘贴进去效率极高。适合历史记录非常多、想精准保留工作路径的高级用户。3.3 常见误区和容易删错的键操作数据库时容易踩的坑我挨个说一遍。误区一把整个ItemTable清空。看起来最省事实际上会把VS Code的窗口状态、快捷键状态、扩展数据一股脑删掉后果是重新打开时需要重新配置很多东西还会让部分扩展的登录状态失效。清空整个表等于给VS Code做了一次“格式化”代价太大。误区二删了openedEditorsList没删history。workbench.files.openedEditorsList记录的是当前打开的编辑器标签页workbench.files.history记录的是文件夹和工作区的历史。只删前者你的“最近打开文件夹”还在只删后者“最近打开的编辑器”还在。想彻底干净两个键都要处理。误区三以为改完立即生效。VS Code启动时会读数据库运行期间也会周期性写回。如果你在编辑器运行状态下改了数据库保存过的内容很可能在下一次VS Code写回时被覆盖掉。这就是我前面强调要先退出VS Code的原因。误区四把Remote相关记录当成普通文件夹删。如果你用过SSH远程开发历史列表里会有形如vscode-remote://ssh-remote主机名/路径的记录。这类记录看起来像是普通URI但直接删了可能会影响远程扩展的状态。如果你不再需要这个远程主机建议通过扩展面板移除远程扩展再清理历史记录顺序错了容易留下残留数据。4. 彻底重置工作区信任与配置防复发4.1 清理工作区信任记录删完历史记录只是第一步。VS Code的“工作区信任机制”也会在文件系统里留下痕迹。每当你在一个不受信任的文件夹中打开项目VS Code会记住这个文件夹的信任状态这些记录同样存在state.vscdb中只不过用的键名是workbench.trustedWorkspaces。信任记录带来的问题在于如果你曾在一个临时目录或者共享文件夹上点过“信任”这个条目会一直存在。如果你出于安全考虑想撤销这个信任光靠设置面板是找不到入口的。操作方式还是在DB Browser里搜索trustedWorkspaces把对应的value改成一个空数组[]。改完之后下次打开这些文件夹时VS Code会重新弹出信任提示框。整个过程不影响其他配置风险极低但也别没事就清频繁重置信任反而会让每次打开项目都多一步确认拉低效率。4.2 如何防止记录“春风吹又生”“删了又冒出来”是问得最多的问题。其实VS Code记录历史是功能设计不是bug你要防止的是“不想被记录的内容被记下来”。这里有几个从根上解决的办法方案一设置里的自动忽略规则。在settings.json中可以加入{ files.exclude: { **/node_modules: true, **/.git: true } }严格来说这套规则影响的是资源管理器显示不是历史记录。但它的副作用是如果一个文件夹里的所有顶层文件都被排除VS Code在记录历史时会更倾向于不收录它。方案二用window.newWindowDimensions配合工作区文件管理。如果你经常同时用多个工作区可以考虑用.code-workspace文件统一管理入口不直接打开各个文件夹的根目录。VS Code对工作区文件的记录和维护策略和文件夹不同工作区文件可以丢在统一目录里通过它进入项目文件夹本身就不会出现在“最近打开”列表里。方案三定期清理脚本自动化。既然记录都在SQLite里写个脚本定期清理完全可行。比如用Python的sqlite3模块每隔一段时间把workbench.files.history重置一次import sqlite3, os, sys path os.path.expanduser(~/Library/Application Support/Code/User/globalStorage/state.vscdb) conn sqlite3.connect(path) cur conn.cursor() cur.execute(UPDATE ItemTable SET value {\entries\:[]} WHERE key workbench.files.history) conn.commit() conn.close()不过这样的脚本有点一刀切如果哪天想保留某条记录还得先把脚本停掉。我自己的做法是维护一个白名单文本文件脚本启动时读取白名单把不在名单里的记录全部清掉这样既省心又精准。4.3 其他configuration里的隐私清理项既然打开了state.vscdb顺手把其他涉及隐私的状态也清理一遍是性价比最高的。除了前面提到的history和trustedWorkspaces还有几个值得关注的键workbench.activity.pinnedViewlets固定的活动栏视图这是你自己主动固定的一般不清理。window.workspaceManagement工作区管理相关的缓存数据。extensionsIdentifiers/disabled禁用扩展的记录卸载扩展后这里可能残留。editor.size、workbench.grid布局状态如果调整过窗口布局且不想保留也可以一并重置。每个键的具体用途不同清理前最好先看一眼value的内容再决定动不动。一个相对安全的“保守清理”是只清history和trustedWorkspaces其他一律不动避免影响扩展和布局功能。5. 常见问题速查与避坑经验5.1 高频问题对照表问题现象根本原因解决方案右键移除后记录还在数据未写入或UI未刷新彻底退出VS Code后重启确认数据库是否仍含该记录命令面板找不到“清空历史”命令版本过旧或使用了不同语言locale切换到英文语言包或直接用DB Browser清理删了历史但文件夹仍占用磁盘workspaceStorage缓存未清删除对应的workspaceStorage子目录远程主机的记录删不掉远程扩展的数据独立存储先卸载对应远程扩展再清理历史记录修改数据库后VS Code启动异常数据库被改坏或值格式错误用备份文件恢复重新按正确JSON格式修改历史记录自动恢复并复现窗口恢复机制重新添加设置window.restoreWindows为none5.2 我踩过的三个坑第一个坑是没退出VS Code就修改数据库。有一次我开着编辑器直接删history删完发现重启后历史记录原封不动。原因很简单VS Code关窗时会把自己内存里的数据反写回state.vscdb我在外部做的修改被覆盖了。后来凡是动数据库我都是先确认进程全部退出才操作。第二个坑是误删了workbench.files.exclude相关的值。本来想清理文件监视的排除项结果把整个ItemTable里的一个无名键当成残留数据删了导致资源管理器的文件过滤规则全部失效node_modules目录瞬间铺满视野。最后只能靠备份文件恢复白白折腾了半小时。第三个坑是workspaceStorage目录的手动清理。某次我为了彻底删除某个大项目的缓存直接在文件管理器里把对应的哈希目录连根删除。结果VS Code启动时发现工作区存储丢失弹了一堆“无法加载工作区状态”的提示部分扩展的本地数据也没了。正确的做法是删之前确认不再需要该工作区的任何设置或者至少把workspace.json备份出来。5.3 备份习惯与后续维护经过多次鼓捣我现在养成了一个固定的清理流程每月底对globalStorage目录做一次整体备份然后清空历史记录和信任记录再检查一下workspaceStorage里有没有超过三个月没访问过的大目录确认无用后手动删除。备份用PowerShell一句话就能搞定Compress-Archive $env:APPDATA\Code\User\globalStorage $env:USERPROFILE\Desktop\vscode_global_backup.zip这个习惯让我在后续折腾扩展配置、迁移设置时省了很多力气。文件不大压缩完通常也就几十MB放在桌面上不碍事真遇到问题时就是救命稻草。6. 顺着这个思路还能解决什么处理完历史记录清理后顺手把VS Code的本地缓存也梳理了一遍发现几个相关的优化点一并分享。扩展缓存目录C:\Users\你的用户名\.vscode\extensionsWindows或~/.vscode/extensionsmacOS/Linux下卸载不彻底的扩展会留下版本号不同的旧版本目录。这些目录不会影响日常使用但会拖慢扩展加载速度。定期把这里清理一遍VS Code启动可以快不少。删除时只保留当前在用的版本目录其余统一删掉。CachedData目录%APPDATA%\Code\CachedData下存放的是VS Code界面渲染的缓存数据体积能到几百MB。这个目录删掉不影响任何配置VS Code会重新生成。适合磁盘空间告急时清理。我试过在清理完历史记录和缓存后做一次对比编辑器冷启动时间从原来的5到6秒降到了3秒左右虽然不全是清理历史记录的功劳但“轻装上阵”的感觉是实实在在的。VS Code本身设计得再优秀用久了积累的冗余数据也会拖慢启动和响应速度定期做一次清理和维护比无止境地加扩展、改配置更管用。