企业官网建设流程全解析

1. 插件目录默认全堆C盘：问题到底出在哪

很多朋友遇到的情况跟我当时一模一样：电脑用了大半年，C盘突然爆红，系统各种卡顿，打开个资源管理器都转圈。查了半天，占用空间的元凶不是下载的视频，也不是微信缓存，而是天天陪你写代码的几个编辑器——vscode、cursor、kiro。它们的插件默认安装路径全在系统盘的用户目录里，装得越多，C盘被吃得越快。

先说清楚“插件下载缓存路径”具体指什么。对 vscode 来说，Windows 上扩展插件装在C:\Users\你的用户名\.vscode\extensions；Cursor 装在C:\Users\你的用户名\.cursor\extensions；Kiro 这类新兴 AI 编辑器，只要是走 VS Code 扩展生态或者基于 Electron 架构，逻辑基本一致，常见是在用户目录下建一个.kiro\extensions之类的文件夹，具体名称以你机器上实际存在的为准。这是三个编辑器最占空间的“插件本体目录”。

但很多人忽略了一点：插件本身之外，每个编辑器还同时在系统盘里堆了一大堆缓存。vscode 的用户数据目录是C:\Users\你的用户名\AppData\Roaming\Code，Cursor 是C:\Users\你的用户名\AppData\Roaming\Cursor，里面装着 CachedData、Code Cache、GPUCache、logs、workspaceStorage 这些东西。它们跟插件目录叠加在一起，特别容易把一个 128G 的 C 盘吃到只剩几个 G。

1.1 三个编辑器各自把插件装到了哪里

Windows 系统下，默认路径大概是下面这个表格的样子：

Linux 和 macOS 上路径结构不同，但思路一样：Linux 的 vscode 扩展通常在~/.vscode/extensions，用户数据在~/.config/Code；macOS 在~/.vscode/extensions，用户数据在~/Library/Application Support/Code。Cursor 也是类似分层。

1.2 为什么插件的“大头”根本不是插件本身

很多代码诊断插件、AI 补全插件、主题包，看起来只是“安装一下”，实际上每个插件目录里会塞语言服务器二进制、source map、dist 编译产物、内置运行时依赖，装多了每个轻松几百 MB。但真正的隐形大户是用户数据目录里的缓存。

举个例子，我自己的 vscode 用了大概半年，装了四十多个扩展，.vscode\extensions目录占 1.8GB，但AppData\Roaming\Code下面各种 Cache 和 workspaceStorage 加起来有 2.4GB。Cursor 更夸张，AI 编辑器对会话、历史、索引数据的缓存需求更高，用户数据目录能到 3GB 以上。如果你只盯着“插件目录”搬，搬到后面发现 C 盘还是没怎么变绿，就是因为缓存目录压根没动。

1.3 影响范围：只有C盘告急这么简单吗

C 盘满了不只是“不能装新软件”这么简单。Windows 系统运行时本身要写临时文件，浏览器、输入法、系统更新也要依赖 C 盘空间。当可用空间低于 5GB 时，很多程序会开始出现莫名其妙的报错，比如 vscode 打开大项目时崩溃、AI 编辑器索引卡死、快捷键失灵。我做了一次迁移后，C 盘从剩 1.2GB 变成剩 9GB，最直观的感受是整个机器都“松”了一口气。

所以这件事值得认真处理，不是随便清理一下缓存那么简单。下面我会按“为什么这样做”和“具体怎么操作”两个角度，把 vscode、cursor、kiro 三个编辑器的插件下载缓存路径搬迁讲透。

2. 动手前必读：搞清楚“改路径”和“迁移”的区别

我第一次折腾的时候也犯过迷糊：以为改一下配置文件就能让新插件装到 D 盘。结果发现 VS Code 这套设计里，扩展安装目录是“启动参数级”的选项，不是settings.json里的普通配置项。也就是说，你没法在设置界面里改一个字段让它生效。想要改变插件落盘位置，业内常见做法只有两种：改启动参数，或者做目录迁移加符号链接。

这两种方案的差别很大，选错了后面会反复踩坑。

