Microsoft Store默认安装路径改D盘：C盘空间释放与迁移指南

D 盘空着小两百个 G，C 盘那一百来 G 的可用空间却已经开始标红，打开存储感知一看，罪魁祸首不是缓存也不是临时文件，而是 Microsoft Store 装的那一堆应用，安安静静全躺在 C 盘的 WindowsApps 里。这个场景我前后在至少五六台机器上遇到过，有公司配的办公本，也有自己攒的台式机，只要用 Store 装过游戏、装过 HEVC 视频扩展、装过一些生产力工具，系统盘的膨胀速度就肉眼可见。很多人第一反应是"删点东西不就行了"，但真正的解法其实只有一个方向：把 Microsoft Store 的默认安装路径挪到非系统盘去，让新装的应用从源头上不再往 C 盘塞。

这件事听起来像是个高级操作，实际上 Windows 10 早就给了官方入口，只是藏得比较深，而且有几个前提条件不满足的话，那个下拉框里根本看不到你想选的那块盘。这篇文章我会把三条路都讲清楚：官方图形界面的改法、已安装应用的搬迁办法、以及需要动注册表和目录权限的进阶方案。中间会带上我实际踩过的坑，比如为什么新建一个文件夹丢到 D 盘之后 Store 装的应用全都打不开、为什么"移动"按钮有时候是灰的、为什么改完之后 C 盘并没有像想象中瘦那么多。

1. 系统盘告急背后的真凶：Store 到底把东西塞哪了

1.1 三个偷偷长大的目录

想改路径，先得知道东西具体落在哪。Microsoft Store 应用在系统盘上主要有三个落点，很多人只盯着第一个，忽略了后面两个，结果清理的时候怎么都清不干净。

第一个是C:\Program Files\WindowsApps。这是应用本体的安装目录，也是体积最大的一个。它默认是隐藏的、受系统保护的，用资源管理器直接看是看不到的，必须先打开"显示隐藏的文件、文件夹和驱动器"，再去掉"隐藏受保护的操作系统文件"的勾，才能勉强看到它。这个目录的所有者是TrustedInstaller，管理员账户默认只有读取权限，双击进去会直接被拒绝访问，这其实是微软故意设计的保护机制，防止用户手滑删掉应用本体导致系统组件崩溃。

第二个是C:\Program Files\WpSystem，以及对应目标盘根目录下的WpSystem。这个目录容易被忽视，它装的是 Store 应用的用户数据部分，按 SID 分子目录存放。把这个目录当成垃圾删掉，后果是应用能装上但一打开就闪退或者配置全部丢失。

第三个是C:\Users\<用户名>\AppData\Local\Packages。这是 Store 应用的沙箱数据目录，应用的配置文件、缓存、数据库、用户文档基本都在这里，按PackageFamilyName分文件夹存放。这个目录是最顽固的，因为它跟用户账户绑定，即使你把应用本体挪到了 D 盘，这一部分依然留在 C 盘。

1.2 为什么值得改，又不能盲目改

改默认路径的收益很直接：新安装的应用本体落到非系统盘，系统盘的空间可以被释放出来，尤其是那些动辄几十 G 的大型应用和游戏，效果立竿见影。但收益背后有两个必须提前接受的现实。

一是这个操作不搬旧账。你把默认路径改成 D 盘，已经装在 C 盘上的应用不会自动跟着走，它们还在原地。想让它们也过去，得挨个手动搬，而部分应用根本不支持迁移。

注意：改默认安装路径只影响"之后新装的应用"，对"已经装好的应用"毫无影响。网上很多教程把这两件事混在一起讲，导致一堆人改完发现 C 盘一点没小，然后开始怀疑操作失败。

二是别指望 C 盘能瘦一大圈。前面说了，用户数据目录AppData\Local\Packages是搬不走的，很多 Store 应用的运行日志、缓存、用户文档都堆在这里，占用的空间有时候能到本体的一半。所以改路径的正确预期是"C 盘增长速度变慢"，而不是"C 盘瞬间多出 50 个 G"。我在自己的主力机上测过，一套总共占用约 42 G 的 Store 应用，把本体全部挪到 D 盘之后，C 盘实际释放了约 27 G，剩下的 15 G 就是沙箱数据和其他零碎。

2. 动手之前必须确认的四个前提条件

