WorkBuddy缓存撑爆C盘？Junction迁移实战与6大坑

1. 为什么我要折腾这次数据目录迁移

C 盘红了这件事，几乎每个在 Windows 上重度使用开发工具的人都躲不过。我这台机器系统盘是一块 512G 的固态，装完系统、Office、几个 IDE 之后还剩两百多 G，本来挺宽裕。结果用 WorkBuddy 做了一段时间的项目之后，某天右下角突然弹了个"磁盘空间不足"的提示，点开一看，C 盘只剩 4 个多 G，进度条红得发紫。

打开资源管理器一层层翻，最后定位到 C:\Users\我的用户名\AppData\Roaming\WorkBuddy 这个目录，体积已经膨胀到 60 多个 G。里面主要是三类东西：会话历史、索引缓存、还有各种 skill 运行时产生的中间文件。这些数据有个共同特点——读写频繁、体积增长快、但又不是系统运行必需的。换句话说，它们完全可以搬到别的盘去，没必要赖在系统盘上占地方。

这次迁移我用的方案是 Junction（目录联接），配合 robocopy 做数据搬运、icacls 做权限修复。整个过程踩了 6 个坑，有的坑差点让我把数据搞丢，所以我把完整过程记录下来，包括每一步为什么这么做、参数怎么算、出问题怎么救。如果你也在被 WorkBuddy 的缓存目录撑爆 C 盘，或者你用的是 CodeBuddy 这类同源工具、遇到"怎么更改系统缓存目录"的问题，这篇可以直接抄作业。

先说清楚适用人群：这篇适合有一定 Windows 操作基础、能看懂命令行、愿意动手改目录结构的用户。如果你完全没碰过 CMD 或者 PowerShell，建议先找个懂行的朋友在旁边看着，因为迁移过程中一旦路径搞错，轻则工具打不开，重则数据要重新下载。另外提醒一句，迁移前一定要备份，这不是客套话，是我踩坑之后最真实的体会。

2. 迁移方案的整体设计与选型思路

2.1 三种常见方案对比：为什么最终选 Junction

把一个大目录从 C 盘挪到 D 盘，Windows 上其实有好几种做法，我逐一试过或者评估过，最后才定下 Junction。先把这几种方案的优劣摆出来，你就明白我为什么这么选了。

我一开始想走"直接改配置"这条路，毕竟最省事。翻了 WorkBuddy 的设置项，发现它确实有缓存目录相关的配置，但改完之后重启，部分 skill 还是往原来的 AppData\Roaming\WorkBuddy 里写数据。这说明它的路径引用不是单一入口，有些模块是硬编码的。这种情况下，改配置只能解决一部分问题，治标不治本。

符号链接我也考虑过，mklink /D 创建的是软链接，理论上更"现代"。但实测下来，WorkBuddy 里有些底层组件在读取路径时对软链接的支持不稳定，偶尔会出现"找不到文件"的报错。而 Junction 在 Windows 上的兼容性是所有链接方式里最好的，它对上层程序完全透明——程序以为自己在访问 C:\...\WorkBuddy，实际上数据躺在 D 盘。这就是我最终选它的核心原因。

提示：Junction 和 Symlink 的区别，打个比方——Junction 像是把一扇门直接焊到另一个房间的入口，走进去就是那个房间；Symlink 像是给你一张写着"去隔壁房间"的纸条，你得先看纸条再走过去。前者对"访客"（程序）来说无感，后者需要访客愿意读纸条。

2.2 迁移前的容量测算与目标盘选择

选 D 盘不是随便选的。我这台机器 D 盘是一块 1T 的机械硬盘加一块 2T 的固态，最终我把目标定在固态那块上，盘符是 D。原因很简单：WorkBuddy 的缓存目录读写非常频繁，尤其是索引构建和会话加载的时候，如果放在机械盘上，你会明显感觉到工具变卡。缓存这种东西，宁可占固态的空间，也别为了省空间牺牲响应速度。

容量测算这块我算了一笔账。当前 WorkBuddy 目录 60 多 G，考虑到后续还会增长，我预留了 150G 的空间。D 盘固态剩余 800 多 G，完全够用。这里给个经验公式：

目标盘可用空间 ≥ 当前目录体积 × 2.5

为什么要乘 2.5？因为迁移过程中 robocopy 是复制而不是移动，源目录和目标目录会同时存在一段时间，等确认无误后才删源。再加上后续几个月的增长余量，2.5 倍是个比较稳妥的系数。如果你当前目录是