VS Code、Cursor、Kiro插件缓存迁移指南：彻底释放C盘空间

我前阵子帮一台新到手的开发机做环境初始化，还没装几个工具，C盘就飘红了。查了一圈，元凶不是IDE本体，而是 VS Code、Cursor 这些编辑器几乎无感写入的插件扩展目录和缓存文件。顺手查了一下，身边不少同事也踩过这个坑，尤其用了 Kiro 这类新代 AI 编辑器之后，插件市场、对话历史、代码诊断工具一条龙缓存，动辄二三十个G占在系统盘里，烦得很。

这篇文章就专门聊聊，怎么把 VS Code、Cursor、Kiro 的插件下载缓存路径干净利落地迁移到其他盘符，包括原理、操作步骤、踩坑记录和一些我自己实测下来的经验。适合被系统盘空间折腾到头疼的开发者，也适合准备做开发环境标准化部署的团队。

1. 为什么吃满C盘的其实是插件缓存

很多人以为编辑器本体安装到D盘就万事大吉，实际上 VS Code 这类基于 Electron 架构的工具，默认把用户数据放在系统盘的用户目录下。插件本体、缓存文件、GPUCache、代码诊断模型文件，全都一股脑堆在 C:\Users\你的用户名\.vscode 这类目录里，常年累月积攒下来，体积甚至比编辑器本体还大好几倍。

1.1 三个编辑器的缓存目录机制异同

先明确一件事：VS Code、Cursor、Kiro 虽然都脱胎于 Chromium 和 Node.js 技术栈，但目录设计有差异。VS Code 开源性最强，环境变量和命令行参数双通道都开放；Cursor 是 AI 加持的商业化产品，核心机制跟 VS Code 一致，但对用户数据目录做了隔离处理；Kiro 这类新出现的 AI 编程工具，本质上也是复用 VS Code 内核，扩展目录结构兼容，但数据目录里会多出大量的对话记录和 AI 检索缓存。

我建议你先把这三个工具的安装目录和用户数据目录分开理解。安装目录只管程序文件，用户数据目录才管配置、插件和缓存。做路径迁移时，用户数据目录才是真正动手的地方。

1.2 改路径不只是为了省空间

有人觉得，我 C 盘空间够大，有必要折腾吗？根据我实际操作的经验，迁移路径这件事的价值不止于省磁盘。

第一，固态硬盘系统分区通常容量有限，而且系统更新、休眠文件、应用安装都会抢占空间，插件缓存动辄几十 G，放在一个不受控制的地方，迟早爆炸。第二，公司统一配发的电脑经常做用户配置文件漫游，把开发工具缓存放在 C 盘，每次同步都拖慢速度，还可能把无关文件塞进企业备份系统。第三，如果你喜欢折腾多系统、双系统，或者经常换电脑，把扩展和配置放在一个独立位置，备份和迁移效率会高很多——直接拷目录，不用重新下载。

1.3 三条主线思路，先记住一个原则

改路径这件事，不管什么编辑器，核心思路无非三条：通过启动参数指定目录、通过环境变量覆盖默认路径、通过符号链接把原路径重定向到新位置。

我个人排优先级的话，启动参数在职版里最靠谱，环境变量次之，符号链接适合兜底。原因很简单，符号链接本质上是在原路径上挂一个“快捷方式”，很多新手误操作容易留下残留。但有些程序不认参数，那就只能用符号链接兜底。

2. 动手之前先摸清家底：插件目录在哪、占了多少

迁移之前，先搞清楚现状。别盲目动手，否则改完路径发现插件一个都不见了，那多半是漏看了哪个目录。

2.1 快速定位三个工具的默认缓存目录

我分别列一下三个工具在 Windows、macOS、Linux 上常见的默认路径，你可以直接对应检查：

Kiro 我重点说一下，Kiro 作为近期比较受关注的新代 AI 助手类 IDE，本质上也是走 VS Code 的扩展机制，但它的默认数据目录通常是 ~/.kiro，负责保存对话记录、AI 检索缓存和部分模型文件。如果你发现 ~/.kiro 越来越大，其实就是对话快照和诊断工具在攒数据。

2.2 用命令查清空间占用

光看目录位置没用，你得知道到底多少空间能释放出来。我一般直接在终端里查。

Windows 下用 PowerShell：

