从VHDX到Windows原生启动：系统文件化备份与部署全攻略

如果你经常帮人装系统，或者自己就是个喜欢折腾 Windows 的人，应该体会过这种纠结：系统用上两三个月就开始卡，C 盘空间莫名变少，想重装又舍不得配置和软件，想备份又嫌镜像太大。后来我把思路转到 VHDX 上——把整个 Windows 装进一个虚拟磁盘文件里，备份就是复制文件，切换系统就是改个引导项，折腾崩了最多删掉它重来一次。这个方案听起来像玩具，实际上从 Windows 8 开始微软就原生支持从 VHDX 引导启动，企业里批量部署测试环境也经常这么干。这篇文章就把我从零搭建、优化、排错的全过程写出来：怎么用 WIM 镜像往 VHDX 里灌注系统，NTFS 压缩到底能不能开、应该怎么开，以及如何让 VHDX 里的系统启动更快。适合给位想搞多重系统、想做系统文件化备份、或者纯想给旧电脑续命的人参考。

1. VHDX到底解决什么问题：先分清三种玩法

很多人一听到 VHDX 就默认它是 Hyper-V 虚拟机的磁盘，这个理解没错，但格局小了。VHDX 是微软在 Windows Server 2012 / Windows 8 时代推出的第二代虚拟磁盘格式，相比老 VHD 最大的变化是：单卷上限从 2TB 提升到 64TB、原生支持 4K 逻辑扇区、带元数据日志防止异常断电导致整体损坏，还提供了更灵活的在线扩容机制。这些特性让它在虚拟化之外，也成了物理机上跑多系统的优雅方案。

实际使用场景我归纳成三种，对应完全不同的玩法：

场景一：虚拟机磁盘。 这是最常规的用法。Hyper-V 虚拟机默认采用 VHDX 作为磁盘，动态扩展、固定大小、差分盘都支持。如果你在 Hyper-V 里跑测试环境，VHDX 比 VHD 稳得多，尤其是断电崩溃后的恢复能力。

场景二：Native Boot，原生启动。 这是隐藏最深的玩法。Windows 引导管理器（BOOTMGR）能直接挂载一个 VHDX 文件，然后像从物理磁盘一样从它启动操作系统。也就是说，你硬盘上某个文件夹里放着一个 vhdx 文件，重启后它就是一个独立的 Windows 系统。使用体验和装在物理分区里几乎没有差别，但整个系统被封装在单个文件里，迁移、备份、还原都变成了文件操作。

场景三：系统文件化备份。 既然 VHDX 是一个文件，那完整系统备份就可以退化为"复制文件"。你可以在任意机器上挂载 VHDX 文件，浏览、修改里面的文件；甚至可以离线往镜像里注入驱动、打补丁，再卸载。这种"文件即系统"的方案在做系统迁移、硬件更换、批量装机时非常高效。

提示：Native Boot 不是所有 Windows 版本都支持，Windows 8/10/11 专业版、企业版、教育版都没问题，家庭版对 VHDX 原生的支持相对受限，动手前先确认版本。

选择 VHDX 而不是直接分区装系统，核心理由有两个。第一是"隔离"：所有系统文件都在一个文件里，物理分区表不会被折腾得乱七八糟，你原来电脑上的 Linux 引导、恢复分区、数据分区全部不受影响。第二是"可维护性"：想修改系统内部，可以直接挂载 VHDX 然后用 DISM 离线操作，不需要进系统；想给多台机器部署，把同一个 VHDX 文件分发过去再改引导即可。

不过原生启动 VHDX 有一个关键注意点：如果要在 VHDX 上运行 Windows，微软官方推荐使用固定大小类型，而不是动态扩展。原因是固定大小不会遇到"逻辑上空间足够但物理上尚未分配，启动过程中边请求边分配"的卡顿问题。后面我会展开讲为什么这个细节对启动速度至关重要。

2. WIM部署VHDX：从镜像到能开机的系统