2.1 目标盘必须是本地固定磁盘且格式为 NTFS

这是最容易卡住新手的一条。Windows 的那个"新的应用将保存到"下拉框，只列出符合条件的卷：必须是本地固定磁盘（不能是 U 盘、移动硬盘这类可移动设备），文件系统必须是 NTFS，而且不能是网络映射盘。FAT32 和 exFAT 一律不认，哪怕你手上的移动硬盘有 2T 空着，它也不会出现在列表里。

为什么会这样？因为 Store 应用的安装过程需要创建符号链接、设置复杂的访问控制列表（ACL），还要把目录所有者改成TrustedInstaller。这几样能力 exFAT 和 FAT32 天生不具备，微软干脆在界面上就把不合格的卷过滤掉了，省得用户白折腾。

如果你手上的第二块盘是 exFAT 格式，唯一的办法是备份数据后重新格成 NTFS。这一步不可逆，动手前一定要确认盘里的东西都有备份。

2.2 空间余量、盘符稳定性与加密状态

第二块盘最好留出足够余量。Store 应用在安装过程中需要临时解压和校验，实际占用会短暂超过应用本身的体积，一般建议目标盘至少保留 20 G 以上的空闲空间。空间不够的时候，安装会以磁盘空间不足的错误收场。

盘符稳定性这一点经常被忽略。如果你把默认路径设成了 D 盘，之后又因为插了别的设备导致盘符漂移，变成 E 盘，那么系统记录的那些应用路径就会全部失效，表现是应用图标还在但点不开。所以设置之前，建议在磁盘管理里确认一下这块盘的盘符是不是稳定的，必要时可以通过磁盘管理的"更改驱动器号和路径"把它固定成一个不太容易被占用的字母，比如用 M 或者 W 这类不常用到的字母。

另外，如果目标盘启用了 BitLocker，要确认它在开机时是自动解锁状态。如果每次重启都需要手动输密码才能解锁，那么在系统启动阶段应用会处于不可访问状态，部分开机自启的 Store 应用可能会报错。

2.3 先给系统留一条后路

这个操作本身风险不高，官方路径改法几乎是零风险，但既然涉及注册表和权限，我个人的习惯是每次动这类设置之前先做两件小事：创建一个系统还原点，并把关键注册表项导出备份。

创建还原点的最快方式是在开始菜单搜索"创建还原点"，打开系统属性里的系统保护选项卡，选中系统盘，点"创建"，起个能看懂的名字比如"改Store路径前"。注册表备份则用一行命令搞定：

reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx" "%USERPROFILE%\Desktop\appx_backup.reg" /y

这条命令会把跟 Store 安装路径相关的整个注册表分支导出到桌面。万一后面出问题，双击这个.reg文件就能还原回去。两分钟的成本，换的是出事之后不用重装系统的底气。

3. 官方图形化改法：三分钟把新应用落到 D 盘

3.1 设置里的操作路径

这是我最推荐的方案，全程点鼠标，不需要命令行，也不需要碰权限。路径是：开始菜单 → 设置 → 系统 → 存储 → 找到"更多存储设置"区域里的"更改新内容的保存位置"。

点进去之后会看到一个列表，分别是新的应用、新的文档、新的音乐、新的照片和视频、新的电影和电视节目，每一项后面都有一个下拉框用来选择保存的驱动器。我们只需要关注第一项"新的应用将保存到"，把它从 C 盘改成目标盘，然后点右边的"应用"按钮。

提示：这个页面上其他几项（文档、音乐、照片等）改不改都行，它们只影响系统自带应用和部分 UWP 应用的默认保存位置，跟 Store 应用的安装路径是两套逻辑。不想折腾的话只改第一项就够了。

点完"应用"按钮之后，Windows 会立刻去目标盘根目录创建两个文件夹：WindowsApps和WpSystem。这两个文件夹同样是隐藏的，看不到是正常的。如果那块盘上原本就有同名文件夹，Windows 会尝试复用，这时候就有可能出现权限不匹配的问题，后面第 6 节会专门讲怎么处理。

3.2 这一步背后到底改了什么

很多人以为这只是改了个 UI 偏好，其实不是。从实际观察来看，点下"应用"之后，系统改的是这个注册表项：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx 值名称：PackageRoot 值类型：REG_EXPAND_SZ 值数据：D:\WindowsApps