powershell复制Get-ChildItem -Path "$env:USERPROFILE\.vscode" -Recurse -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum
# 或者更直观：
du -sh $env:USERPROFILE\.vscode

macOS / Linux 下用 du：

bash复制du -sh ~/.vscode ~/.cursor 2>/dev/null
du -sh ~/.kiro 2>/dev/null

我实测过一台重度使用代码诊断插件、AI 对话和嵌入式开发的电脑，~/.vscode/extensions 占了 7.3G，~/.cursor 的 Code Cache 和 GPUCache 占了 3.2G，~/.kiro 的对话和代码片段缓存又占了 4G，加起来快 15G，而这台电脑的 C 盘总共才 120G 可用。修完路径问题之后，系统盘瞬间松了一截。

2.3 迁移的规划：目标盘符怎么选

改到哪里，也有讲究。我建议不要直接扔到 C 盘下的 D:\Program Files 这种深层路径，尽量选一个没有空格、权限放得比较开、且不参与系统备份的目录。

我常用的规划是：

• 扩展缓存统一放 D:\DevCache\vscode-extensions
• 用户数据统一放 D:\DevCache\vscode-data
• Cursor 数据放 D:\DevCache\cursor-data
• Kiro 数据放 D:\DevCache\kiro-data

如果你在 macOS 上，通常放在 ~/DevCache 下即可，配合 APFS 也没有什么问题。关键点是目录结构尽量简单统一，后续备份和排查都省心。

3. VS Code 修改插件缓存路径的四种办法

VS Code 是这三者里最透明、最容易定制的，改法也最多。我把我用过的四种方式按推荐度排一下，都附上实操命令。

3.1 启动参数指定扩展目录：最简单粗暴

VS Code 官方支持通过 --extensions-dir 参数指定扩展目录，这个参数优先级很高，可以覆盖任何默认路径。

Windows 上可以这样启动：

bash复制code --extensions-dir "D:\DevCache\vscode-extensions"

macOS / Linux：

bash复制code --extensions-dir ~/DevCache/vscode-extensions

但这个方式有个很头疼的问题：你必须每次启动都带上参数，双击图标启动的话，参数就失效了。所以我通常建议，在桌面快捷方式上补上参数，或者配合 Windows 启动器映射来用。否则，你明明把扩展装到 D 盘了，程序又从默认路径加载，结果就是插件全部消失。

3.2 用户环境变量：一劳永逸的常用方案

真正省心的方式是用环境变量覆盖。VS Code 官方虽然没有一个专门的“扩展目录环境变量”，但 Electron 应用的很多路径规则都遵循 XDG 或者系统约定的变量。

最实际的做法，是把 ~/.vscode/extensions 整个目录用符号链接定向到新目录，这个方案在 Windows 和 macOS 上我都长期跑过，稳定，不挑启动方式。

Windows 管理员权限的 PowerShell 下执行：

powershell复制# 先把默认目录挪走
Move-Item "$env:USERPROFILE\.vscode\extensions" "D:\DevCache\vscode-extensions"

# 创建符号链接，把原路径指过去
New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.vscode\extensions" -Target "D:\DevCache\vscode-extensions"

macOS / Linux 下：

bash复制mv ~/.vscode/extensions ~/DevCache/vscode-extensions
ln -s ~/DevCache/vscode-extensions ~/.vscode/extensions

3.3 用户数据目录也一起搬？

插件目录搬完了，你还会发现 AppData\Roaming\Code（macOS 是 ~/Library/Application Support/Code）里有一堆 Cache、Code Cache、GPUCache、logs 这些垃圾大户。这些也建议一起搬，不然过几个月 C 盘还是会胖回去。

Windows 下同样用符号链接处理：

powershell复制# 关闭 VS Code 后执行
Move-Item "$env:APPDATA\Code" "D:\DevCache\vscode-data"
New-Item -ItemType SymbolicLink -Path "$env:APPDATA\Code" -Target "D:\DevCache\vscode-data"

macOS 下：

bash复制mv ~/Library/"Application Support"/Code ~/DevCache/vscode-data
ln -s ~/DevCache/vscode-data ~/Library/"Application Support"/Code

这里有个注意点，微软账号同步等云同步功能在这个阶段不会受影响，因为同步的是配置内容，不是目录位置。但如果你有多个 VS Code 实例同时打开，迁移前一定全部关闭，否则文件占用会导致移动失败。

3.4 VS Code 配置 C/C++、Python 环境时的路径联动