既然要把系统装进 VHDX，第一步就得解决"系统镜像怎么进去"的问题。这里最规范的方式就是 WIM + DISM，不是用第三方工具解压，也不是直接复制文件。

2.1 WIM镜像的来源与准备

WIM 是微软的镜像封装格式，和 GHOST 那种扇区级克隆完全不一样：它是文件级镜像，同一个文件只在镜像中保存一份，所以体积控制得很好，而且一个 WIM 文件里可以包含多个系统索引（比如 Windows 11 家庭版、专业版、企业版都在同一个 install.wim 里）。

获取 WIM 镜像有两条路。最省事的路是从微软官方 ISO 里提取：挂载 ISO，到 sources 目录下找到 install.wim（部分新版本是 install.esd，内部结构一样）。第二条路是自己捕获，适合有自定义装机需求的人：在模板机装好系统、装完软件、Sysprep 之后，进入 WinPE 环境用 Dism /Capture-Image 把当前 C 盘打包成 WIM。捕获命令大概是：

bash复制Dism /Capture-Image /ImageFile:D:\custom.wim /CaptureDir:C:\ /Name:"MyWin11" /Description:"Custom image" /Compress:max

拿到镜像后不要急着部署，先看索引信息。注意 /Index 对应的是哪个版本，不同版本的 install.wim 索引序号不一样。查看命令：

bash复制Dism /Get-WimInfo /WimFile:D:\sources\install.wim

返回结果里会列出每个索引的版本名称、架构、大小，比如 Index: 1 名称: Windows 11 专业版。记住你要部署的那个索引号。

注意：install.esd 是更高压缩率的镜像，很多新 ISO 里已经没有 install.wim 了。ESD 同样可以用 DISM 应用，但如果你需要的是 WIM 格式（比如要离线编辑镜像、要用 7-Zip 查看内容），可以用 Dism /Export-Image 把 ESD 转成 WIM。转换后体积会变大，但兼容性更好。

2.2 diskpart创建VHDX

WIM 准备好了，接下来创建 VHDX。这里我强烈建议直接用 diskpart 脚本化操作，比图形界面可靠，也方便记录下来复现。以创建一个 100GB 的固定大小 VHDX 为例：

bash复制diskpart
create vdisk file=C:\vhdx\win11.vhdx maximum=102400 type=fixed
select vdisk file=C:\vhdx\win11.vhdx
attach vdisk
create partition primary
format fs=ntfs quick label="Windows"
assign letter=V
detach vdisk
exit

解释几个参数：maximum=102400 单位是 MB，正好 100GB；type=fixed 代表固定大小，如果希望先不占满物理空间，可以改成 type=expandable，但基于前面说的原生启动建议，最终系统盘还是转成固定大小更好。执行 attach vdisk 之后，系统里就会出现一块"虚拟硬盘"，然后创建主分区、格式化、分配盘符，完成后建议先 detach 再开始应用镜像，避免盘符冲突。

还有一点容易忽略：diskpart 在创建 VHDX 分区时默认会对齐到 1MB 边界，这符合 4K 扇区的对齐要求，所以不需要手动指定 offset。很多老教程还在教手动分区的偏移量，在 UEFI + 新系统下反而是多此一举。

2.3 用DISM应用WIM镜像

VHDX 分区创建好后，再次 attach，然后就可以把 WIM 里的系统"灌"进去。这里我特别强调：应用 WIM 必须使用 DISM 的 Apply-Image 命令，不要手动解压 WIM 文件到目标盘。WIM 里的文件包含 NTFS 安全描述符、硬链接、压缩流等元数据，普通解压会把它们全丢掉，装出来的系统大概率无法启动。

命令如下：

bash复制Dism /Apply-Image /ImageFile:D:\sources\install.wim /ApplyDir:V:\ /Index:1 /CheckIntegrity