想自己验证的话，管理员权限打开 PowerShell，跑一行就行：

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx" -Name PackageRoot

这个PackageRoot值就是整个机制的枢纽。它告诉系统的应用部署服务：新来的包往哪儿放。图形界面只是这个注册表值的一层皮，理解了这一点，后面手工方案为什么能生效，以及为什么改完注册表还得配权限，就都能串起来了。

这里还有个技术细节值得说清楚：PackageRoot决定的是"新包落到哪个卷"，而已安装包的确切位置是记录在系统的应用状态库里的，跟这个注册表值无关。所以无论你怎么改，已经装好的应用都不会自己搬家，这不是 bug，是设计如此。

3.3 装个测试应用验证

改完之后别急着大规模安装，先拿一个体积小的应用验证一下。我的习惯是装一个 HEVC 视频扩展或者随便一个免费的小工具，装完之后用 PowerShell 查一下它的实际落地位置：

Get-AppxPackage | Where-Object { $_.InstallLocation -like "D:\*" } | Select-Object Name, Version, InstallLocation | Format-Table -AutoSize

正常的话应该能看到刚装的应用出现在列表里，InstallLocation指向D:\WindowsApps\<包全名>。如果列表是空的，说明路径没生效，回头检查第 3.1 步的下拉框有没有真的选对并且点了"应用"。

注意：有些应用是作为系统组件的更新形式安装的，比如运行时框架，它们仍然会留在系统盘。判断路径是否生效，要挑一个真正独立的应用来测，别拿框架包当参照物。

4. 已经装好的应用怎么搬走

4.1 "移动"按钮出现与消失的条件

默认路径改好之后，桌面上那堆已经装在 C 盘的应用还是老样子。这时候可以走 Windows 自带的迁移功能：设置 → 应用 → 应用和功能 → 在列表里点中某个应用 → 会展开"移动"和"卸载"两个按钮，点"移动"会弹出一个对话框让你选择目标驱动器。

这个"移动"按钮不是所有应用都有。它是灰色的、或者干脆不显示的情况主要有三种：一是这个应用本身标记为不可迁移，微软的一部分系统级组件就是这种情况；二是除了系统盘之外没有其他符合条件的卷；三是应用当前正在运行，得先彻底退出再回来刷新列表。

从我的经验看，能显示"移动"按钮的应用大概占七成左右，剩下的三成只能靠卸载重装来达到目的——反正新装的会自动落到 D 盘，效果是一样的。

4.2 迁移过程的观察点与中断处理

迁移的本质是一次复制加删除操作。它会把应用目录从 C 盘完整复制到目标盘，校验通过后再把源目录删掉。这个过程有几个必须知道的点。

第一，耗时比想象中长。我搬过一个接近 8 G 的应用，整整跑了六分多钟，中途进度条几乎不动，看起来像卡死了。这是正常的，别急着点取消。

第二，迁移过程中千万不要强行关机或者休眠。如果复制到一半中断，可能出现两边各有一半文件的情况，此时应用既打不开也卸载不掉，只能靠 PowerShell 强拆包才能收拾干净：

Get-AppxPackage -Name "包名" | Remove-AppxPackage -AllUsers

第三，如果系统盘和目标盘是同一块物理硬盘的不同分区，迁移的读写会互相争抢带宽，速度会比跨物理硬盘慢不少。有条件的话，把应用搬到另一块物理硬盘上，既省时间，又能真正分摊 I/O 压力。

4.3 搬不动的应用该放弃还是硬拆

对于那些"移动"按钮灰掉的应用，我的建议是不要试图用第三方工具强拆。有一部分应用跟系统服务、Shell 扩展、文件关联绑得很深，硬挪目录之后可能表现为右键菜单里少了一项，或者资源管理器偶尔报错，排查起来非常费劲。

正确的做法是先记下它占多大空间，如果只有几十兆，就让它待在系统盘上，没必要为这点空间折腾；如果是几百兆到几个 G 的大块头，直接卸载然后重新从 Store 安装，让它落到新路径上。卸载前记得导出应用内的配置和数据，尤其是在做笔记、记账、剪贴板历史这类会存数据的应用，用户数据在AppData\Local\Packages下面对应的目录里，稳妥的做法是在应用内找"导出"功能，而不是手动去拷沙箱目录。

5. 进阶方案：手工接管 WindowsApps 目录