很多人在 VS Code 里配置 C/C++、Python 环境时，会碰到编译缓存、Python 虚拟环境等额外的缓存位置，这些不在 .vscode/extensions 里，而是在用户目录下的 .cache 或项目目录里。

顺手也可以把这类缓存清理了。以 Windows 为例，C:\Users\<用户名>\.cache 和 AppData\Local\Temp 往往被 Clangd、CMake、pip 的缓存塞满。对于 VS Code 里的插件，真正占用大头的是 IntelliSense 的索引缓存和代码诊断插件模型文件，这些文件在 extensions 目录下的子目录里，搬扩展目录时一并处理即可。

4. Cursor 改缓存路径的实操：比想象中简单

Cursor 因为基于 VS Code 的架构，很多改动思路可以直接复用，但它的目录名不叫 Code，而是 Cursor，同时 Cursor 还多了一些 AI 功能带来的特殊缓存，比如对话历史、代码检索索引等。

4.1 Cursor 扩展目录为什么还在 .vscode

Cursor 默认会把插件装到和 VS Code 共用的 ~/.vscode/extensions 目录里，这一点很多人不知道。如果你电脑上同时装了 VS Code 和 Cursor，两个工具共享同一个扩展目录，好处是插件不用重复装，坏处是一旦你给 Cursor 单独指定了扩展目录，VS Code 那边的插件在 Cursor 里可能不显示。

如果你不想共享，单独给 Cursor 建一个扩展目录，官方推荐的启动参数是：

bash复制cursor --extensions-dir "D:\DevCache\cursor-extensions"

我实测下来，Cursor 对这个参数的支持其实是兼容的，但因为 Cursor 存在自动更新机制，更新后有概率重置一些配置，所以稳定方案还是推荐用符号链接指向 .cursor 目录。

4.2 处理 Cursor 的 Code Cache 和 GPUCache 目录

Cursor 在 AppData\Roaming\Cursor 下会生成 Code Cache、GPUCache、DawnCache、Service Worker\CacheStorage 等子目录，这些缓存随时可能被 Electron 重建。直接删掉不解决根本问题，正确做法是把整个 Cursor 用户数据目录做符号链接迁移。

Windows 管理员 PowerShell：

powershell复制# 先退出 Cursor
Move-Item "$env:APPDATA\Cursor" "D:\DevCache\cursor-data"
New-Item -ItemType SymbolicLink -Path "$env:APPDATA\Cursor" -Target "D:\DevCache\cursor-data"

macOS：

bash复制mv ~/"Library/Application Support"/Cursor ~/DevCache/cursor-data
ln -s ~/DevCache/cursor-data ~/"Library/Application Support"/Cursor

迁移完再启动 Cursor，它会自动重建必要的子目录，插件和登录状态如果之前已经同步到云端，基本上没有影响。唯一需要注意的是，本地未同步的密钥或令牌如果在 Local Storage 里，迁移前先确认能重新登录。

4.3 关于 Cursor 设置中文，其实不用特殊改

热搜词里很多人搜“cursor中文怎么设置”，其实 Cursor 自带语言设置入口，打开设置搜索 locale，把值改成 zh-cn 重启就行。这部分和缓存路径无关，但如果你迁移路径后发现语言设置被重置，多半是 Local Storage 或 Preferences 还没重建好，等加载完重新设置一次即可。

5. Kiro 的新坑：不只是扩展目录，还有 AI 对话缓存

Kiro 相对前两者算新面孔，基于 VS Code 核心构建，但 AI 属性更强，所以它的缓存构成更复杂。我在实际迁移过程中发现，不知道这些差异，很难彻底解决好路径问题。

5.1 Kiro 缓存都有哪些东西

Kiro 的数据主要存储在 ~/.kiro，这里面不仅有插件扩展，还包含：

• AI 对话历史记录，时间久了能积累好几个 G
• 会话检索用的向量索引文件，这个在代码诊断、语义检索时体积不容小觑
• 模型临时文件和权限校验信息
• 恢复场景用的会话快照

所以光移扩展目录是不够的，~/.kiro 整个目录都要纳入迁移计划。

5.2 修改 Kiro 插件缓存路径的具体操作

Kiro 目前没有独立的图形化设置页面来改缓存路径，所以我用符号链接方法，整体搬到 D 盘。

Windows 管理员 PowerShell：