其中 /Index:1 要和你之前在 Get-WimInfo 里看到的索引号对应，/CheckIntegrity 是可选参数，加上它会花更长时间校验数据一致性，但能提前暴露镜像损坏问题，值得第一次部署时用一次。应用过程会显示进度条，不同磁盘速度差异很大，机械盘可能需要十几分钟到半小时，NVMe 固态几分钟就能完成。

2.4 引导修复与首次启动

到这里 VHDX 里已经有了一套完整的 Windows 文件，但它还不能启动，因为引导管理器不知道它的存在。需要在当前系统的引导分区（通常是 EFI 系统分区）里写入指向 VHDX 的启动项。步骤如下：先把 VHDX attach（如果还没 attach），给它分配盘符，假设是 V，再确认 EFI 分区的盘符，假设是 S，然后执行：

bash复制bcdboot V:\Windows /s S: /f UEFI

这是 UEFI 启动机的写法，BIOS 传统引导则用 bcdboot V:\Windows /s S: /f BIOS。执行完毕后重启，在引导菜单里就能看到新系统。第一次从 VHDX 启动会比较慢，因为 Windows 要初始化虚拟磁盘、安装基础驱动，别急着判断失败，给它两三分钟。

经验之谈：如果重启后引导菜单里没有新选项，别去依赖什么修复工具。直接在 WinPE 环境里重新跑一次 bcdboot，百分之八九十的问题是盘符指定错了或者 detach 时机不对。另外，如果你原来的系统是 UEFI 引导，新 VHDX 系统也是 UEFI，不要混用 BIOS 和 UEFI 的 bcdboot 参数，否则会出现"找不到启动设备"之类的诡异现象。

3. "wim包含无效的压缩数据"：一次完整排查记录

我在不少论坛帖子里看到"wim 包含无效的压缩数据"这个报错，几乎每个用 WIM 部署的人都可能撞上。这个错误字面描述很清楚：DISM 在解压 WIM 内部某个压缩块时，读出来的数据 CRC 校验不过。但背后的根因往往不是一句话能说清的，我把自己踩坑和排查的过程完整记录一下，你以后遇到可以直接按这条链路走。

3.1 报错出现的位置和特征

这个报错一般出现在 Dism /Apply-Image 执行到一半的时候，可能进度停在 60%、70%，然后直接抛错退出。也可能是 Dism /Get-WimInfo 读取镜像信息时就报。不同阶段报错对应的原因侧重点不一样：读信息就报，大概率是文件拷贝不完整或者文件系统层损坏；应用一半才报，可能是磁盘坏道、内存不稳定，也可能是 DISM 解压到某个文件时才触发了数据错误。

3.2 逐层排查链路

我的排查顺序是这样的，从最廉价的检查开始，逐步深入：

第一步，核对文件大小和哈希。 WIM 是超 4GB 的大文件，最常见的问题是 U 盘是 FAT32 格式，复制时超过 4GB 的部分被截断或失败。先看文件大小和源文件是否完全一致，再看 SHA256 哈希。在 PowerShell 里执行：

powershell复制Get-FileHash D:\sources\install.wim -Algorithm SHA256

拿这个值和官方/原下载页面的哈希比对。如果对不上，不用想了，重新拷贝一份，并确认目标分区是 NTFS 或 exFAT，不是 FAT32。

第二步，检查磁盘错误。 如果哈希没问题，那可能是 U 盘或目标磁盘有坏道导致的读取错误。可以先复制镜像到本地 NTFS 分区再应用，排除移动介质不稳定因素。再用 chkdsk /f 检查目标磁盘，清理坏道问题。

第三步，换干净环境重试。 我遇到过一次报错，根源是杀毒软件实时扫描在 DISM 写文件时锁住了部分数据，导致解压出来的文件不完整。最简单的办法是直接进 WinPE 环境执行 Apply-Image，这个环境没有任何第三方驱动和杀软干扰，也可以排除当前系统权限不足的问题。WinPE 里注意先加载对应磁盘驱动，否则可能看不到硬盘。