5.1 什么时候需要走这条路

官方图形界面能满足绝大多数人的需求，但有几种情况它搞不定：一是下拉框里死活看不到你的目标盘；二是企业环境里用了定制的系统镜像，某些设置项被组策略屏蔽了；三是你想在系统封装阶段就把路径固定好，让这个设置随镜像一起分发。

这时候就得手工写注册表。但手工方案有个前提必须强调：注册表和目录权限必须同时改，只改注册表一定出问题。这是我见过最多的失败案例——只写了PackageRoot就重启，结果装上的应用全部提示"此应用无法打开"，因为目标目录的 ACL 里缺少ALL APPLICATION PACKAGES的读取权限，应用的沙箱进程访问不了自己的文件。

5.2 目录准备与显隐设置

第一步是在目标盘根目录创建WindowsApps文件夹。这一步看起来简单，但有个坑：用资源管理器右键新建的文件夹，会继承 D 盘根目录的权限（通常只有 SYSTEM、Administrators 和当前用户的完全控制），不具备 Store 应用运行所需的条目。所以创建完之后必须重配权限。

先把隐藏文件显示出来，方便确认目录状态：在资源管理器里点"查看"选项卡，勾选"隐藏的项目"，如果还是不显示WindowsApps，就得去"文件夹选项"里去掉"隐藏受保护的操作系统文件"的勾选。

5.3 用 icacls 把权限配齐

以下命令都要在管理员权限的命令提示符或 PowerShell 里执行。我把每一步的意图写清楚，方便你理解为什么这么写。

:: 1. 把目录所有者设为 Administrators，否则后面授权会被拒绝 takeown /f "D:\WindowsApps" /a :: 2. 给 SYSTEM 完全控制（应用部署服务以 SYSTEM 身份运行） icacls "D:\WindowsApps" /grant "SYSTEM:(OI)(CI)F" /T :: 3. 给管理员组完全控制（方便后续维护） icacls "D:\WindowsApps" /grant "Administrators:(OI)(CI)F" /T :: 4. 给普通用户读取和执行权限 icacls "D:\WindowsApps" /grant "Users:(OI)(CI)RX" /T :: 5. 给所有应用包读取和执行权限（这一步是应用能不能启动的关键） icacls "D:\WindowsApps" /grant "*S-1-15-2-1:(OI)(CI)RX" /T :: 6. 给所有受限应用包读取和执行权限 icacls "D:\WindowsApps" /grant "*S-1-15-2-2:(OI)(CI)RX" /T

第 5、6 步里的那两个S-1-15-2-1和S-1-15-2-2是应用包账户的安全标识符，界面上看不到对应的名称，必须用 SID 字符串来写。漏掉这两条，应用能装上但打不开，报的错通常是拒绝访问类的。

如果你觉得手敲六条命令太麻烦，还有个更省事的思路：直接把系统盘上那个已经配好的目录权限整份复制过来。在管理员 PowerShell 里执行：

$acl = Get-Acl "C:\Program Files\WindowsApps" $acl | Set-Acl "D:\WindowsApps"

这个做法的好处是省心，坏处是它只复制访问控制条目，不复制所有者。所以第 1 步的takeown还是要单独跑一次。我个人更推荐这个组合：先takeown，再用 PowerShell 拷 ACL，最后手工补上 SID 那两条，稳。

5.4 写入注册表并重启验证

权限配完之后再写注册表：

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx" ` -Name "PackageRoot" -Value "D:\WindowsApps" -Type ExpandString

写完必须重启。不要试图只重启某个服务，应用部署服务（AppXSvc）和客户端许可服务（ClipSVC）都是受保护的按需启动服务，手工停止往往会被系统拒绝，重启是最干净的办法。

重启之后用第 3.3 节那行 PowerShell 验证：装一个测试应用，看它有没有落到 D 盘。同时还要验证老应用能不能正常打开，随便点开两三个原本装在 C 盘的 Store 应用试试。如果老应用打不开了，说明权限配置过程中动了不该动的东西，走下面的回滚。

5.5 出问题时的回滚路径

回滚其实很简单，把注册表值改回默认就行：

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx" ` -Name "PackageRoot" -Value "C:\Program Files\WindowsApps" -Type ExpandString

