最近接手了同事的一台电脑，他抱怨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.vscdb - macOS：
~/Library/Application Support/Code/User/globalStorage/state.vscdb - Linux：
~/.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 Recent（macOS），在弹出的子菜单里，每条记录右侧也有叉号。这里和欢迎页的区别在于，文件菜单展示的记录更多，但部分版本不会显示叉号，需要按住Shift再点记录才能调出移除选项。我测试过几个版本，1.70之后的版本大多可以直接点叉号，老版本则必须配合Shift键操作，这点容易踩坑。
从资源管理器移除：如果你当前正打开着某个文件夹，想把它从历史里抹掉，可以右键点击资源管理器顶部的文件夹名称，选择“从最近打开中移除”。这个操作只影响历史记录，文件夹本身仍然打开着，关掉窗口后才会真正“消失”。
界面操作适合处理零散的几条，但如果历史记录已经积累了几十上百条，一段一段地移会让人崩溃，这时候需要下面的批量方案。
2.2 批量清理：通过快捷键和面板组合操作
VS Code内置了一条命令可以清空所有历史记录，但入口藏得比较深。按Ctrl+Shift+P（macOS是Cmd+Shift+P）打开命令面板，输入开发人员: 清空最近打开的文件历史记录（英文版是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为none |
5.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\extensions（Windows）或~/.vscode/extensions（macOS/Linux）下，卸载不彻底的扩展会留下版本号不同的旧版本目录。这些目录不会影响日常使用，但会拖慢扩展加载速度。定期把这里清理一遍，VS Code启动可以快不少。删除时只保留当前在用的版本目录，其余统一删掉。
CachedData目录：%APPDATA%\Code\CachedData下存放的是VS Code界面渲染的缓存数据，体积能到几百MB。这个目录删掉不影响任何配置，VS Code会重新生成。适合磁盘空间告急时清理。
我试过在清理完历史记录和缓存后做一次对比，编辑器冷启动时间从原来的5到6秒降到了3秒左右，虽然不全是清理历史记录的功劳，但“轻装上阵”的感觉是实实在在的。VS Code本身设计得再优秀，用久了积累的冗余数据也会拖慢启动和响应速度，定期做一次清理和维护，比无止境地加扩展、改配置更管用。