第四步，加 /CheckIntegrity 再跑一次。 这一步可以让 DISM 在应用前先整体校验 WIM 完整性，它会明确告诉你是"镜像文件本身损坏"还是"读写过程中出错"。如果它在前期校验阶段就报错，基本可以断定是镜像文件损坏，直接换文件；如果校验通过但在应用中途报错，那更可能是硬件/环境问题。

第五步，用 wimlib-imagex 重新导出。 如果 WIM 文件只是存在部分坏扇区，但还没彻底损坏，可以用 wimlib 这种第三方开源工具把镜像重新编码导出一次，相当于把损坏的区域排除掉。命令类似：

bash复制wimlib-imagex export D:\install.wim 1 D:\new.wim --compress=LZX

它会逐文件重新压缩生成一个新的 WIM，如果某个文件无法读取会明确报错，那么你就知道坏在哪个文件上了。导出成功后就换用 new.wim 来部署。

3.3 从源头避免这类问题

排查完之后，我给自己定了几条规矩，之后再没被这个报错卡过：

• 镜像文件永远用哈希校验后再使用，尤其从网盘/测试环境下载的 ISO。
• 拷贝大文件到 U 盘前，先确认 U 盘文件系统是 NTFS 或 exFAT，FAT32 是死路。
• 重要安装介质尽量用官方工具制作，比如 Windows 官方媒体创建工具生成的 U 盘自然规避了 FAT32 单文件限制。
• 部署环境和目标环境尽量都用 WinPE 或全新系统，减少第三方软件干扰。

4. NTFS压缩：省空间还是拖速度

VHDX 里的系统部署完成后，很多人第一反应就是：C 盘占用太大，能不能压缩？这时候就绕不开 NTFS 压缩了。这个话题在论坛里争论挺多，我的观点是：在 VHDX 这个特定场景下，NTFS 压缩值得开，但不能无脑全盘开，得搞清楚它到底压了什么、换走了什么。

4.1 NTFS压缩的底层逻辑

NTFS 压缩是文件系统层的透明压缩，不是像 Zip 那样打包成一个文件。它的核心基于 LZ 系算法，读取文件时自动解压，写入时自动压缩，对上层应用是完全透明的。压缩的基本单位是一组簇（默认 16 个簇，对应 64KB），也就是说，文件小于或等于这个粒度时不用额外计算，大文件则按块压缩。

在普通物理磁盘上，压缩换空间是要给 CPU 付费的。文件读出来要多一道解压流程，写下去要多一道压缩流程，因此随机 I/O 密集的操作、大型数据库、视频编辑这类任务不适合压缩。但 Windows 系统目录里的文件有很强的可压缩性，WinSxS 组件库、DriverStore 驱动缓存、SoftwareDistribution 下载缓存，这些目录里充斥着大量重复的 DLL、日志、安装包，压缩率通常能到 30% 到 50%。

4.2 在VHDX上压缩的特殊性

VHDX 的引入让"要不要压缩"这个问题变得更有意思。动态扩展的 VHDX 文件在宿主机上的实际大小，完全取决于 VHDX 内部文件实际占用了多少空间。当 NTFS 压缩把系统文件从 20GB 压到 12GB 时，VHDX 文件的物理占用也会跟着缩水，而且这种缩水是"结构性"的——不是靠后续 Compact 回收，而是从源头减少了需要分配的数据块。

但代价还在。启动时，BOOTMGR 需要从 VHDX 里读取 winload.efi、ntoskrnl.exe 等核心文件；如果这些文件被压缩了，读取过程除了 IO 还要消耗 CPU 解压。在 NVMe 固态硬盘上，读取延迟很低，解压消耗是相对明显的瓶颈，但现代 CPU 解压 64KB 块的耗时可以忽略不计，实际感知差别很小。在机械硬盘上，IO 才是主要瓶颈，压缩反而可能让读取的数据量变小，启动时间不升反降。所以不用神话压缩，也不用妖魔化它。

4.3 实操：该压缩什么不该压缩什么

