代码补全变慢/不准需清理CachedData和WorkspaceStorage，而非Cache；CachedData存语言服务AST缓存，WorkspaceStorage存符号索引，二者共同影响补全响应与跳转准确性。
VSCode 的代码补全缓存不单独存在，它混在 CachedData 和 WorkspaceStorage 里，直接删这两个目录才有效——但不能乱删，否则补全变慢、跳转失效、符号索引要重刷几十秒。
为什么“代码补全变慢/不准”不是清 Cache 能解决的
很多人误以为清 Cache（Chromium 渲染缓存）能修复补全问题，其实它只管 UI 快照和 Marketplace 页面加载。真正影响 Python/TypeScript/Java 补全响应速度和准确性的，是语言服务器生成的中间产物，它们被写进：
-
CachedData：存放预编译 JS 模块、TS 类型检查器快照、Python 语言服务的 AST 缓存 -
WorkspaceStorage：每个子目录对应一个工作区，存符号索引、引用图、语义高亮数据
这两个目录长期不清理，会导致补全卡顿、Go to Definition 失败、Find All References 返回空结果。
删 CachedData 前先确认是否真要动它
这个目录体积增长快，尤其开过大型 monorepo 或含大量 node_modules 的项目后。但它不是“临时文件”，删完重启 VSCode 会触发全量重建，首次打开项目时补全可能延迟 5–20 秒（取决于项目大小）。
- Windows 路径：
%LOCALAPPDATA%\Programs\Microsoft VS Code\CachedData - macOS 路径：
~/Library/Application Support/Code/CachedData - Linux 路径：
~/.config/Code/CachedData - 删之前必须杀光所有
Code.exe/Code Helper/node.exe进程，否则文件被锁，删不掉也释放不了空间
WorkspaceStorage 里哪个子目录影响补全？按修改时间精准删
这个目录下每个 GUID 命名的子文件夹，都对应你曾经打开过的某个工作区。补全不准常源于旧索引残留（比如切换 Git 分支后结构大变，但索引没更新）。
- 进目录后按「修改日期」排序，重点删那些修改时间早于 90 天、且你确定已废弃的项目（如 WSL 工作区、测试分支、已迁移的仓库）
- 别全删：删错一个正在用的项目对应目录，下次打开时补全、跳转、搜索都会卡顿几秒到几十秒（等重建索引）
- Windows 下可快速定位大户：
cd "$env:APPDATA\Code\WorkspaceStorage"; Get-ChildItem -Directory | ForEach-Object { $size = (Get-ChildItem $_.FullName -Recurse -File | Measure-Object -Property Length -Sum).Sum; [PSCustomObject]@{Folder=$_.Name; SizeMB=[math]::Round($size/1MB, 2)} } | Sort-Object SizeMB -Descending | Select-Object -First 3
插件自带的补全缓存（比如 Pylance、TypeScript Server）怎么清
这些插件通常不在全局缓存路径里建缓存，而是藏在自己扩展目录下。例如：
- Pylance 会在
~/.vscode/extensions/ms-python.vscode-pylance-*/cache/存类型推导结果 - TypeScript Server 可能写入
~/.vscode/extensions/ms-vscode.vscode-typescript-next-*/node_modules/typescript/lib/tsserver.js旁的tmp或cache子目录 - 遇到补全突然失效、提示“Loading…” 卡住，先进对应扩展目录，手动删
cache/或__pycache__/，不要删整个扩展文件夹 - 删完重启 VSCode，插件会自动重建，比禁用再启用更彻底
补全问题最常被忽略的一点：它从来不是单点缓存，而是 CachedData + WorkspaceStorage + 插件私有缓存三者联动的结果。只清一个，往往治标不治本；全清又太重。精准识别当前瓶颈在哪，比盲目删更省时间。
