1. 为什么这个问题值得专门写一篇看着碍眼删着心虚先说说我为什么会折腾这个。VS Code 用久了左侧活动栏的资源管理器顶部会挂一串最近打开的文件夹和工作区。平时倒还好但当你同时维护两三个项目、开过一堆临时目录、或者帮同事排查过问题之后那个列表就会变成一锅粥。更烦的是某些文件夹实际已经挪走或删掉了点击只会报错可它依然顽固地躺在那个列表里每次打开 VS Code 都得看它一眼非常影响心情。我最初的想法很简单——直接找settings.json删配置。结果翻了半天发现 VS Code 的配置文件里压根没有最近打开列表这一项。后来才知道这类界面状态根本不住在配置文件里而是存在专门的状态数据库文件中。于是问题就从删配置文件的哪一行变成了搞清楚 VS Code 到底把状态存在了哪里。这两者的排查思路完全不同也是我想在这篇文章里重点讲的。如果你也想清理自己 VS Code 里那一堆失效的文件夹和工作区记录这篇文章适合你如果你想弄明白 VS Code 的配置体系是怎么分层存放的这篇文章同样值得一读。2. 先搞清楚配置文件体系settings.json、storage 和状态库2.1 VS Code 的配置分成两套体系在动手删除之前必须先把 VS Code 的存储机制说清楚否则很容易白忙活。VS Code 的用户数据主要分两块一是我们熟悉的settings.json存的是编辑器偏好、插件设置、快捷键绑定这些配置项二是界面状态和进程数据比如最近打开列表、窗口布局、已展开的折叠区域、断点列表等这些并不是常规意义上的配置而是运行时产生的状态VS Code 不会把它们写进settings.json而是存到了另外一个地方。这个区分非常关键你删掉settings.json里某个字段顶多是恢复默认行为但你删掉状态库里的数据才能让最近打开列表这类界面元素真正重置。换句话说清理文件夹和工作区记录本质上不是改配置文件而是操作状态库。我一开始在settings.json里找recentFolders、workspaces之类的关键字当然是找不到的。2.2 用户状态到底存在哪里那这些状态存在哪以 Windows 为例如果你的用户目录是C:\Users\你的用户名VS Code 的整个数据目录就是C:\Users\你的用户名\AppData\Roaming\Code往里看比较重要的是这样几个目录路径大致用途User\settings.json用户级配置User\workspaceStorage工作区级别缓存每个工作区一个子目录User\globalStorage跨工作区的全局状态logs运行日志Cache、CachedData缓存可安全清理而我们要找的最近打开列表通常不在workspaceStorage里而是在User\globalStorage下的状态数据库中。不同 VS Code 版本这个文件可能叫state.vscdb也可能路径结构略有差异但大方向是一致的。2.3 验证一下你的版本如果你不确定自己的版本对应什么结构可以打开 VS Code 后按CtrlShiftP输入Developer: Open User Data Folder它会直接帮你打开当前用户的数据目录。这一步能明确看到globalStorage、workspaceStorage等目录然后我们才能继续下面的操作。提示在修改任何状态库文件之前请务必先关闭 VS Code 所有窗口尤其是把右下角托盘里的 VS Code 后台进程也退出。状态数据库在程序运行时可能被锁住且正在运行时的写入极容易把数据弄脏。3. 从删到清几种逐级深入的处理方式3.1 最省事的方法直接把条目从列表里移除如果你的需求只是让某个失效的文件夹从最近打开里消失而不是重置全部历史那最简单的方式是鼠标悬停到该条目上右键选择Remove from Recently Opened从最近打开中移除。这个方法不需要碰任何文件立即生效适合单独清理几个碍眼的条目。但这个方法的局限也很明显它一次只能处理一条而且如果你有几十条历史记录或者你想彻底清空这个列表手动一条条右键删除效率太低。更麻烦的是有些失效条目可能不会出现在右键菜单里或者已经被某些插件改动过位置这时候就需要下面更彻底的办法。3.2 界面内批量清空开发者命令的妙用VS Code 的命令面板里藏着一个不太为人知的命令——Developer: Reset Workspace State。执行它会重置当前工作区的所有本地状态包括工作区级别的布局、UI 状态等。这算是一个更官方的狠招但它主要针对当前打开的工作区覆盖面不是全局最近打开列表所以如果你的目标是全局清理所有历史记录这个命令帮不上太多忙。更接近目标的做法是直接操作全局状态库。VS Code 自身没有提供清空所有最近打开的按钮这点确实不如一些其他编辑器体贴。所以想要彻底清理绕不开下面的手动方案。3.3 直接操作状态库用 SQLite 改数据现在我们进入核心操作。state.vscdb本质上是一个 SQLite 数据库VS Code 的界面状态、文件历史、工作区历史等都可能以键值对的形式存在里面。先找到这个文件Windows 路径参考C:\Users\你的用户名\AppData\Roaming\Code\User\globalStorage\state.vscdbmacOS 通常在~/Library/Application Support/Code/User/globalStorage/state.vscdbLinux 通常在~/.config/Code/User/globalStorage/state.vscdb注意不同发行版或版本的 VS Code这个文件名和目录层级可能会有轻微差异但关键词是globalStorage里的state.vscdb。如果你打开数据目录后没找到这个名字可以往下看看有没有类似state.vscdb-wal、state.vscdb-shm之类的伴随文件那说明库文件本身存在只是被连接着。有了目标文件接下来需要 SQLite 工具。Windows 上可以用DB Browser for SQLite或者直接在 VS Code 里装一个 SQLite 插件没错我们就是用编辑器来改编辑器自己的状态库。操作前强制建议先复制一份state.vscdb作为备份毕竟这是自己日常开发环境的状态万一改坏了还能恢复。打开数据库后表名叫ItemTable字段包括key和value。与最近打开相关的键通常长得像history.recentlyOpenedPathsList。这个键里存放的 value 是一个 JSON 结构里面按entries数组列出所有最近打开过的文件夹和工作区每条记录包含folderUri或workspaceUri以及对应的显示名称。我们有两种改法精确删除某几条把value中的 JSON 解析出来筛选掉不需要的条目再把 JSON 写回。彻底清空直接把这个键值的value改成{entries:[]}或者简单粗暴地删除该行记录。删除后 VS Code 会按默认行为生成一个空的最近列表。我个人的经历是解析 JSON 再改的方式最可控。因为一旦你删除了整行VS Code 虽然会自动重建但某些 UI 状态可能不如预期。只把entries数组清空界面会显示一个干净的最近打开区域行为也更接近重置。注意改完 SQLite 后重启 VS Code 才会看到效果。另外state.vscdb在 VS Code 运行时还会伴随-walWrite-Ahead Log和-shmShared Memory文件如果直接用外部工具改库务必将三个文件一起退出锁定否则可能出现写不进去或数据不一致的问题。3.4 备用方案删除工作区级状态目录如果你只想清理某个特定工作区的状态而不是全局最近记录可以直接去User\workspaceStorage下删除对应的子目录。每个子目录对应一个工作区命名是一串哈希值。怎么确认哪个目录对应哪个工作区看子目录里的workspace.json文件里面有folder字段写的就是实际路径。删除该目录后那个工作区相关的窗口状态、断点记录、UI 布局都会被重置。这个方案适合那种这个项目怎么开怎么怪的情况比如某个工作区里插件状态错乱、面板布局异常删掉对应目录比全局重置影响面小得多。但要注意它不会把该工作区从最近打开列表里移除——因为最近打开列表是全局的这和数据存放层级有关。4. 实测排查全过程案例与排错思路我整理了一个我前两天真实处理的场景尽量把排查链写完整方便你照着复现思路。先说问题背景我的最近打开列表里有大概十几个条目其中有三四个明显是旧项目路径其中一个甚至整个磁盘分区都已经不在了。当时我想直接用上面 3.3 的方法清理于是打开state.vscdb但在 SQLite 里搜索history.recentlyOpenedPathsList时发现有两个类似的键一个是history.recentlyOpenedPathsList另一个是history.recentlyOpenedPathsListPopularity。第一次我改了第一个键里的 JSON重启后列表确实发生了变化但旧路径还残留了一部分。后来才注意到VS Code 的最近打开列表其实有两种排序逻辑一种是纯时间顺序的 MRUMost Recently Used另一种是按打开频率排序的 Popularity。这两套数据都可能同时生效所以只改其中一个键列表数据源还是会从另一个键里补齐一部分。最后我把两个键里的 JSON 都做了清理列表才彻底正常。再有一个容易踩的坑你在 SQLite 里看到的value值大部分是 JSON 字符串但有些版本的 VS Code 会对数值进行转义或换行直接拿去解析容易报错。稳妥的处理是用 SQLite 的查询功能先把值取出来复制到任意编辑器里格式化确认一遍结构再修改。只要 JSON 解析不报错写回去基本问题不大。还有一次我改完数据库重启发现列表纹丝不动。核查原因后发现是 VS Code 没有完全退出——系统托盘里还挂着后台进程外部工具写入时被文件锁挡住了表面提示写入成功实际没有落盘。所以后面我养成了习惯改动之前先打开任务管理器或 Mac 的活动监视器确认所有Code.exe/code-*相关进程全部结束。这一步虽然不是技术含量最高的却是最容易被忽略的重点。5. 分类对比什么时候改数据库什么时候删目录为了让你少走弯路我把几种情况按症状-处理方式-影响范围做个对比。症状推荐处理方式影响范围最近打开列表混入失效路径想单删几条右键移除 / 改state.vscdb中的history.recentlyOpenedPathsList全局最近列表最近打开列表想一键全清改state.vscdb把 entries 清空或删除键值全局最近列表某个工作区打开后布局混乱、状态异常删除workspaceStorage下对应子目录仅该工作区想彻底重置整个 VS Code 用户状态备份后删除整个User目录或使用官方重置机制所有配置与状态强烈不建议盲目操作从实际效果看大部分普通用户的诉求就是前两行也就是清理最近打开列表后两行更多是开发者在调试插件或测试环境时才用得上的手段。分清这四个层级就不会每次一遇到界面不对劲就直接删掉整个User目录把好好的界面主题、快捷键配置全卷走了。6. 动手前别忘的备份与风险控制6.1 备份策略不管用哪种方式改动状态库前备份永远不嫌多。最少要把state.vscdb文件复制一份放到桌面或项目目录外。更稳妥的做法是连globalStorage目录一起复制里面偶尔会存放插件的一些全局状态比如登录信息缓存、扩展缓存等。备份完再动手改完即使发生意外也有后悔药吃。6.2 安全边界还有一个容易被忽略的点state.vscdb里除了最近列表还存了很多插件的持久化状态比如某些插件记录的窗口尺寸、认证 token、缓存数据等。不要一时兴起把整行全删光更不要用清空数据库这种操作来图省事。你只想清扫记录没必要让 VS Code 所有插件重新初始化一遍。最安全的方式始终是定位到具体键名只改目标键的value尽量不要动其他行。从另外一个角度看这也是很多人一劳永逸失败的原因。网上很多文章教你直接删掉整个globalStorage文件夹这样做的确会让最近记录消失但与此同时所有插件状态也一并重置重新打开 VS Code 时你需要重新登录插件、重新设置窗口布局代价相当大。就为了清理一个最近列表付出这个成本不值得。6.3 恢复手段万一改坏了怎么恢复把之前备份的state.vscdb复制回原路径覆盖损坏文件然后重新启动 VS Code 即可。如果你的备份只有这个单文件而操作时已经新产生了很多新的状态写入可能会丢一小段统计数据比如最近打开列表里新增的几条但核心功能不会受影响顶多回退几天的状态而已。整体来看VS Code 的这套配置文件体系在主流编辑器里属于相当清晰的但它把用户配置和用户状态分开存储的设计经常让习惯了settings.json的熟练用户也迷路。当你理解了settings.json只管偏好、state.vscdb管界面状态、workspaceStorage管工作区现场这三层关系之后不仅清理最近记录变得简单以后再遇到窗口错乱、插件数据异常之类的问题也能直接判断该动哪一层不用再靠重装解决问题。我个人在做这类清理时越来越倾向于用第三条路把state.vscdb里最近打开列表的 JSON 拿出来在外部编辑器里处理完再写回去。虽然比右键删除多几步但它可控、可批量、可逆。如果你只是想快速处理一两条那自然直接右键更快但如果你希望以后每次打开 VS Code 都能看到一个干净清爽的列表那么花十分钟备份、定位、改 JSON绝对是一劳永逸的事情。