先给结论：不要对整个 VHDX 分区一键全盘压缩。Windows 系统里有些文件对启动至关重要，被压缩后可能导致兼容问题，比如 winload.efi、ntkrnlmp.exe、休眠文件、页面文件。安全做法是选择性压缩目录，优先处理这几个大头：

bash复制compact /c /s:D:\Windows\WinSxS /i /q
compact /c /s:D:\Windows\System32\DriverStore /i /q
compact /c /s:D:\Windows\SoftwareDistribution\Download /i /q
compact /c /s:D:\Windows\Installer /i /q

其中 /s 表示递归处理子目录，/i 忽略出错继续执行，/q 安静模式。执行完再查一下压缩率：

bash复制compact /q D:\Windows\WinSxS

它会输出当前目录的压缩比。我实测过，WinSxS 从 8GB 左右压到 4GB 出头，DriverStore 从 1.5GB 压到 800MB，合计能省出 4-5GB，启动影响几乎感知不到。如果想撤销压缩，把 /c 换成 /u 即可。

还要提醒一个反直觉的点：不要压已经压缩过的文件。像 install.wim、*.zip、*.jpg、*.mp4 这类文件本身压缩率极低，压了白压，还浪费 CPU。上面的命令只针对系统目录，不会误伤媒体文件，所以相对安全。

如果你嫌一条条执行麻烦，可以用 Windows 自带的 CompactOS 替代全盘压缩。在管理员命令行执行：

bash复制compact /compactos:always

Windows 会智能地只压缩系统文件，并在文件上打标记，后续更新维护时系统自己也认得。相比手动全盘 NTFS 压缩，CompactOS 的兼容性好很多，官方推荐，空间收益和 NTFS 压缩基本持平。在我测试的 VHDX 环境里，CompactOS 开启后系统盘从 18GB 降到 11GB，启动时间只增加了不到 1 秒。

5. 启动提速：把VHDX的启动时间压进自己的心理预期

VHDX 系统能进桌面只是第一步，接着得解决"快不快"的问题。很多人对 VHDX 启动有先入为主的偏见，觉得"绕了一层虚拟磁盘肯定慢"。其实只要把配置做对，VHDX 启动速度和物理分区基本没有肉眼可见的差别。慢，大概率是某些细节没做对。

5.1 VHDX启动的链路分析

先拆一下从按下电源键到进桌面的链路。传统物理分区启动是：BIOS/UEFI 初始化 → BOOTMGR → winload.efi → 加载内核。VHDX 启动则在 BOOTMGR 这一步多了一个环节：BOOTMGR 先根据 BCD 里的配置找到 vhdx 文件路径，把它挂载为虚拟磁盘，然后才从虚拟磁盘里读取 winload.efi 和系统文件。这个"多挂载一次"的过程是纯软件逻辑，开销很小，真正的差异在于后面读取文件时，VHDX 的 IO 表现。

动态扩展 VHDX 之所以慢，是因为文件块在物理磁盘上不是连续排列的，BOOTMGR 读取系统文件时需要频繁跳转，机械盘尤其吃亏。固定大小 VHDX 的逻辑块位置相对稳定，IO 模式更接近物理分区。所以想提速，第一个原则就是：系统 VHDX 用固定大小。

5.2 分区对齐、碎片整理与Optimize-VHD

第二个提分点是分区对齐。虽然 diskpart 默认对齐已经解决大部分问题，但如果你用老工具或者手工分区，可能出现 VHDX 内部簇和物理扇区错位，后果就是每次读一个文件要多读一遍扇区。确认是否对齐，可以在管理员 PowerShell 里跑：

powershell复制Get-Partition -DriveLetter V | Get-Sector

观察边界是否按 4K/8K 对齐。不对齐的话，建议直接重新分区，别为省事留隐患。