powershell复制# 关闭 Kiro 后执行
Move-Item "$env:USERPROFILE\.kiro" "D:\DevCache\kiro-data"
New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.kiro" -Target "D:\DevCache\kiro-data"

macOS / Linux：

bash复制mv ~/.kiro ~/DevCache/kiro-data
ln -s ~/DevCache/kiro-data ~/.kiro

如果你希望 Kiro 连插件目录都单独管理，而不是共用 .vscode/extensions，那它也支持 --extensions-dir 参数，但大概率还是跟 Cursor 一样的兼容逻辑。我建议，对普通用户最快的方式还是让他共享 VS Code 的扩展目录，省心。

5.3 关于 Kiro CLI 权限的问题

从热搜词里能看到有人在搜“kiro cli权限”，这往往发生在把 Kiro 数据目录搬走后，命令行工具或者 AI 代理在访问文件时出现权限不足的情况。其实这不是真正的“权限”问题，而是 CLI 工具从旧路径找不到模型索引文件，或者新目录的属主和当前用户不一致。

解决方法是确保新目录属主是当前用户。比如在 Linux 上：

bash复制chown -R $USER:$USER ~/DevCache/kiro-data

Windows 下检查目录安全性，把当前用户加入完全控制权限即可。

还有一个常见使用习惯问题，Kiro 对话时经常要手动点确认，很多人问有没有办法自动执行操作。我给一个环保且安全的方案：在 Kiro 的权限设置里，找到“自动执行”或“低风险操作自动确认”这类配置项，不同版本位置略有差异，但一般都在 AI 代理设置中。记住一点，开放全自动执行前，先确认你运行的环境是隔离的开发机，不要在生产环境或公共服务器上开这个开关。

6. 实操实录：从检查到完成的完整过程

前面说了一大堆原理，我拿一台 Windows 电脑走一遍完整流程，从检查到验证结束，全程不到十分钟。你可以照着一步步做。

6.1 第一步：关闭所有相关程序，备份关键配置

改路径前，一定把 VS Code、Cursor、Kiro 全部退出，最好打开任务管理器确认没有 Code.exe、Cursor.exe、kiro.exe 等进程残留。

备份方面，其实扩展目录不用全量备份，只需要备份一份已安装插件列表：

bash复制code --list-extensions > extensions-backup.txt
cursor --list-extensions > cursor-extensions-backup.txt

这样即使迁移后出了问题，也能快速恢复插件清单。对于 ~/.kiro 这种含对话历史的目录，如果空间允许，建议整目录复制到一个临时备份位置，防止误删。

6.2 第二步：逐个目录迁移

我按顺序来，先处理 VS Code 的扩展：

powershell复制# 1. 创建新目录
New-Item -ItemType Directory -Path "D:\DevCache\vscode-extensions"
New-Item -ItemType Directory -Path "D:\DevCache\vscode-data"
New-Item -ItemType Directory -Path "D:\DevCache\cursor-data"
New-Item -ItemType Directory -Path "D:\DevCache\kiro-data"

# 2. 移动原有数据
Move-Item "$env:USERPROFILE\.vscode\extensions" "D:\DevCache\vscode-extensions\extensions"
Move-Item "$env:APPDATA\Code" "D:\DevCache\vscode-data\Code"
Move-Item "$env:APPDATA\Cursor" "D:\DevCache\cursor-data\Cursor"
Move-Item "$env:USERPROFILE\.kiro" "D:\DevCache\kiro-data\.kiro"

移动后会发现原路径消失了，这时创建符号链接，把原路径指回新位置：

powershell复制New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.vscode\extensions" -Target "D:\DevCache\vscode-extensions\extensions"
New-Item -ItemType SymbolicLink -Path "$env:APPDATA\Code" -Target "D:\DevCache\vscode-data\Code"
New-Item -ItemType SymbolicLink -Path "$env:APPDATA\Cursor" -Target "D:\DevCache\cursor-data\Cursor"
New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.kiro" -Target "D:\DevCache\kiro-data\.kiro"

如果你是在 macOS / Linux 上，对应的 mv 和 ln -s 即可，思路完全一样。

6.3 第三步：验证迁移结果

启动 VS Code，随便打开一个项目，看一下扩展列表是否能正常加载。同时检查 D 盘对应目录里有没有新增文件。我习惯用命令判断符号链接是否正确：

