上周帮朋友处理一台 256GB 固态的笔记本系统盘可用空间只剩 3.2GB右下角红条一直挂着微信截图都存不进去。翻了一圈发现用户的桌面、下载、微信文件、conda 环境、Docker 镜像全都老老实实躺在 C 盘而旁边那块 1TB 的 D 盘闲着发慌。这件事其实特别典型Windows 上 C 盘清理从来不是删几个垃圾文件的问题而是哪些东西本就不该放在 C 盘的问题。这篇内容就来把这件事说透——从空间去向的判断到 Users、Program Data 这些目录怎么合理挪到 D 盘再到迁移之后软件报错怎么排查。适合三类人看C 盘飘红的普通用户、装了一堆开发环境把系统盘撑爆的程序员、以及帮别人装机维护的运维同学。不涉及任何灰色工具方法都能自己动手复核。1. 先搞清楚空间去哪了C盘告急的整体判断1.1 把看不见的占用量化出来的两种做法很多人清理 C 盘的方式是打开资源管理器右键看每个文件夹大小然后发现加起来才 60GB剩下的 200GB 凭空消失。这不是错觉而是资源管理器默认不统计隐藏目录和系统保护目录而且对硬链接的统计会重复计算WinSxS 就是重灾区它里面大量文件在 System32 里有硬链接副本直接被算了两遍。想把账算清楚我一般用两个手段配合。第一个是资源管理器勾选显示隐藏的项目同时把文件夹选项里的隐藏受保护的操作系统文件取消勾选这样C:\ProgramData、C:\Users\你的用户名\AppData、C:\Windows\Installer才会露出来。第二个是拿一个只读扫描的磁盘分析工具跑一遍树状图只看不动——注意是只看分析工具的删除按钮我从来不碰判断还是自己做。判断顺序上我习惯按这个清单逐个过位置典型占用是否可以迁移风险等级C:\Users\用户名20GB–200GB部分可以中C:\ProgramData5GB–80GB仅部分子目录高C:\Windows\WinSxS6GB–20GB不可只能 DISM 压缩高C:\Windows\SoftwareDistribution2GB–15GB可清理缓存低C:\Windows\Installer3GB–20GB不可删可谨慎处理高hiberfil.sys内存的 40%–100%可关闭或缩小低pagefile.sys内存的 1–1.5 倍可移到 D 盘中C:\Windows\System32\DriverStore3GB–10GB不可手删高C:\Windows\Temp1GB–10GB可清低这张表建议你截图存下来每次 C 盘告急先照着过一遍比盲目点清理按钮高效得多。有一个判断原则我一直在用凡是 Windows 在开机早期、安全模式、系统还原、Windows 更新这些场景下必须访问的目录一律不动其余的数据型目录才考虑搬。这条原则能帮你挡掉 90% 的翻车可能。1.2 清理与迁移两种路线的取舍逻辑C 盘瘦身有两条路很多人混着用结果两头都没做好。第一条是清理删缓存、关休眠、清更新残留、压缩组件存储。优点是见效快、可逆、几乎零风险缺点是治标几个月后又满而且天花板有限一般能挤出 10GB–40GB。第二条是迁移把数据目录整体搬到 D 盘再用目录联接Junction在 C 盘留一个传送门。优点是治本一次操作能腾出几十上百 GB后续新增数据也自动落到 D 盘缺点是有技术门槛做错了会导致软件启动失败甚至系统异常。我的建议是先清理后迁移顺序不能颠倒。原因是清理完之后你才知道真实的数据体积是多少才能判断到底需要搬哪些目录。我见过有人上来就把整个 Users 剪到 D 盘结果 8GB 的更新残留还留在 C 盘白折腾一场不说系统还进不去了。还有一个关键判断迁移只对数据目录有效对程序目录往往是负收益。比如C:\Program Files里的软件它的本体不过几百 MB 到几 GB真正吃盘的是它的缓存、日志、模型文件、镜像文件这些通常藏在 AppData 和 ProgramData 里。所以与其纠结把程序装哪儿不如把它的数据目录指向 D 盘。注意任何迁移操作前务必确认 D 盘是内置固定磁盘且文件系统是 NTFS。U 盘、移动硬盘、exFAT 格式的分区都不能作为联接目标——开机时盘符可能还没挂上系统直接找不到路径后果比 C 盘满严重得多。2. 不搬家也能腾出大空间清理环节的实操2.1 命令行组合拳从系统组件到更新缓存图形界面的磁盘清理cleanmgr够用但它漏掉的东西不少。我一般用一组命令补齐全部以管理员身份在 PowerShell 或 CMD 里执行。第一步分析组件存储的实际可用压缩空间DISM /Online /Cleanup-Image /AnalyzeComponentStore看输出里的可回收包数量。如果大于 0再执行压缩DISM /Online /Cleanup-Image /StartComponentCleanup注意别顺手加/ResetBase。这个参数会把所有已安装更新的旧版本清掉能多腾几个 GB但代价是从此无法卸载任何已安装的更新。我一般只在系统已经稳定运行几个月、短期内不打算回滚更新时才用它。第二步清理 Windows 更新缓存。这里的关键是先停服务再删文件否则删了也会被占用或者删不干净net stop wuauserv net stop bits rd /s /q C:\Windows\SoftwareDistribution\Download net start wuauserv net start bits第三步清系统临时目录和用户临时目录del /f /s /q C:\Windows\Temp\*.* del /f /s /q %TEMP%\*.*%TEMP%那条执行时会有大量文件正在被使用的报错这是正常的正在运行的软件会占用自己的临时文件跳过就行不用强删。第四步处理休眠文件和页面文件。休眠文件默认等于内存的 40% 以上16GB 内存的机器就是 6.4GB 起步powercfg /h /type reducedreduced模式保留快速启动但禁用完整休眠通常能把 hiberfil.sys 压到 2GB 左右。如果你根本不用休眠也不用快速启动直接powercfg /h off彻底关掉这是最干脆的。页面文件pagefile.sys我一直建议保留在 C 盘一个小尺寸同时在 D 盘放主页面文件。原因是Windows 在蓝屏时需要把内存转储写到 C 盘的页面文件里如果 C 盘完全没有页面文件出问题时你拿不到 dump 文件排查会变成盲猜。我的配置是 C 盘固定 2GBD 盘设成系统托管。2.2 三个容易被忽略的隐形大户第一个是系统还原点。Windows 默认会给系统盘分配最多 10% 的空间做还原点和卷影副本256GB 的盘就是 25GB。这个功能在关键时刻能救命所以我不建议直接关掉而是限制它的上限vssadmin list shadowstorage vssadmin resize shadowstorage /forC: /onC: /maxsize10GB第二条命令把上限压到 10GB既保留回滚能力又不会无限膨胀。你可以用第一条命令验证是否生效。第二个是事件日志。C:\Windows\System32\winevt\Logs目录下是一堆 .evtx 文件长期不清理的情况下安全日志、应用程序日志、系统日志加起来能到几个 GB。先看谁的体积大wevtutil el再针对性清空单个日志不会破坏日志服务新的记录会继续写入wevtutil cl Application wevtutil cl System安全日志我一般不清因为它在合规场景下有审计价值而且在很多机器上它的体积并不夸张。但如果确实占了几 GB也可以在确认无审计需求后清空操作前先把文件复制备份一份。第三个是Windows 安装残留。重装或大版本升级后会留下C:\Windows.old体积动辄 20GB 以上。它保留 10 天供你回退到旧系统10 天后系统会自动删除也可以手动提前删。删除方式是设置 → 系统 → 存储 → 临时文件里勾选或者用 cleanmgr 的以前的 Windows 安装选项。千万别直接右键删这个目录里面的权限结构特殊硬删会留下一堆删不掉的残骸那时候更麻烦。顺带说一句存储感知设置 → 系统 → 存储 → 存储感知打开之后可以让系统自动清理回收站里超过 30 天的文件和下载文件夹里长期未打开的文件。这个功能对我来说最大的价值不是省空间而是让我少做重复劳动一次配置长期受益。2.3 第三方清理工具的能与不能市面上叫某某清理大师的工具我基本不用理由很简单它们能做的事上面几条命令和系统自带功能都能做而它们额外做的事往往是我无法审计的。具体风险有三类。一是误删。为了显示清理了多少 GB这类工具倾向于把一切看起来像缓存的文件都算进去包括某些软件的配置文件和插件数据。我就遇到过把某个 IDE 的插件目录清掉后需要全部重装的情况。二是捆绑。安装过程中默认勾选的其他软件、浏览器主页修改、开机自启的守护进程这类行为在免费工具里太常见了。清理工具本身变成了占用源这挺讽刺的。三是注册表清理。这个功能我一直认为收益极低、风险不低。注册表里那些无效项占用的空间通常只有几十 MB删错了却可能导致某个软件无法启动或某个文件类型无法打开。那系统自带的清理能力够不够对大部分人来说够。设置 → 系统 → 存储里的分类清理 cleanmgr 的清理系统文件模式已经覆盖了主要场景。真正的好工具是能清楚告诉你哪个目录占了多少的分析类工具而不是一键帮你删的清理类工具。前者给你判断权后者替你承担风险而这个风险其实是你自己的。提示如果你确实要用第三方工具执行清理前一定先创建系统还原点。创建命令是wmic shadowcopy call create VolumeC:\或者在系统属性 → 系统保护里点创建。这几十秒能救你半天。3. Users目录搬家为什么不能直接剪切3.1 用户目录里的四类数据与各自风险C:\Users\用户名是绝大多数人 C 盘占用的头号凶手但它的内部结构风险差异极大必须分类对待。第一类是可见的用户文件夹桌面、文档、下载、图片、视频、音乐。这类是纯数据占用可能几十 GB而且移动起来最安全因为 Windows 原生支持改它们的位置。第二类是AppData\Roaming。这里放的是应用配置、账号信息、插件、部分应用数据。它的特点是大量软件在安装时就把这个绝对路径写进了配置文件甚至注册表路径一变就找不到自己。这层要挑着搬。第三类是AppData\Local。缓存、临时数据、模型文件、包管理器缓存大多在这里。这是最值得搬的一层也是收益最大的一层。像 pip 缓存、HuggingFace 模型缓存、各类 IDE 的索引缓存动辄几十 GB。第四类是AppData\LocalLow和NTUSER.DAT等。前者是低完整性级别的应用数据浏览器沙箱、部分游戏后者是用户注册表配置单元。这两个绝对不能动尤其是 NTUSER.DAT它是系统加载用户配置的核心文件。我见过最惨的一次是有人直接把C:\Users\张三整个剪切到 D 盘然后开机进了一个空的临时配置文件——因为系统找不到原本的用户配置自动创建了一个临时账户。数据其实没丢但用户以为全没了又重装了一遍系统。所以这里必须说清楚C:\Users这个目录本身的绝对路径是写死在注册表 ProfileImagePath 里的直接剪切是最不可取的做法。顺带回答一个高频问题Win10 改了用户名显示名为什么C:\Users下的目录名没变因为改账户显示名只影响登录界面和开始菜单显示不影响配置文件目录名。想改目录名必须新建账户重新配置或者去注册表里改 ProfileImagePath 并同步重命名目录——后者操作失误风险极高我不推荐普通用户尝试。更稳妥的做法是新建一个英文名账户然后把数据迁移过去。3.2 官方支持的做法逐个文件夹改位置这是我最推荐的 Users 迁移方式因为它完全是 Windows 原生支持的功能不需要任何链接技巧也不会破坏软件。操作路径打开C:\Users\用户名右键下载文件夹 → 属性 → 切到位置选项卡 → 点移动 → 选择 D 盘上的目标文件夹比如D:\UsersData\Downloads→ 应用。系统会问你是否要移动已有文件选是它会把现有内容搬过去并把路径登记到注册表。同样的操作适用于文档、图片、视频、音乐、桌面、3D 对象这几个标准文件夹。桌面这个特别值得搬很多人桌面堆了几十 GB 的文件自己都没意识到。这套方法有几个细节要注意。一是目标文件夹最好提前建好且放在一个专门的数据目录下统一管理别散落在 D 盘根目录各处。二是保存的游戏和联系人这两个文件夹可能不显示位置选项卡属于正常现象跳过即可。三是操作过程中不要中断尤其是文档和图片体积大的时候中断可能留下半搬运状态此时重新执行一次移动到同一目标即可系统会续传剩余文件。这套操作能解决 80% 的用户数据占用问题。如果你做完之后 C 盘还是紧张那就说明真正的大头在 AppData需要进入下一节。3.3 用目录联接做曲线搬家的完整步骤目录联接Junction是 NTFS 文件系统的一个特性在 C 盘创建一个传送门访问它时系统会自动转向 D 盘的真实目录。对上层软件来说路径完全没变所以不会报错。这就是它比直接剪切高明的地方。我以迁移AppData\Local\Temp为例把完整流程拆开。这个目录值得优先搬的原因是它又大又脏而且几乎所有软件都往里写临时文件长期不清理能到十几 GB。第一步确认原目录位置和体积顺便关掉正在使用它的程序。第二步把内容搬到 D 盘用 robocopy 而不是剪切粘贴robocopy C:\Users\YourName\AppData\Local\Temp D:\CDiskMove\Temp /E /COPYALL /MOVE /R:1 /W:1 /XJ这条命令里几个参数值得解释/E复制所有子目录包括空目录/COPYALL复制包括权限和所有者在内的全部属性这是关键少了它可能导致链接后权限不足/MOVE复制完成后删除源文件/R:1 /W:1表示失败只重试 1 次、每次间隔 1 秒避免遇到被占用的文件时无限卡住/XJ排除目录联接防止递归死循环——如果你的源目录里已经有链接没有这个参数会把自己套进去。第三步确认源目录已经空了如果还有残留通常是正在被占用的文件重启一次再删。第四步创建联接mklink /J C:\Users\YourName\AppData\Local\Temp D:\CDiskMove\Temp看到为 xxx yyy 创建的联接就成功了。第五步验证在资源管理器里打开 C 盘那个 Temp看地址栏和内容是不是 D 盘的内容然后随便新建一个文件去 D 盘对应目录看它是不是也出现了。这套流程可以套用到很多目录上我按收益和风险排了个优先级目标目录收益风险推荐度AppData\Local\Temp高低强烈推荐AppData\Local\pip\Cache中高低推荐AppData\Local\Microsoft\Edge\User Data高中谨慎AppData\Local\Google\Chrome\User Data高中谨慎AppData\Roaming\某软件中高逐个评估AppData\Local\Packages高高不推荐浏览器用户数据我不太推荐做联接原因是浏览器更新频繁且对文件锁和权限比较敏感出问题后修复成本高。更稳妥的办法是直接在浏览器里改下载目录再把缓存上限调到几百 MB。而AppData\Local\Packages是 UWP 应用的数据涉及容器化的权限体系动了容易出各种玄学问题建议保留在 C 盘。注意创建联接前务必把源目录彻底清空并删除。如果源目录还存在mklink /J会直接报文件已存在。另外 32 位和 64 位系统的联接兼容性没问题但跨文件系统比如 D 盘是 exFAT会失败。迁移完这三个大块一台典型笔记本通常能腾出 30GB–80GB。如果你还装了开发环境那还有一大块可以挖继续往下看。4. ProgramData与软件目录从源头装到D盘4.1 ProgramData里到底有什么为什么不能整体搬C:\ProgramData是个隐藏目录很多人根本不知道它存在但它经常悄悄占用十几到几十 GB。它存的是所有用户共享的应用数据安装包缓存、许可证文件、共享配置、服务端数据。先说要紧的结论不要整体把 ProgramData 搬到 D 盘。原因有三层。第一层是加载时序。这个目录在系统启动早期就被服务和驱动访问可能早于 D 盘完成挂载。如果它不是真实的本地目录而是一个联接某些服务会读不到路径表现可能是 Windows 更新失败、安全中心无法启动、某些驱动加载异常。第二层是权限模型。ProgramData 下的子目录权限是各家软件自己设定的有的只允许 SYSTEM 访问有的给 Users 只读。整体搬移后如果权限继承链断了会出现一堆拒绝访问。第三层是系统恢复与安全模式。在安全模式或恢复环境下第三方盘符可能不可用而系统组件仍然会去访问 ProgramData 的路径直接失败。那怎么处理答案是只搬具体的大体积子目录一个一个来流程和上一节的联接方法完全一致。我按经验列几个值得搬的C:\ProgramData\DockerDocker Desktop 的镜像和容器数据几 GB 到几十 GB这是最值得搬的。C:\ProgramData\Anaconda3或miniconda3Python 环境和包缓存包缓存目录尤其大。C:\ProgramData\Package CacheVisual Studio 和各种运行库的安装包缓存经常十几 GB。注意这个目录删了会导致修复/卸载功能失效所以是搬不是删。C:\ProgramData\chocolatey包管理器的下载缓存。C:\ProgramData\NVIDIA Corporation驱动安装缓存通常可以清理。操作时有一个细节Package Cache这类目录里有大量长路径和特殊权限文件用 robocopy 时要留意路径长度限制。如果遇到路径过长报错可以先启用长路径支持或者用\\?\前缀绕过。4.2 新软件从源头装到D盘的配置清单比起搬已装软件新软件从一开始就装到 D 盘成本低得多。我把常用的几类配置整理成一份可以直接照抄的清单。核心思路是能改安装路径的改路径不能改的改缓存目录环境变量。Python 环境Miniconda / Anaconda。安装时把路径直接选到D:\Miniconda3并且不要勾选为所有用户安装那会往 ProgramData 写。装完之后改包和环境目录conda config --add envs_dirs D:\Miniconda3\envs conda config --add pkgs_dirs D:\Miniconda3\pkgs conda config --show | findstr dirs另一个关键设置是 pip 的缓存目录pip config set global.cache-dir D:\DevCache\pippip 的 wheel 缓存长期不清理能到十几 GB而且每次装包都在 C 盘现攒。改掉之后新装的包缓存直接落 D 盘。顺带把 HuggingFace 模型缓存也改掉现在动辄几 GB 的模型文件全默认往C:\Users\用户名\.cache里塞setx HF_HOME D:\DevCache\hf setx TORCH_HOME D:\DevCache\torchsetx设置的是永久环境变量需要重开终端才生效。WSL 发行版。新版 WSL 支持直接搬移比导出再导入省事得多wsl --list --verbose wsl --manage Ubuntu --move D:\WSL\Ubuntu注意发行版要先关闭wsl --shutdown再搬。搬完之后用wsl --list --verbose确认状态是 Stopped 且位置正确。旧版本 WSL 没有--manage参数的话用wsl --export导出 tar注销原发行版再wsl --import到 D 盘——这套流程多一步但兼容性更好。Docker Desktop。设置 → Resources → Advanced → Disk image location改成 D 盘的目录。改完它会自动搬移现有镜像体积大的话要等一会儿。改完之后ext4.vhdx就不在 C 盘了这一项通常能省 20GB 以上。VSCode。它的用户数据、扩展、缓存默认分在三四个位置。最省事的做法是改快捷方式的目标加上两个参数C:\Program Files\Microsoft VS Code\Code.exe --extensions-dir D:\VSCode\extensions --user-data-dir D:\VSCode\data这个操作要提醒一句--user-data-dir一改原本的设置、已装扩展列表、登录状态都会消失因为它们还在老位置。正确做法是先把%APPDATA%\Code和%USERPROFILE%\.vscode\extensions的内容完整复制到新目录再改快捷方式。工作区的.vscode目录不受影响放在项目里的。Ollama 等本地模型服务。这类工具默认把模型放在用户目录可以用环境变量指定setx OLLAMA_MODELS D:\AIModels\ollama大模型的体积是 GB 级别的几十 GB 很常见这一项不设的话 C 盘基本撑不住。通用临时目录。最后一步是把系统临时目录也改到 D 盘系统属性 → 高级 → 环境变量把用户变量和系统变量里的TEMP和TMP都改成D:\Temp。改完重启生效。这一步配合前面 Temp 的联接方案效果是叠加的——我一般两个都做环境变量负责新进程联接负责兜底老路径。4.3 已装软件的数据目录重定向与验证已经装好的软件处理方式分三种。第一种软件自带设置项。所有正经的软件都有修改数据目录的入口找设置里的存储位置下载目录缓存路径这类字眼。微信、QQ、企业微信、各类笔记软件、IDE 都支持。这是最安全的方式优先用它。第二种改环境变量。适合那些不提供设置入口但认环境变量的工具比如 pip、npm、HuggingFace 系列。npm 的缓存可以这样改npm config set cache D:\DevCache\npm --global npm config set prefix D:\DevCache\npm-global第三种目录联接。适合完全不给你配置入口、又确实占地方的软件。流程和 3.3 节完全一样robocopy 搬移 → 删空源目录 → mklink /J 建链接。无论用哪种方式做完之后一定要验证。我的验证清单是三步一是打开软件的设置界面看它显示的路径是不是新位置二是跑一遍核心功能比如下载一个文件、打开一个项目、拉取一次依赖确认不报错三是回 C 盘原路径看新文件还会不会生成在那里。第三步最容易发现问题——有些软件会自动修复路径把你搬走的目录重新在 C 盘建一个这种情况就得找它的配置文件强制指定。提示迁移之后不要马上清理 D 盘上的备份。我有一次迁移完顺手删了源目录结果三天后发现某个软件其实是双写机制两个目录的用途不同删掉的那个是配置文件目录。留一周观察期成本几乎为零。5. 常见问题与排查实录5.1 迁移后报错的排查顺序报错一OSError: [WinError 1114] 动态链接库(DLL)初始化例程失败加载c10.dll失败。这个报错在 PyTorch 用户里特别常见典型场景是直接把 conda 环境从 C 盘剪切到 D 盘之后torch 就起不来了。原因有两层。一是 conda 环境里的很多脚本和元数据记录了创建时的绝对路径剪切之后这些记录失效导致依赖库的搜索路径错乱c10.dll这个 torch 的核心库加载不到它依赖的其他 DLL。二是这类报错也可能是VC 运行库缺失或版本不匹配造成的跟路径无关。排查顺序我建议这样走先确认是不是路径问题——创建一个全新的环境试试conda create -n test python3.10再装 torch如果新环境正常说明就是搬移导致的老环境损坏直接重建环境比修复靠谱得多。如果新环境同样报错那问题在运行库去装最新的 VC 可再发行组件包同时检查是否有多个 Python 版本混用导致的 DLL 冲突。这里有个重要经验conda 环境不推荐用复制粘贴或剪切的方式迁移。正确做法是用conda env export env.yml导出依赖清单在新环境conda env create -f env.yml重建。或者用conda-pack打包成 tar它在解包时会做路径重定位处理比手工剪贴可靠得多。报错二软件启动后提示找不到配置文件或恢复到了默认设置。这说明路径迁移成功但配置文件没跟着走或者软件读的是 Roaming 目录而不是 Local 目录。处理方式是检查它的配置指向必要时把 Roaming 下的对应目录也一起搬。报错三迁移后系统还原失败或者某些系统功能异常。这通常是因为动了不该动的目录。排查方法是检查你创建的所有联接是否都指向真实存在的 NTFS 目录以及 D 盘是否在开机时正常挂载。附件里的计算机管理 → 磁盘管理能看到 D 盘的健康状态。报错四winget install之类的命令失败。这类工具在 Windows 上依赖 MSIX 组件和网络连通性权限不足时也会直接失败。我的处理方式是先用winget --version确认组件本身正常然后改用管理员身份运行实在不行就去官网下安装包手动指定安装路径——反正我们的目的就是装到 D 盘手动装反而更好控制位置。5.2 权限、盘符与还原点相关的典型坑坑一D 盘新建文件夹提示需要管理员权限。这是 D 盘根目录的 ACL 没有给普通用户写权限。原因是部分品牌机出厂时对数据盘做了权限收紧或者你在某个时点把根目录权限改成了仅管理员。处理方式有稳妥和激进两种。稳妥的是不要在 D 盘根目录直接建文件夹改成在自己的用户目录下建比如D:\UsersData\...或者在 D 盘建一个顶层目录然后修正它的权限右键 → 属性 → 安全 → 高级 → 更改权限 → 添加当前用户 → 勾选完全控制 → 勾选替换子容器和对象的所有者。激进的是一上来把 D 盘根目录所有权限改成 Everyone 完全控制这个操作会削弱系统整体的权限边界我不推荐尤其是多人使用的机器。坑二系统还原之后迁移的软件找不到了或者又占满 C 盘了。这是必然的——系统还原会回滚注册表和系统目录但不会回滚你在 D 盘建的目录也不会恢复你在 C 盘建的联接。所以还原之后需要重新建立联接。这也是我建议把每一步操作记录下来、写个清单的原因还原之后照着清单重做一遍十分钟搞定比抓瞎强。坑三某块数据盘突然消失或者显示未格式化。遇到这种情况第一原则是不要格式化、不要用任何修复工具去写盘。先检查物理连接线缆、供电、是否移动硬盘再看磁盘管理里盘是否可见。如果能看到但没盘符手动分配盘符即可如果显示未分配那可能是分区表问题此时最要紧的是先把重要数据用只读的方式备份出来再考虑后续。另外要排查盘符冲突——有些外设会抢占盘符把原本的 D 占掉导致路径全部失效。坑四C 盘空间紧张想把 D 盘的空间划一部分给 C 盘。这个操作可行但有前提。Windows 自带磁盘管理的扩展卷功能只能吃掉紧邻 C 盘右侧的未分配空间。如果你的 C 盘和未分配空间中间隔着一个恢复分区这条路就走不通需要更专业的工具来移动分区而移动分区是有数据风险的操作。我的建议顺序是先做前面几节的清理和迁移把能省的省下来再考虑动分区。因为迁移是安全的分区的风险高一个量级。如果确实要做压缩 D 盘前先完整备份压缩之后在磁盘管理里点扩展卷一路下一步中间不要中断。坑五迁移过程中断电或者强关机。这是最糟的情况可能留下文件搬了一半、源目录还剩一半、链接还没建的中间状态。恢复思路是先确认 D 盘上的目标目录里有多少数据然后重新执行一次 robocopy 的搬移命令不带 /MOVE先把 D 盘已有的跳过确认两边数据一致后再删源目录、建链接。不要急着删任何一边两个目录同时存在不会影响使用只是暂时多占点空间。5.3 常见问题速查表现象最可能原因处理方式mklink 报文件已存在源目录没删干净确认空目录后删除再执行联接后软件报拒绝访问复制时丢了 ACL 权限用 robocopy /COPYALL 重搬一次联接目录打开是空的D 盘未挂载或路径写错检查盘符和mklink /J的目标路径conda 环境搬后崩了绝对路径写死在环境里导出依赖清单重建环境系统还原后链接失效还原不回滚 D 盘和链接按操作清单重做联接更新一直失败SoftwareDistribution 被占用或损坏停服务后清空 Download 再重启服务winSxS 清理后无法卸载更新用了 /ResetBase无解只能等系统自行整合临时目录改了但软件还往 C 写老进程未重启或软件硬编码路径重启 对该目录单独做联接D 盘文件被误搬回 C 盘软件自动修复路径查软件配置强制指定目录磁盘管理中扩展卷是灰的C 盘右侧没有紧邻的未分配空间先做清理迁移或评估分区调整风险最后分享一个我在多台机器上反复验证过的小技巧把整个流程写成一个批处理脚本包含 robocopy 搬移、源目录删除、mklink 建链、验证输出四段。因为家里和公司、笔记本和台式机的迁移需求高度相似脚本化之后新机器上十分钟就能完成一轮迁移而且不会漏步骤。脚本里每一行前面加一句echo输出当前在干什么迁移的时候心里有底。这比每次手动敲命令可靠得多也是我从踩了几次坑之后才养成的习惯。