第三个提分点是碎片。VHDX 用到一定时间，内部文件会碎，宿主文件也会碎。Windows 有个隐藏技能是能够识别 VHDX 并自动执行在线优化，在"优化驱动器"（Defragment and Optimize Drives）面板里能看到你的 VHDX 显示为"无法分析"还是"需要优化"。更专业的做法是用 Hyper-V 模块的 Optimize-VHD：

powershell复制Optimize-VHD -Path C:\vhdx\win11.vhdx -Mode Full

这个命令需要系统有 Hyper-V 管理模块，如果没装，也可以用 diskpart 离线 compact。Optimize-VHD 会把动态 VHDX 里已删除文件留下的空洞回收，让文件块重新紧凑排列，对启动速度提升很直接。建议在系统关机状态下执行。

另外，如果你的 VHDX 一开始建的是动态类型，系统装完、软件驱动也齐了、验证无误后，可以考虑转成固定大小：

powershell复制Convert-VHD -Path C:\vhdx\win11-dynamic.vhdx -DestinationPath C:\vhdx\win11-fixed.vhdx -VHDType Fixed

转换时要保证目标盘空间足够，完成后用新文件替换旧文件并更新 BCD 指向。这一步做完后，最直观的感受就是"启动变实了"，进度条变得更线性，不会有卡顿等待。

5.3 BCD配置与系统侧优化

启动链路上还有一些小而有效的小项，顺手就能改。第一项是 BCD 菜单超时时间，多系统用户一定深有体会——默认 30 秒空等最烦人。设置为例：

bash复制bcdedit /timeout 3

第二项是电源计划，很多笔记本默认的平衡模式会限制 CPU 频率，间接影响 VHDX 解压/加载的速度。切到高性能计划可以这样：

bash复制powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

第三项是快速启动。如果你的机器支持，开启快速启动可以减少冷启动加载内核的时间。前提是休眠功能正常，VHDX 下我测试过是可以正常工作的。在控制面板电源选项里勾选"启用快速启动"即可。注意，如果你的 VHDX 装在移动硬盘里或者经常在不同机器间迁移，不建议开，因为每次换硬件环境都可能出现驱动不匹配。

5.4 一个可以直接抄的bat优化脚本

看到不少热词里有"批处理优化游戏性能"的需求，我把自己在 VHDX 系统上常用的一套安全优化脚本分享出来，只做无害级调整，不关服务、不动防火墙，专门针对临时文件、电源、DNS 和启动等待：

bat复制@echo off
rem 需要以管理员身份运行
title Windows VHDX 启动与性能优化

rem 设置高性能电源计划
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

rem 清理当前用户临时文件
del /f /q "%TEMP%\*.*" >nul 2>&1

rem 清理系统临时文件
del /f /q "C:\Windows\Temp\*.*" >nul 2>&1

rem 刷新 DNS 缓存
ipconfig /flushdns >nul

rem 设置引导菜单等待时间 3 秒
bcdedit /timeout 3 >nul 2>&1

echo 优化完成，部分设置重启后生效。
pause

提示：脚本必须在管理员权限下运行，否则 powercfg、bcdedit 都会直接拒绝执行。不要手动关闭"服务"来提升性能，Windows 服务之间的依赖关系很隐蔽，关错一个可能导致网络、打印、安全模块各种连锁故障。使用上面这种"无害级优化"其实已经能满足大部分场景的提速需求。

6. 日常维护：让VHDX告别"只涨不缩"

VHDX 用久了你一定会遇到一个烦心事：明明在系统里删了好几个大文件，VHDX 文件在宿主机上的体积却纹丝不动。这是动态 VHDX 的机制决定的，删除文件释放的空间会被 VHDX 内部标记为"空闲块"，但宿主文件不会自动收缩。如果不主动做空间回收，一个原本 40GB 的 VHDX 能膨胀到 80GB，非常尴尬。

6.1 空间回收的思路

