很多人以为 Mac 的空间问题只要“删一删”就行，但真正长期占空间的，往往是 ~/Library 里的聊天数据、媒体缓存和离线资源。
Disk Relocator 想解决的就是这个现实问题：把微信、Telegram、钉钉、飞书、Discord 这类应用的大目录迁到外接盘，同时保留可控、可回滚、可追踪的操作路径。
项目地址：Disk Relocator
为什么要做这个工具
在 macOS 上，“手动 mv + ln -s”当然能用，但它有几个典型痛点：
- 迁移成功后缺少统一台账，后续很难维护。
- 外接盘掉线或只读时，没有清晰告警和修复路径。
- 中途异常后容易留下“半迁移状态”，普通用户很难判断能不能继续用。
Disk Relocator 的目标不是再造一个命令行脚本，而是给出一套可视化、工程化、可恢复的迁移体验。
这不是“万能迁移器”，而是有边界的工具
这个项目明确面向固定工位场景：
- 适合：小容量 Mac + 长期连接同一块外接 SSD。
- 不适合：频繁拔插硬盘、经常移动办公、要求“离盘也完全无感”的使用方式。
换句话说，它优先解决“长期稳定释放系统盘空间”的问题，而不是覆盖所有极端场景。
核心设计：事务化迁移，而不是一次性硬切
Disk Relocator 的核心流程是：
- 预检（进程、权限、挂载状态、可用空间、策略）
- 复制（先拷贝到目标临时位置）
- 校验（体积/一致性校验）
- 原子切换（源目录备份 + 建软链接）
- 后检（可读写探针、链接健康）
- 清理（成功收尾）或自动回滚（失败恢复）
这套流程的价值很直接：任何步骤失败，都尽量回到一致状态，而不是把用户留在“看起来迁过但又不能用”的尴尬中间态。
当前支持应用（以线上画像为准）
- WeChat（Non-MAS）
- Telegram（macOS 原生版）
- 钉钉（DingTalk）
- 飞书（Feishu / Lark）
- Discord
项目采用“画像驱动”的策略：不盲目声称支持任意应用，而是对每个应用定义可迁移单元、风险等级、预检与回滚策略，保证行为可验证、可复现。
5 分钟上手
- 准备稳定的外接 SSD（建议 APFS），并确保迁移时保持挂载。
- 打开应用后点击“刷新扫描”。
- 在应用列表选择目标应用，点击“搬迁外存”。
- 在弹窗确认迁移目录与目标盘，开始迁移。
- 迁移后到“健康检查”确认状态。
- 若需恢复，在应用卡片点击“恢复到系统”。
下载安装可在 Releases 获取最新 .dmg。
微信用户务必注意
微信属于高风险迁移单元。迁移完成后建议立即执行一次：
sudo codesign --sign - --force --deep /Applications/WeChat.app并且在微信每次升级后再执行一次，避免微信在 app_data 下重新初始化目录导致历史记录不可见。
健康检查与一键回滚
我在这个项目里把“修复策略”拆成两层：
- 自动纠偏：只处理可证明无损的动作（比如清理残留临时目录、修正元数据状态）。
- 一键回滚：在异常持续、影响使用时，优先恢复系统盘路径，尽快回到可用状态。
推荐顺序是先做健康自检，再决定是否回滚。尤其遇到“磁盘离线/只读”时，先恢复磁盘状态通常更稳妥。
技术栈与后续方向
项目使用 Tauri + Rust + Vue，本地元数据由 SQLite 管理，目标是把迁移、健康检测、回滚、日志追踪连成闭环。
后续会继续完善应用画像与测试矩阵，优先保障已支持应用的稳定性，而不是盲目扩展名单。
如果你也在被系统盘空间折磨，欢迎试用并提交反馈。
如果这个项目对你有帮助，也欢迎在 GitHub 点个 Star。