改完重启，系统会重新使用系统盘的目录。那些已经装到 D 盘上的应用可能需要在设置里重新"移动"回 C 盘，或者直接卸载重装。如果连设置界面都打不开了，那就是更严重的问题，通常在安全模式或者带命令提示符的恢复环境里执行这条注册表修改还能救回来。

注意：整个过程中，绝对不要用资源管理器去删除C:\Program Files\WindowsApps。这个目录里除了 Store 应用，还混着一批系统内置应用和运行时框架，删错了会导致开始菜单、搜索、设置这些基础功能一起出问题。清理空间请走"应用和功能"里的正常卸载流程。

6. 常见问题排查速查表与周边需求

6.1 盘选不中的排查顺序

下拉框里找不到目标盘是问得最多的一个问题。按下面的顺序挨个排，基本都能定位到原因：

还有一个隐藏原因：如果这块盘在磁盘管理里是"脱机"状态，或者在"存储空间"里被做成了存储池成员，它也不会出现在下拉框里。这种情况需要在磁盘管理里把它重新联机。

6.2 安装报错码对照表

改完路径之后再装应用，报错信息跟平时不太一样，下面这几个是我实际遇到过的：

看到 0x80070005 的时候，九成以上是第 5.3 节里那两个 SID 权限没配对。这时候不用重装系统，把命令补上再重启就恢复了。

6.3 Store 本身损坏的修复与重装

有时候问题不在路径上，而是 Store 应用本身已经坏了，表现是打开闪退、一直转圈、或者更新报 0x80080005。这种情况按下面的顺序处理。

第一步清缓存，按 Win+R 输入wsreset回车，会弹出一个空白的命令行窗口，几十秒后自动关闭并打开 Store。这个操作会把 Store 的本地缓存清空，不影响已安装的应用。

第二步重注册 Store：

Get-AppxPackage -AllUsers Microsoft.WindowsStore | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" -ErrorAction SilentlyContinue }

第三步查系统文件完整性，这两条命令跑完大概十分钟，别中途打断：

DISM /Online /Cleanup-Image /RestoreHealth sfc /scannow

三步都走完还是不行的话，那就属于系统镜像本身的损伤了。这时候重装 Store 比修它的成本低得多，直接从另一台正常的机器上找到 Store 的安装包路径复制过来，用Add-AppxPackage装回去即可。

6.4 顺带把 WSL2 的默认路径也挪一挪

用 Store 装的东西里，体积最凶的其实不是普通应用，而是 WSL2 的发行版。Ubuntu、Debian 这些装完之后，虚拟磁盘文件默认在%LOCALAPPDATA%\Packages\下面，动辄十几个 G，而且会随着使用不断增长，属于系统盘的头号杀手。

它跟 Store 应用的路径机制是两套逻辑，改 Store 的PackageRoot管不到它。想挪的话得导出再导入，思路是先把发行版导出成一个压缩包，注销掉原实例，再指定新位置导入：

wsl --shutdown wsl --export Ubuntu D:\wsl\ubuntu-backup.tar wsl --unregister Ubuntu wsl --import Ubuntu D:\wsl\Ubuntu D:\wsl\ubuntu-backup.tar --version 2

导入完之后默认用户会变成 root，需要去/etc/wsl.conf里补一段配置把默认用户改回来，否则每次进去都是 root 身份。这套流程跟改 Store 路径是同一个思路：先搞清楚数据到底落在哪个目录，再想办法把落点挪走。

6.5 关于导出的两个实测心得

最后分享两个我在做这类迁移时总结出来的经验。

一个是关于磁盘空间的预期管理。改完路径之后，建议隔一周再去看一次 C 盘的占用变化，用工具对比前后两次数值。我自己的机器上，第一个月 C 盘只释放了 27 G，第二个月变成了 33 G，原因是有些应用在启动之后才慢慢把缓存从系统盘迁移过去，这个过程不是瞬时的。

另一个是关于盘符的长期规划。如果你有多块盘，建议在装机阶段就规划好用途，把系统盘只留给系统和必须装在系统盘上的东西，把应用、数据、缓存分别放到不同盘上。后续再想调整，成本会高得多——光是搬应用加上等待，一台机器折腾小半天很正常。我现在的做法是给每块盘起一个有含义的标签，比如"系统"、"应用"、"资料"，盘符和标签一起用，半年之后打开磁盘管理一眼就能看清谁是谁，比盯着"本地磁盘(D:)"猜要舒服得多。