路科C盘又红了，任务栏图标一个接一个变黄，打开VS Code转圈半天，最后发现磁盘空间不足——这个场景我太熟了。有一次我新安装完环境，刚跑起前端项目就报“ENOSPC: no space left on device”，查了一圈，VS Code的插件缓存愣是吃掉了C盘十几个GB。其实VS Code本身不大，真正膨胀的是它悄悄堆在用户目录里的缓存和插件数据。这篇集中梳理一下VS Code缓存与插件目录迁移的完整思路，从路径定位到实操命令，一次讲清楚。
1. 先把“家底”摸清：VS Code在C盘到底放了些什么
很多人一上来就搜“VS Code缓存改路径”，其实连里面有哪些目录、各自干什么都没弄明白，改的时候自然容易出岔子。我先帮你把VS Code在Windows上的数据存放格局拆开。
1.1 两个目录，各管一摊
VS Code在Windows下主要有两块专属地盘：
- 插件目录：默认位于
C:\Users\<用户名>\.vscode\extensions。这个目录是纯插件本体，什么东西最占空间？答案通常是语言服务器、代码补全引擎、远程开发组件这类体量巨大的扩展。比如Python扩展自带分析器，C/C++扩展包含庞大的调试器和IntelliSense引擎，单个体积往往超过500MB，装七八个常用插件后几个GB轻松出去。 - 用户数据目录：默认位于
C:\Users\<用户名>\AppData\Roaming\Code。这里面装的不只是配置和全局状态，还包含大量缓存子目录：Cache、CachedData、CachedExtensionVSIXs、CacheStorage、GPUCache等。其中CachedExtensionVSIXs是安装扩展时下载的安装包残留，CacheStorage是各类面板的本地缓存，CachedData是代码编辑器渲染进程的缓存数据，日积月累体积相当可观。
可以理解为：.vscode目录是插件的“员工工位”，AppData\Roaming\Code是VS Code的“档案仓库+临时仓库”，这两处一动，C盘压力立刻缓解大半。
1.2 空间不是一夜没的，是慢慢“攒”出来的
我见过不少同事，C盘从剩30GB到只剩2GB，整个过程其实没有一次大型操作，就是正常使用VS Code写了两个月的代码：
- 天天打开各种工作区，VS Code为每个窗口生成缓存数据，
CacheStorage和CachedData持续累积，只增不减。 - 装插件时下载的VSIX安装包，正常情况下用完该删，但
CachedExtensionVSIXs目录里的残留经常因为升级中断、安装器异常退出而留存下来。 - 远程开发场景（Remote-SSH、WSL、Dev Containers）更是重灾区。每次连接远程环境，VS Code会在本地缓存服务器端代码、扩展、依赖，一套下来就是1-2GB，换几个远程环境就是成倍增长。
- 工作区索引、搜索索引、Git历史缓存等散落在
Code目录下的若干子文件夹，普通用户根本不会去删，也不敢删。
所以迁移的逻辑不是“今天C盘红了赶紧删一删”，而是把VS Code天生喜欢往系统盘堆的这两类数据，一次性改成用户目录或非系统盘位置，从源头解决。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. VS Code官方支持的路径指定：启动参数和命令行开关
VS Code在运行时允许通过命令行参数覆盖默认路径，这是官方推荐的方式，也是所有迁移方案的根基。理解这些参数比单纯换目录更重要，因为如果你不清楚VS Code内部怎么加载这些路径，后面改了配置不生效会一脸懵。
2.1 两个核心参数：--extensions-dir 和 --user-data-dir
--extensions-dir <path>：指定插件所在目录。VS Code启动时从这个路径扫描并加载扩展。--user-data-dir <path>：指定用户数据目录。VS Code把配置、缓存、全局状态都放进这个目录。
理论上，只要启动VS Code时带上这两个参数，就能把插件和缓存整体挪走。例如：
bash复制code --extensions-dir "D:\VSCodeData\extensions" --user-data-dir "D:\VSCodeData\userdata"
这样启动后，VS Code不会再往C盘的用户目录里写插件和数据。
但这里有个坑：如果你平时不是通过命令行启动，而是通过开始菜单快捷方式、任务栏固定、文件关联打开，这些位置不会自动带上参数。每次用快捷方式打开VS Code时，它就直接忽略了你的命令行参数，重新回到C盘默认路径，等于白忙活。所以单纯记命令不够，必须把参数固化到启动入口。
2.2 把参数写进快捷方式：最常见的正确做法
在VS Code桌面快捷方式上右键，选择属性，在“目标”一栏追加参数：
text复制"C:\Users\<用户名>\AppData\Local\Programs\Microsoft VS Code\Code.exe" --extensions-dir "D:\VSCodeData\extensions" --user-data-dir "D:\VSCodeData\userdata"
每次更新VS Code时，安装程序可能会重置快捷方式，导致参数丢失，需要重新检查。更麻烦的是，任务栏固定的快捷方式并不等同于桌面快捷方式，修改后还要单独处理任务栏图标的启动参数，比较容易遗漏。
如果只是临时验证参数是否生效，可以在命令行跑一次：
bash复制code --extensions-dir "D:\VSCodeData\extensions" --user-data-dir "D:\VSCodeData\userdata" --status
观察输出中的路径信息，能确认VS Code是否按新路径加载。
2.3 为什么“指定目录”不够，还要移动旧数据
记住：修改参数只是让VS Code未来读新位置，你不把旧位置的数据搬过去，新装目录就是空白的，等于插件全部丢失，配置全部重置。真正的迁移流程是：
- 关闭所有VS Code窗口。
- 把C盘旧目录里的文件完整复制或剪切到新位置。
- 再修改启动参数指向新位置。
- 启动验证。
顺序别搞反。我见过有人先改参数再移动数据，结果启动后发现VS Code生成了全新的空配置，然后又把已有配置覆盖掉，损失惨重。
3. 方案深度对比：启动参数 vs 目录联接（Junction）
改启动参数是最直观的思路，但在日常使用中你会发现它有两个明显缺陷：一是要改快捷方式，二是有外部工具调起VS Code时仍可能走默认路径。那有没有更“透明”的方式？有，就是Windows的目录联接（Junction）。
3.1 什么是Junction，它和快捷方式有什么区别
Junction是Windows NTFS文件系统提供的一种重解析点，可以简单理解为一个虚拟目录指针。创建后，所有对Junction路径的读写操作都会透明地转发到目标路径，对于应用程序来说，它完全感受不到自己访问的是一个“假目录”。
它与快捷方式的根本区别在于：
| 对比项 | 快捷方式 | 目录联接（Junction） |
|---|---|---|
| 应用透明性 | 不透明，应用需要自行解析.lnk | 完全透明，应用无感知 |
| 系统层级 | 文件级，需要Shell支持 | 文件系统级，内核直接处理 |
| 兼容性 | 部分命令行工具不识别 | 所有依赖文件路径的工具都能用 |
| 创建方式 | 右键新建 | mklink /J命令 |
由于VS Code（包括它的更新程序、子进程）访问的都是原路径，通过Junction可以把数据真实存储位置完全搬到其他盘，但VS Code眼里路径没有变过，不会产生任何路径冲突或重新下载数据的风险。
3.2 用mklink把目录“偷梁换柱”的完整步骤
Windows 10/11下，管理员权限打开命令提示符或PowerShell，按顺序执行：
powershell复制# 1. 关闭VS Code
# 2. 将原插件目录改名或移走备份
cd C:\Users\<用户名>
ren .vscode .vscode_bak
# 3. 创建目录联接，让原路径指向新磁盘位置
mklink /J C:\Users\<用户名>\.vscode D:\VSCodeData\extensions
# 4. 对用户数据目录重复同样操作
ren C:\Users\<用户名>\AppData\Roaming\Code Code_bak
mklink /J C:\Users\<用户名>\AppData\Roaming\Code D:\VSCodeData\userdata
执行顺序不能乱，先改名再建联接是为了避免目录冲突。等验证无误后，可以直接删掉_bak备份目录，把空间彻底释放出来。
如果你用Windows的“设置”里查看磁盘占用，会看到Junction指向的目录仍然显示在C盘路径下，但实际占用会被系统计算在目标盘上。这个特性不会造成数据错乱，只是磁盘占用统计时略有迷惑性，不用太担心。
3.3 两种方案选哪个：日常使用与维护成本
实际项目中，两种方案各有适用场景：
- 启动参数方案：适合只想把插件目录移位、不想动配置缓存的场景，也适合临时用不同插件集合干活（比如前后端分离调试），通过不同的启动参数按需切换。
- Junction方案：适合彻底搬家、一劳永逸的场景。不用管快捷方式、不用管外部工具调用、不用管VS Code自动更新是否重置参数。唯一要注意的是硬盘分区格式必须是NTFS（基本上默认都是）。
如果你把VS Code升级到Insiders版本，注意它的默认数据目录是AppData\Roaming\Code - Insiders，插件目录是.vscode-insiders，需要分别处理，不能和正式版共用路径，否则版本配置会互相污染。
4. 缓存目录专项清理：删什么、留什么、挪什么
前面说的是“整体搬”，实际使用中还有一种情况：C盘虽然红了，但暂时不想动路径结构，只想把缓存清理一遍先救急。这就要搞清楚缓存里哪些是纯垃圾，哪些不能乱碰。
4.1 按清理价值把缓存目录分个级
把VS Code用户数据目录下的缓存子目录按“清理收益”和“风险”排个序：
| 目录名 | 内容 | 能不能删 | 收益 |
|---|---|---|---|
Cache |
HTTP缓存，用于加速扩展下载、图标加载等 | 可以删，会自动重建 | 低，通常几十MB |
CachedData |
编辑器核心渲染缓存 | 可以删，会自动重建 | 中等，可能数百MB |
CachedExtensionVSIXs |
扩展安装包残留 | 可以删，影响极小 | 极高，很多机器几个GB |
CacheStorage |
多个视图面板的本地存储缓存 | 可以删，但部分面板状态会重置 | 较高 |
GPUCache |
GPU着色器缓存 | 可以删，会自动重建 | 低 |
logs |
日志文件 | 可以随便删 | 中 |
User\workspaceStorage |
每个工作区的临时状态存储 | 可以谨慎删 | 极高，很多机器几个GB |
特别提醒：workspaceStorage这目录，名字看着像“工作区配置”，很多人不敢删。实际上它存的是每个工作区的UI状态、面板布局、断点临时数据等，删掉后只会丢失工作区的界面布局记忆，不会动你的源代码和版本控制信息。很多人的C盘被VS Code吃掉的空间，大头就是它对几十个工作区各建了一套本地缓存，累计下来相当惊人。
4.2 清缓存最安全的三步法
如果只做急救清理，按下面这个顺序操作风险最低：
- 完全退出VS Code（确保托盘图标也退掉，任务管理器里没有
Code.exe进程）。 - 删除
CachedExtensionVSIXs、logs、GPUCache这三个目录下的所有内容。 - 重启VS Code，看是否正常运行。如果某些面板布局被重置，可以通过“查看-外观”重新调整，无伤大雅。
这样做完通常能释放几百MB到几个GB。
4.3 清理后VS Code为什么变“慢”了
清完缓存后会立刻遇到一个体验问题：启动变慢、图标闪烁、扩展重新下载。这是因为首次启动时，VS Code需要重建索引、重新请求HTTP缓存、重新编译渲染缓存。这个过程通常持续几分钟到十几分钟，视扩展数量而定。
所以我建议平时不要频繁清理CachedData和CacheStorage，而是优先清理CachedExtensionVSIXs和workspaceStorage。前者是纯残留，后者是低价值的状态数据，两者删了都几乎无感。
提示：如果清理后某些扩展加载异常，最稳妥的办法是到扩展面板里把对应扩展禁用再启用，强制它重建缓存。
5. 迁移后踩过的坑：八条实战经验直接给你
第一次做完整迁移的人，八成会碰到下面这些问题。我按自己实际踩坑的顺序列出来，省得你走弯路。
5.1 插件装了但没生效，问题出在“新旧路径并存”
迁移完成后，如果发现装新插件时VS Code仍然提示空间不足，很可能是旧插件目录没有被完全搬走，或者新目录没有成为唯一加载路径。检查方法是在VS Code里打开命令面板（Ctrl+Shift+P），输入“developer”找到“Developer: Show Running Extensions”，看扩展的安装路径是否指向新目录。
常见原因：迁移时没有把旧目录彻底删干净，C:\Users\<用户名>\.vscode下还残留着扩展安装的硬链接或影子目录。尤其在使用某些扩展管理工具（比如settings sync）时，它会扫描默认路径并重新创建目录。解决方式是确认旧路径下没有活动文件后，再完整重命名或删除旧目录。
5.2 远程开发（SSH/容器）插件缓存依然占C盘
Remote-SSH和Dev Containers这类扩展，在连接远程环境时还会在本地生成连接缓存，存放路径带有user-data-dir参数影响，但也有一部分存放在临时目录。你会发现迁移后C盘仍然增长，这属于扩展自身的缓存行为，不是VS Code主程序的问题。
最简单的处理方法是定期清理%TEMP%下的vscode相关目录，或者把系统的临时目录也一起挪到其他盘（系统设置-系统-关于-高级系统设置-环境变量，把TEMP和TMP指向D盘），这样远程开发产生的临时文件就不会再堆积到C盘。
5.3 更新VS Code后参数被重置
VS Code每月发布更新，很多更新包会顺手刷新快捷方式。如果你用的是启动参数方案，更新完务必重新检查一遍快捷方式。Junction方案则完全不需要担心这个问题，因为路径本身没变。
5.4 别用“软链接”替代“目录联接”
Windows下除了mklink /J（Junction）还有mklink /D（符号链接）。在普通场景下两者看起来相似，但/D符号链接在某些权限受限的应用场景下可能不被识别，而/J目录联接是更底层、兼容性更好的选择。尤其是有一些命令行工具、编译脚本会遍历目录时，/J几乎没有兼容性风险。
另外，创建mklink /J不需要管理员权限（普通用户即可），而/D在某些配置下需要提权，这也是我推荐Junction的原因之一。
5.5 用户数据目录迁移后，登录状态全部掉线
把AppData\Roaming\Code整体迁走后，VS Code里登录的GitHub、Microsoft账号会掉线，已保存的密码、令牌也会失效。这是因为这些凭证也存储在用户数据目录里。迁移后重新登录一次就行，但第一次启动时不要惊慌以为迁移坏了。
5.6 C盘空间没减多少？检查是不是还有“Code - Insiders”
同时安装稳定版和Insiders版的用户，迁移时只处理了稳定版。Insiders版的数据在另一个目录，同样需要单独迁移或清理。
5.7 迁移完启动报“Cannot write file”
某些老版本扩展会把用户数据路径硬编码写在全局配置里，迁移后配置路径失效导致报错。遇到这种情况，打开设置搜索files.exclude、search.exclude等含绝对路径的配置项，把旧的C盘路径改成新路径即可。
5.8 先备份再操作，永远别嫌麻烦
迁移前强烈建议用文件历史、Windows备份或直接把目录复制到移动硬盘做一份备份。尤其是在处理用户数据目录时，里面可能保存着你从未注意过的密钥、配置文件、断点数据。虽然理论上迁移是可逆的，但真出了问题，备份就是救命稻草。
6. 如果日常C盘空间持续吃紧，还得加这几个组合操作
迁移VS Code只是C盘瘦身的一环，如果C盘空间持续吃紧，还要做几个辅助调整，把“易胖体质”彻底改掉。
6.1 把Chrome/Edge浏览器缓存和用户数据也挪走
很多人的C盘空间，其实是浏览器和VS Code一起吃的。Chrome和Edge的用户数据默认都在C:\Users\<用户名>\AppData\Local\Google\Chrome\User Data或C:\Users\<用户名>\AppData\Local\Microsoft\Edge\User Data。这些目录动辄几个GB到几十个GB（尤其多年不清理插件的）。如果只是删缓存，没几天又涨回来，更好的做法是把整个用户数据目录用Junction迁移到其他盘。
操作方法类似：关闭浏览器，把原目录改名，用mklink /J把原路径指向D盘。浏览器内登录状态会保留（只要你把整个User Data目录完整搬走），缓存也自动写入新盘。
6.2 把WSL虚拟磁盘文件迁移
如果日常用WSL做开发，C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx这个文件可能占用数十甚至上百GB。这是Linux子系统的虚拟磁盘，不是简单的缓存，但体量远大于VS Code。迁移方法是用WSL导出/导入：
powershell复制wsl --shutdown
wsl --export Ubuntu D:\WSL\ubuntu.tar
wsl --unregister Ubuntu
wsl --import Ubuntu D:\WSL\Ubuntu D:\WSL\ubuntu.tar
这步操作量级较大，建议在VS Code迁移后、确认稳定再执行。
6.3 Java开发者的Gradle缓存、Maven缓存
如果日常写Java，C:\Users\<用户名>\.gradle（Gradle缓存）和C:\Users\<用户名>\.m2（Maven缓存）的体积也相当惊人。这些缓存也会跟随VS Code的Java扩展被频繁调用。方法同样是Junction搬迁或修改配置文件指定新位置。
6.4 系统临时文件目录（TEMP/TMP）
把系统TEMP和TMP环境变量指向D盘，能让大量程序运行时的中间文件不再占用C盘。改法是：系统属性-高级-环境变量-用户变量，把TEMP和TMP改为D:\Temp。改完重启一次系统让变量全局生效。
这几个操作配合VS Code迁移，C盘健康度能维持很久。但注意别一次性改太多环境变量，避免某个软件因找不到路径而出问题，建议每改一个重启确认一次。
6.5 定期查看磁盘占用，主动干预比被动清理有效
Windows 11的“设置-系统-存储-临时文件”里能看部分缓存，但VS Code的数据目录通常不在这个分类内。更好的方式是定期（比如每月一次）手动查看AppData和\.vscode目录的体积变化，超过2GB就及时处理。别等到“C盘空间不足”的弹窗出现才想起来排查。
7. 延伸思考：VS Code更新机制对数据目录的影响
一个容易被忽略的细节：VS Code的自动更新是以用户数据目录为相对基准定位安装目录的。当你使用--user-data-dir指定了非默认路径，更新程序可能出现“找不到Code.exe”的提示，或者更新后快捷方式参数被重置。这不是bug，而是更新脚本设计的路径假设。
应对方式有两种：
- 接受Junction方案，更新程序看到的数据路径和安装路径都保持在默认位置，更新体验与未迁移时完全一致。
- 坚持启动参数方案，就要接受每次大版本更新后需要手动检查一次启动参数。
我认识的一些团队同事，把VS Code的安装包本身也做了Junction迁移（把C:\Users\<用户名>\AppData\Local\Programs\Microsoft VS Code指向D盘），整个Visual Studio Code完全不在C盘落地。这需要提前把安装目录拷贝到目标盘，再建Junction，之后VS Code更新时仍然正常，因为更新程序本身也访问同一个Junction路径。不过这步操作涉及安装目录的完整性，比数据目录迁移更容易出问题，新手不要轻易尝试，先把数据目录迁走已经能解决绝大多数空间问题。
8. 最后的经验总结：动手前记住这五句话
- 先诊断再动手，分清是插件目录膨胀还是缓存膨胀，不然改了路径不治本。
- 移动用户数据目录的效果最彻底，但对日常使用的“无感程度”也最低——重新登录是常态，备份要先行。
- 普通用户优先用Junction方案，改启动参数只适合特定场景（比如多个版本并存）。
- 缓存清理和路径迁移是两件事，别混着做。先清理应急，再迁移根治。
- 网络上的“C盘清理工具”一律不推荐用于清理VS Code，直接针对目录操作比任何第三方工具都干净、可控。
VS Code占C盘的问题，本质是“默认路径设计+用户使用习惯+扩展生态膨胀”三者的耦合。只要把数据目录、插件目录迁移到非系统盘，然后养成定期查看目录体积的习惯，C盘就不会再三天两头告急。如果迁移过程中遇到什么意外情况，欢迎在评论里具体描述你的目录结构和报错信息，我帮你一起排查。