先理清回收链路：系统内删除文件 → NTFS 把空间标记为空闲 → VHDX 内部出现空闲块 → 需要把空闲块的信息告诉宿主机或物理磁盘。前面两个环节自动完成，后面才是关键。Windows 对 VHDX 的 Trim 支持是有的，在"优化驱动器"里运行一次"优化"就能让 SSD 上的 VHDX 瘦下来。但如果你的宿主机是 HDD，Trim 基本没有用，需要显式执行 compact。

6.2 Compact的三种方式

我常用的有这三种，按使用环境不同选一种：

方式一：Hyper-V 管理器图形界面。 打开 Hyper-V 管理器 → 右键虚拟机 → 编辑磁盘 → 选择"压缩"，按向导走即可。注意，虚拟机必须处于关机状态，否则磁盘文件被进程占用无法编辑。

方式二：diskpart 命令。 不用装 Hyper-V 端也能做，离线状态下（目标 VHDX 没有挂载到运行中的系统）执行：

bash复制diskpart
select vdisk file=C:\vhdx\win11.vhdx
attach vdisk readonly
compact vdisk
detach vdisk
exit

attach vdisk readonly 这种做法是挂载只读，避免在压缩过程中有任何写入导致文件不一致。压缩速度取决于 VHDX 文件大小和空闲块比例，可能需要几分钟到十几分钟，中间不要强行中断。

方式三：PowerShell 的 Optimize-VHD。 前文提过，适合已经装了 Hyper-V 模块的机器：

powershell复制Optimize-VHD -Path C:\vhdx\win11.vhdx -Mode Full

它比 diskpart compact 更智能，在压缩的同时还能整理内部文件布局，效果更好。

6.3 别让差分盘毁掉你的系统

还有一个维护大坑是差分盘。VHDX 支持父盘+子盘的差分结构，子盘记录所有变化，父盘保持只读。这种机制在创建快照、测试环境时非常方便，但很多人用了差分盘之后忘了这回事，结果父盘被误删、子盘无法启动，或者子盘膨胀到比父盘还大。

我的建议是：VHDX 原生启动系统绝对不要长期依赖差分盘。差分盘一旦作为主系统运行，性能会有持续损耗，因为每次读文件都要先查子盘，再回溯父盘。如果你只是想要快照功能，更稳妥的做法是直接复制 VHDX 文件作为备份，或者使用 Windows 系统还原点。复制整个 vhdx 文件比差分盘操作直观多了，也不会产生依赖链。

6.4 WSL使用的ext4.vhdx顺带一提

说到 VHDX 维护，有个很多人忽略的隐藏点：WSL 2 的发行版磁盘文件其实也是一个 VHDX，默认位置在 %LOCALAPPDATA%\Packages\...\LocalState\ext4.vhdx。WSL 用久了也会出现磁盘只涨不缩的问题。处理方法是先运行 wsl --shutdown 关闭所有 WSL 进程，然后用 Optimize-VHD 路径指到那个 ext4.vhdx 上压缩。如果你遇到 WSL 提示"系统找不到指定的文件"这种诡异报错，先检查路径有没有被移动或改过，再用 wsl --import 方式重新挂载一遍，多半能救回来。

我在实际维护中发现，定期执行"系统内磁盘清理 + 手动 compact"可以让 VHDX 一年下来瘦 20% 到 40%。这个步骤和 VHDX 的压缩、部署一样重要，算是真正用顺手的必修课。

折腾 VHDX 这么多年，我最大的体会是：这套方案不是用来替代虚拟机的，它是给"想在物理机上同时维护多个 Windows 环境、又不想反复折腾分区和引导"的人准备的。它最迷人的地方在于，装好的系统是一个文件，而文件是可以随意复制、归档、分发、挂载的东西。第一次尝试的人，我建议先建一个 40GB 的固定 VHDX，完整走一遍部署流程，确认启动没问题后，再去做 NTFS 压缩和启动优化。这中间每一步都有坑，但这些坑踩完之后，你对 Windows 引导链、文件系统、虚拟磁盘的理解都会深一大截，后面无论用 Hyper-V、WSL 还是部署工具，都会顺手很多。