2.1 方案A：给目录搬家，符号链接接管

核心思路：把整个 extensions 目录从 C 盘复制到 D 盘，然后在原来的位置建立一个“目录联接”（junction）指向 D 盘。目录联接可以理解成给系统装了一个“转发层”：当 vscode 往原路径读或写时，系统自动把请求转发到 D 盘的真实目录。

对用户来说，路径看起来还是C:\Users\<你>\.vscode\extensions，C 盘上却不会真存数据。这个方案的好处是：

• 对软件完全无感，随便你用桌面图标、命令行、还是文件关联启动，都自动走 D 盘；
• 不依赖每次启动都要带参数；
• 一旦建立，后续安装、更新插件都自动落到新目录。

Windows 下创建目录联接的命令是mklink /J，它跟符号链接/D的区别是：目录联接不需要管理员权限，跨盘符也能用，而且兼容性更好，是折腾编辑器目录时最稳的选择。

2.2 方案B：改配置让新插件写入新位置

VS Code、Cursor 这系列基于 Electron 的编辑器，官方支持的改变扩展目录方式其实是启动参数：

code --extensions-dir "D:\CodeData\VsCodeExtensions"

如果你想用 Windows 桌面图标启动，那就改快捷方式的“目标”，在后面追加参数：

"C:\Users\你的用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe" --extensions-dir "D:\CodeData\VsCodeExtensions"

这个方法的问题是：你必须保证每次启动都带着这个参数。一旦哪次忘了，或者从别的入口启动（比如右键菜单里的“用 Code 打开”），编辑器又会重新在 C 盘默认位置创建一个新的 extensions 目录，然后你会看到两台“分裂”的插件环境——D 盘有一套，C 盘又长出一套，非常烦人。

2.3 我为什么推荐两者结合

我个人的建议是：以方案A为主，方案B作为补充。

先说主方案。迁移加目录联接一劳永逸，路径对软件透明，不会因为启动方式不同而分叉。你也不需要改任何快捷方式，C 盘原路径依然有效，但数据实际都在 D 盘。很多人担心的“会不会不稳定”其实不会发生，Windows 的目录联接技术很成熟，我用了一年多，没出过问题。

方案B适合什么场景？你临时测试一个新路径，或者想对比不同扩展目录环境下插件的兼容性，那可以用启动参数快速切换，不用反复做搬迁。但如果你是想彻底解决 C 盘空间问题，方案B单独用很容易因为“忘了带参数”而前功尽弃。所以实际执行时，我会先用方案A把旧目录搬走并建立联接，后面如果还想调整目标路径，再用启动参数覆盖，这样最灵活。

3. 实操：把vscode的插件目录挪到D盘

下面进入正题，完整走一遍 vscode 插件目录迁移过程。Cursor 和 Kiro 的步骤几乎一样，区别只是路径不同，我会在下一节单独指出各自要注意的细节。

3.1 新路径准备与旧数据拷贝

第一步，先把 vscode 完全退出。注意不是关掉窗口就完事，要确认后台没有 Code.exe 进程在跑。很多人复制文件时提示“文件被占用”，就是因为后台进程还挂着扩展的某些文件句柄。可以打开任务管理器，在“详细信息”里搜索 Code.exe，有残留就结束任务。

然后规划 D 盘的目录结构，我习惯把这类数据集中放，建一个根目录D:\CodeData，下面再分子目录：

• D:\CodeData\VsCodeExtensions：装 vscode 扩展
• D:\CodeData\CursorExtensions：装 cursor 扩展
• D:\CodeData\KiroExtensions：装 kiro 扩展

接着复制旧扩展目录。推荐用命令行，因为扩展数量多的时候，资源管理器复制容易漏掉隐藏文件，速度也慢。在命令提示符里执行：

xcopy "C:\Users\你的用户名\.vscode\extensions" "D:\CodeData\VsCodeExtensions\" /E /I /H /Y

参数含义：

• /E：复制所有子目录，包括空目录；
• /I：如果目标路径不存在，假设它是一个目录；
• /H：复制隐藏文件和系统文件；
• /Y：遇到已存在同名文件时直接覆盖。