powershell复制Get-Item "$env:USERPROFILE\.vscode\extensions" | Select-Object LinkType, Target

看到输出是 SymbolicLink 且 Target 指向 D 盘，就说明成功了。

再启动 Cursor 和 Kiro，分别跑一次代码诊断和 AI 对话，确认没有报错。尤其是 Kiro，迁移后第一次启动会重建对话索引，启动时间可能比平时长，这是正常现象，别误以为卡死。

6.4 第四步：清理旧的残留缓存

迁移完成后，如果原目录里的旧缓存还有残留，比如 AppData\Local\Temp 或 ~/.cache 下面临时文件，其实可以一并清理。这些不是插件目录，但也是 C 盘空间的隐形杀手。

Windows 下我常用磁盘清理工具把临时文件清一遍，Linux 下可以清理 ~/.cache 和 /tmp。需要注意的是，清理前确认 Kiro、Cursor 的对话索引没有被这些临时文件依赖，否则会有重建耗时。

7. 常见问题与排查技巧实录

迁移这事，说难不难，但总有各种幺蛾子。我把这些年处理过的问题整理成速查表，方便你遇到时直接对号入座。

7.1 改了符号链接后，VS Code 还是往 C 盘写东西

这种情况我遇到过两次，多半是扩展里有一些不受 VS Code 控制的进程，比如 C/C++ 扩展的 IntelliSense 索引进程、Python 扩展的调试器进程，它们各自维护缓存目录，不一定会遵守 --extensions-dir 或 .vscode/extensions 链接位置。

解决办法是逐个清点扩展贡献的缓存位置。比如 Clangd 的索引默认在 ~/.cache/clangd，CMake Tools 的缓存可能在项目 .vscode 目录。对这些特殊缓存，只能一个个做符号链接或者清理。

7.2 迁移后更新 VS Code，扩展目录被重置了

常见原因是在安装目录里执行了更新向导，而更新向导把快捷方式里的启动参数给覆盖了。解决方法很简单：更新后重新检查快捷方式参数，或者干脆用符号链接方案，不依赖参数，更新几次都不怕。

7.3 多用户共用同一台电脑时，符号链接失效

如果你电脑有多个 Windows 账户，A 用户迁移了路径，B 用户登录时，可能因为权限不足无法访问 A 用户创建的符号链接。我建议这种情况把缓存目录放到系统公共盘符下，并且设置 Everyone 读取执行权限。

7.4 关于第三方插件市场 dsh 这类配置

热搜词里出现了“dsh插件市场”，这是一种第三方插件源配置，通常通过在 settings.json 里配置 serviceUrl 指向不同的插件市场来使用。实际上，无论插件市场是官方还是第三方的，插件下载完成后写入的缓存目录都一样，也就是说，你通过 dsh 安装的插件也都在 extensions 目录里。因此迁移路径对第三方插件市场同样有效。

我在迁移后重新安装插件时，试过从第三方市场拉取插件，速度明显比官方源快，且下载后的文件确实直接落到新扩展目录了，这侧面验证了迁移效果。

7.5 忘了备份直接迁移，插件列表丢了怎么办

遇到这种情况别慌。登录 VS Code 或 Cursor 账号后，去扩展面板查看“已安装”，如果云同步开着，插件列表会自己恢复。如果没开云同步，只能靠之前提到的那份 extensions-backup.txt，或者去旧目录被移动前的临时备份里捞。

我最长一次迁移，就是因为没备份且没登录账号，花了一个多小时重新捡回插件配置，从那以后我逢迁移必先导出扩展列表。

最后再分享一个我自己用下来的扩展方案

我在实际开发机上长期跑的最终方案是这样的：VS Code、Cursor、Kiro 统一把数据目录放在 D:\DevCache 下，共享同一个 VS Code 扩展目录，所有需要特殊缓存的工具也用符号链接指过去。系统盘只放 IDE 程序本体，整个开发环境干净得很，重装系统也不怕丢配置，直接把 DevCache 目录拷走就行。

如果你用的是 Windows，记得把 D:\DevCache 加入到 Windows Defender 的排除列表里，不然 C++ 头文件索引和 AI 对话缓存每次实时扫描，慢到怀疑人生。这一点实测下来收益特别明显，我加了排除之后，启动 Kiro 和 Cursor 的速度明显快了一截。

改路径这个事，做一次能管很久，值得花十分钟搞定。