最该优先清理的是WorkspaceStorage、Cache、CachedData、Backups及Java用户的.jdt/index；需先彻底退出VSCode，再删除对应子目录，重启后自动重建，不丢失settings.json等配置。
VSCode 启动慢、卡顿、内存高，90% 是缓存堆积 + 扩展乱跑共同导致的，不是硬件问题，也不是必须换编辑器。
哪些缓存最该优先清理？
真正拖慢 VSCode 的不是“所有缓存”，而是几类高频写入、易腐化、且不自动回收的缓存：
-
WorkspaceStorage：保存每个工作区的 UI 状态（折叠状态、终端标签页、打开的编辑器顺序等），长期不清理会积累大量冗余键值，尤其在频繁切换项目后 -
.jdt/index（Java 项目）：JDT-LS 语言服务器的索引缓存，损坏或过期时会导致 CPU 持续 100% 扫描~/.m2/repository -
Cache和CachedData目录：存放渲染快照、语法高亮缓存、字体度量等，旧版本升级后常残留不兼容数据 -
extensions下的插件缓存（如 ESLint、Prettier 的 node_modules 副本）：某些扩展会在自己目录里再装一遍依赖，重复占用磁盘和内存
怎么安全又彻底地清掉它们？
别直接删整个 Code 目录——你会丢 settings.json 和 snippets。只动明确知道作用的子目录：
- 先完全退出 VSCode（macOS 要在 Dock 右键选 “退出”，Windows 检查任务管理器有没有残留
Code Helper进程） - 定位用户数据根目录：
macOS：~/Library/Application Support/Code
Windows：%APPDATA%\Code
Linux：~/.config/Code - 进到该目录后，删除以下文件夹（不是文件）：
WorkspaceStorage（放心删，重启后自动重建）CacheCachedDataBackups（除非你真需要未保存的草稿） - Java 用户额外清理：
~/.cache/.jdt/index或XDG_CACHE_HOME/.jdt/index（Linux/macOS）；Windows 则清%APPDATA%\Code\User\globalStorage\redhat.java\index
为什么有时候清完还是卡？关键遗漏点
缓存只是表象，真正让缓存“反复变脏”的是运行时行为：
-
files.watcherExclude没配：哪怕删了node_modules缓存，只要没在.vscode/settings.json里加"**/node_modules/**": true，VSCode 下次启动仍会尝试监听它，瞬间打满 inotify 句柄 -
java.jdt.ls.vmargs内存设太小：Java 项目清完缓存后首次重索引，若-Xmx仍为默认 1G，会频繁 GC 导致界面冻结，建议至少设-Xmx2G - Remote-Containers 没挂载命名卷：每次容器重建都重装
node_modules或venv，缓存根本存不住——得在devcontainer.json里用mounts显式绑定 Docker 卷 - 同步功能开着却不清
sessions：路径%APPDATA%\Code\User\sessions（Windows）或~/Library/Application Support/Code/User/sessions（macOS）里的 session 文件损坏，会导致启动时反复尝试恢复失败状态
缓存本身无害，有害的是它和错误配置、失控扩展、不匹配的硬件加速策略混在一起——清理只是起点，后续必须堵住这些“漏点”，否则一周后又回到原样。