扩展目录里有大量小文件，xcopy 可能要跑几分钟甚至更久，这取决于你装了多少扩展。复制完成后，先别急着删原目录，检查一下目标目录里是不是能看到所有扩展文件夹，文件数量是否和源目录一致。

3.2 用目录联接“欺骗”vscode

这个步骤是整个迁移的核心。先把原来的extensions目录改名，相当于做一个备份，然后再建立目录联接。

打开命令提示符，依次执行：

ren "C:\Users\你的用户名\.vscode\extensions" "extensions_old" cmd /c mklink /J "C:\Users\你的用户名\.vscode\extensions" "D:\CodeData\VsCodeExtensions"

第一条命令把旧目录改名为extensions_old，这样原来的路径就“空出来”了。第二条命令创建了一个目录联接：vscode 访问C:\Users\你的用户名\.vscode\extensions时，系统会把请求转到D:\CodeData\VsCodeExtensions。

这里有几个容易出错的小地方：

• 如果旧目录没有改名，直接执行 mklink 会提示“已存在文件”无法创建；
• 不要用/D创建符号链接，虽然也能用，但有些场景需要额外开启开发人员模式，而/J目录联接不需要管理员权限，更省事；
• 路径里不要写错用户名，最好复制实际路径。

执行成功后，可以用dir命令验证：

dir C:\Users\你的用户名\.vscode

你会看到extensions这行带有类似<JUNCTION>的标记，说明联接已经生效。

3.3 验证方法：装了新插件后如何确认写入位置

建立联接后，启动 vscode，扩展面板里应该能看到所有原有插件，一个都不少。如果出现某些扩展报错、感叹号，别急着删，先检查是不是在复制过程中漏了什么隐藏文件。

更可靠的验证方法是：随便安装一个新插件，安装完成后去 D 盘目标目录看一眼，新的扩展文件夹应该出现在D:\CodeData\VsCodeExtensions里，同时C:\Users\你的用户名\.vscode\extensions下也能看到同样的文件夹——这就是目录联接转发的结果。

如果你还是不太放心，可以在 vscode 里打开一个项目，新建一个临时文件输入几行代码，看诊断插件是否正常工作。只要原有的中文插件、代码格式化工具、AI 补全都正常，迁移就算成功。

最后确认一切正常后，再把extensions_old目录删掉。我个人习惯先保留一周，确认没有扩展异常才删。删除时如果提示文件被占用，多半是又启动过 vscode，先退出再删。

4. cursor和kiro的迁移：不是套娃，但套路相通

Cursor 和 Kiro 这两款 AI 编辑器，底层思路跟 vscode 很接近。Cursor 本身就是从 VS Code 分支出来的；Kiro 这类新工具只要支持 VS Code 扩展，目录结构基本也是同一套玩法。所以你不需要懂什么高深技术，照着 vscode 的流程再走一遍就行。

4.1 cursor如何迁移：改启动参数

Cursor 的插件目录默认在C:\Users\你的用户名\.cursor\extensions。但注意，Cursor 的坑在于它除了插件目录，还有大量的 AI 会话历史、模型缓存、索引数据，这些东西在用户数据目录里，也就是C:\Users\你的用户名\AppData\Roaming\Cursor。很多朋友搬完插件目录发现 C 盘没瘦多少，就是因为没动这个用户数据目录。

如果只想先把插件搬走，可以完全复用第3章的操作，把所有.vscode字样换成.cursor即可：

xcopy "C:\Users\你的用户名\.cursor\extensions" "D:\CodeData\CursorExtensions\" /E /I /H /Y ren "C:\Users\你的用户名\.cursor\extensions" "extensions_old" cmd /c mklink /J "C:\Users\你的用户名\.cursor\extensions" "D:\CodeData\CursorExtensions"

如果你不想用目录联接，非要走启动参数方案，快捷方式目标可以写成：

"C:\Users\你的用户名\AppData\Local\Programs\cursor\Cursor.exe" --extensions-dir "D:\CodeData\CursorExtensions"

不同版本的 Cursor 安装路径可能不一样，有的在AppData\Local\Programs\cursor，有的在别的目录，以实际安装位置为准。但我还是这句话：日常使用别迷信启动参数，直接用目录联接最稳，不然你每次从命令行启动忘了参数，C 盘又会偷偷长出新目录。

4.2 kiro如何迁移：目录方式处理

Kiro 是较新的 AI 编辑器，插件加载机制大概率兼容 VS Code 生态。但它的安装目录名、用户数据目录名不一定就叫.kiro，不同版本可能差异很大。最稳妥的排查方法是：打开 Kiro 的扩展面板，看某个已安装扩展的详情，里面通常会标注“安装位置”；或者在用户目录下搜索名为extensions的文件夹，配合修改时间判断哪个是 Kiro 的。

找到插件目录后，流程完全一样：复制到 D 盘、改名原目录、建立目录联接。如果 Kiro 自身提供了“扩展目录”或“存储路径”设置项，优先在设置界面里改，那个是官方支持的入口，比手动迁移更干净。如果它没有暴露这个选项，就用目录联接兜底，效果一样。

4.3 三个编辑器用同一个插件目录？劝你冷静

有人可能会想：反正都是 VS Code 生态，能不能让 vscode、cursor、kiro 三个编辑器共用同一个 extensions 目录，这样只占一份空间？

我之前也动过这个念头，实际试过之后强烈不建议。原因有三个：

• 扩展版本兼容性不同。每个编辑器内置的 Electron 和 Node 版本不一样，某些扩展更新时会针对特定编辑器做适配，共用目录容易相互踩版本。
• 卸载逻辑会误伤。你在 vscode 里卸载一个扩展，编辑器可能直接删除那个扩展目录，结果 Cursor 和 Kiro 依赖的文件也被删了。
• 各自维护的.obsolete文件、缓存状态不同，混用久了会出现“这个扩展明明装了但显示未安装”的诡异问题。

所以三个编辑器各用各的目录，别图省事合并。D 盘空间又不值钱，折腾共享路径省下来那点空间，远不够填后面踩坑的时间成本。

5. 迁移后容易踩的三个坑与排查方法

把目录搬过去之后，大部分人会遇到下面这几个问题。我把排查思路写出来，你照着走能省不少事。

5.1 插件更新失败 / 安装报错

表现：新建联接后，原有插件都能用，但去扩展商店更新某个插件时，提示“安装失败”或者一直停留在下载中。

这种情况大概率跟权限或者旧版本残留有关。扩展更新时，编辑器会生成一个.obsolete文件，用来标记哪些旧版本目录该被删除。如果目录联接正常但旧文件没清干净，更新就会卡住。

处理思路：

step 1: 先关闭编辑器，检查 D 盘对应扩展目录下有没有 .obsolete 文件； step 2: 如果有，先复制一份备份，然后删掉这个文件； step 3: 重新启动编辑器，再次尝试更新。

另外需要留意目标盘有没有被安全软件拦截写入。有些安全策略会监控“不常见路径下的高频率小文件写入”，扩展更新恰好就是这种模式。可以把 D 盘的扩展目录加入白名单，或者暂时关闭实时防护再试一次。正常装好后重新开启防护即可。

5.2 扩展商店打不开

表现：扩展商店列表空白，或者搜索插件时一直转圈，但本地插件使用正常。

这往往不是路径问题，而是网络因素。扩展商店依赖 CDN，不同网络环境下的连通性差异很大。如果用的是公司网络、公共网络，遇到商店加载不出来可以先换一个网络环境试试，比如用手机热点连一下，多半能解决。

检查路径有没有问题的方法是：看商店页面的报错信息里有没有出现C:\Users\...相关提示。如果只是网络超时的错误，那就跟迁移无关，不用在目录上反复折腾。

5.3 同步功能被路径问题搞乱

很多朋友现在会开 Settings Sync 或登录账号同步插件列表。迁移目录后偶尔会出现“同步来的设置没有生效、登录态失效”的情况，这主要是因为你虽然搬了扩展目录，但编辑器把登录凭据、密钥、会话信息放在用户数据目录里，也就是AppData\Roaming下面的那些文件。如果你只搬了扩展目录，登录态理论上不会失效；但如果你把整个用户数据目录也一起搬到 D 盘，就可能遇到重新登录的问题。

遇到登录失效，别慌，重新登录一次即可。同步回来的插件列表如果出现重复启用，去扩展面板把禁用的扩展重新启用就行。这里给大家提醒一句：迁移完用户数据目录后，第一周尽量多关注同步状态，别同时折腾“迁移”和“清理同步配置”，不然出了问题很难判断是哪一步引发的。

6. 一些与路径无关但同样让C盘难受的优化

扩展目录搬完，C 盘确实会松一口气，但还没有彻底解决问题。很多朋友反馈“搬完 extensions 后 C 盘还是涨得很快”，这是因为还有一大块缓存没处理干净。接下来这几个优化点，是把 C 盘占用彻底压下去的关键。

6.1 将用户全局目录、workspaceStorage 一并迁移

VSCode 的用户数据目录（Windows 下是C:\Users\你的用户名\AppData\Roaming\Code）里存了工作区状态、面板布局、搜索历史、各种 Cache。它和插件目录一样，也是默认在 C 盘的。

如果你用的项目比较多，workspaceStorage 会存每个工作区的临时索引和状态数据，项目多时能占 1GB 以上。把整个用户数据目录搬走，跟搬扩展目录的操作一模一样：

xcopy "C:\Users\你的用户名\AppData\Roaming\Code" "D:\CodeData\CodeUserData" /E /I /H /Y ren "C:\Users\你的用户名\AppData\Roaming\Code" "Code_old" cmd /c mklink /J "C:\Users\你的用户名\AppData\Roaming\Code" "D:\CodeData\CodeUserData"

Cursor 类似的目录是AppData\Roaming\Cursor，Kiro 是它自己的用户数据目录。搬到 D 盘后，编辑器启动时会自动往“原路径”写，实际上是写到了 D 盘，登录态、快捷键、界面布局全都不受影响。唯一要注意的是：首次启动时可能因为缓存迁移导致索引重建，打开大项目会慢一次，之后恢复正常。

6.2 定期清理旧的扩展版本

vscode 系编辑器更新扩展时，不会立刻把旧版目录删干净，而是留下旧目录并写一个.obsolete标记。如果某次更新异常中断，旧版本就会一直躺在那。我见过最夸张的案例是一个Python扩展，旧版本目录堆了四五个版本，合计超过 800MB。

清理时不要手动乱删目录，正确做法是：打开扩展面板，把不再使用的扩展正常卸载。如果某些扩展“卸载”按钮是灰色的，可以手动进扩展目录，按修改时间排序，删除最老的版本目录。删除前先确认当前正常使用的新版本目录还在。这个方法对 vscode、cursor、kiro 都适用。

6.3 用环境变量统一“用户数据”的位置

如果你不想每次都手动复制、建联接，可以考虑用启动参数统一指定用户数据目录。比如在快捷方式目标里加上：

--user-data-dir "D:\CodeData\CodeUserData"

这样编辑器会直接把所有用户数据写到 D 盘，根本不碰 C 盘。但对已经跑了一段时间的现有配置来说，这个参数不会自动帮你迁移旧数据，你得先手动把旧目录里的内容复制过去，再改启动方式。

我个人的习惯是：日常主力用目录联接，不用启动参数，因为不怕哪个入口忘了带参数。只有当我在测试多套配置、想快速切换不同工作环境时，才用--user-data-dir或--extensions-dir做临时切换。

最后再分享一个我自己的操作习惯。迁移完三个编辑器的目录之后，我在 D 盘专门建了一个CodeData文件夹，把 vscode、cursor、kiro 的扩展和用户数据分门别类放好，然后在系统盘的固态空间不够用时，第一时间想到的不是乱删东西，而是去检查这几个目录又长了多大。折腾完这套流程，C 盘从长期飘红变成稳定有富余，机器整体响应速度都回去了。如果你也在被编辑器目录撑爆系统盘的问题困扰，按上面的思路一步步来，基本不会再走弯路。