简介：这份资源是为Windows系统管理员、技术支持人员和需要深度维护系统映像的用户准备的Dism工具组件包。包内包含Dism 10.1.2002.101.b版本可执行程序及配套组件，可用于添加或删除Windows映像功能、清理组件存储、准备Windows PE环境以及修复损坏映像。压缩包共44个文件，约32.46MB，主要以x86/x64/ARM64位的exe、14个dll动态库、2个sys驱动及19个zip压缩模块为主，另有ini配置文件、cab更新包和log日志，便于识别与按需调用。已有576人学习下载。通过该包可直接使用图形化维护界面执行系统空间释放与映像健康检查；Plugins、UpdateInfoBeta.zip、default.ui.zip等内容可支撑离线更新、组件管理和多语言界面切换，适合在不使用完整安装介质的情况下，对Windows映像或运行中系统进行精细化服务与故障恢复的中高级用户。
1. Dism-v10.1.2002.101.b.zip：这个维护工具包，解决的是系统层面最麻烦的那几件事
电脑突然进不了桌面、C 盘空间被莫名吃满、要给一批机器装系统却发现驱动和补丁要一个个点——这些场景每一个都够让人头疼的。而 Dism-v10.1.2002.101.b.zip 这个发布包，本质上就是 Windows 自带的部署映像服务和管理工具（DISM）的特定版本分发。它能在命令行里完成系统备份、镜像健康修复、离线集成驱动与补丁这些操作，不需要装第三方软件，也不需要进到正常桌面。对运维人员和喜欢自己研究系统的开发者来说，学会这套命令，等于把系统维护从“出了问题就重装”升级成“可复现、可预判的工程操作”。这篇文章我会按平时处理真实问题时的顺序，把 DISM 的用法、参数细节和踩过的坑一次讲清楚，新手能照着敲，熟手也能在某些边界问题上有个参照。
2. 搞懂 DISM 的两条操作路径：/Online 与 /Image 各管什么
2.1 为什么系统维护优先选 DISM：第三方备份工具做不到的三件事
我见过很多人在系统崩溃后第一反应是找 Ghost、找某某一键还原，这类工具确实有它的便利性，但有两个问题：一是它们的镜像格式不透明，备份出来的东西你很难在别的环境下操作；二是它们只解决“备份和恢复”这一个点，系统坏了之后连源文件都识别不了的时候，想要修复损坏的组件、集成某个补丁，第三方工具基本做不到。
DISM 的价值在于它是系统自带的能力，不依赖第三方运行时，而且它支持的三大类操作恰好覆盖了系统维护的完整闭环：健康修复（/Cleanup-Image）、映像备份与恢复（/Capture-Image、/Apply-Image）、离线定制（/Add-Driver、/Add-Package）。
还有一个关键点：DISM 支持离线操作。也就是说，哪怕系统已经完全起不来了，你用一个 PE 启动盘进入命令行环境，照样可以加载镜像、修复系统、备份分区。这种“不带病工作”的特性，是很多 GUI 工具给不了的安全边界。所以我个人的习惯是：凡是要动系统底层、要做批量部署，优先用 DISM，而不是依赖某个厂商的备份软件。
2.2 /Online 路径：对着正在运行的系统做健康修复
/Online 表示操作对象是“当前正在运行的这个 Windows 系统”。常见的场景包括：系统更新失败后组件存储损坏、开机变慢、疑似文件被篡改。此时我会先用一条命令做健康扫描：
Dism /Online /Cleanup-Image /ScanHealth这条命令会把当前系统的组件存储（Component Store）和系统文件与已知的良好状态做比对，判断是否存在损坏。扫描结果会写进日志，路径默认为C:\Windows\Logs\DISM\dism.log。如果扫描发现“可修复”的损坏，紧接着执行：
Dism /Online /Cleanup-Image /RestoreHealthRestoreHealth 会在联网情况下从 Windows Update 拉取健康文件来修复损坏组件。很多人忽略的是，这条命令也可以指定本地源，比如你有一个完整的安装镜像，可以这样写：
Dism /Online /Cleanup-Image /RestoreHealth /Source:WIM:E:\sources\install.wim:1 /LimitAccess这里的/Source参数指向 WIM 文件，冒号后的数字表示索引号；/LimitAccess表示限制 DISM 只访问指定的源，不去联网。这个参数组合在离线环境里非常有用，也是我在给一些内网机器做维护时的标准做法。
日常巡检时，我一般还会搭配sfc /scannow。它俩的分工是：DISM 负责修复组件存储本身，SFC 负责检查并修复系统文件。顺序上，先跑 DISM 再跑 SFC，这样系统文件校验时才有完整的源可用。
2.3 /Image 路径：挂载镜像才能做离线手术
/Online 只能处理正在运行的系统，但如果你手里是一个 WIM/ESD 镜像文件，比如安装镜像install.wim，那就得用 /Image 路径。核心流程是三步：挂载、操作、卸载提交。
mkdir C:\MountDir Dism /Mount-Image /ImageFile:D:\sources\install.wim /Index:1 /MountDir:C:\MountDir /ReadOnly挂载的意思是把这个 WIM 里的内容解出来映射到一个空目录，你可以直接对这个目录里的文件做增删改。加上/ReadOnly参数后，挂载出来的目录是只读的，适合只想查看或提取文件的情况；如果要往镜像里集成驱动和补丁，就不要加这个参数。
操作完成后必须执行卸载，否则挂载目录会一直占着资源，而且镜像文件可能被锁：
Dism /Unmount-Image /MountDir:C:\MountDir /Commit/Commit 表示把挂载期间做的所有更改写回 WIM 文件。如果操作过程中发现改坏了，想放弃所有更改，可以用/Discard。这条命令我建议每个新手都背下来，因为很多“WIM 被占用”的问题，都是挂载后忘了卸载导致的。
2.4 高频命令的语法速查：先把参数结构看懂
DISM 的命令结构统一是“命令 + 对象 + 参数”。我最常用到的几个命令，参数拆解如下：
Dism /Capture-Image /ImageFile:D:\backup\system.wim /CaptureDir:C:\ /Name:"MySystem-2025"/CaptureDir指定要捕获的分区或目录，/ImageFile 指定备份输出的 WIM 路径，/Name 是这个镜像索引的显示名称，必填。这条命令会把 C 盘整个打包成一个 WIM，第一次备份建议再加一个/Compress:fast，能明显减少备份时间。
Dism /Apply-Image /ImageFile:D:\backup\system.wim /Index:1 /ApplyDir:C:\/ApplyDir是指要把镜像释放到哪个分区。这一步通常是在 PE 环境下执行的，目标分区需要提前格式化。还有一条查看镜像信息的命令：
Dism /Get-ImageInfo /ImageFile:D:\backup\system.wim它会列出这个 WIM 里包含的所有索引、每个索引的名称、大小、创建时间、适用架构。这个习惯很好，每次拿到陌生镜像先看一眼信息，能避免很多因架构不匹配导致的低级错误。
这些命令的参数看着多，但核心逻辑就一句话：DISM 不谈“分区对分区”的裸拷贝，它操作的是有索引、有校验的映像文件。理解了这一点，后面遇到的绝大多数问题都能顺着这个逻辑找到原因。
3. 系统镜像备份与恢复：用 /Capture-Image 做出你自己的整机还原点
3.1 备份前的三件准备：空间、分区识别、启动介质
备份不是敲一条命令那么简单。我吃过一次亏：C 盘用了 80GB，直接往 D 盘备份，结果 D 盘剩余空间不够，命令跑到一半报错，镜像文件还残留了半个。所以我现在每次备份前都会先确认三个事情。
第一，目标磁盘的剩余空间要比源盘已用空间大至少 1.5 倍。因为 WIM 虽然做了压缩，但压缩率取决于里面文件的类型，视频、安装包多的系统，压缩效果就差，空间留少了就是给自己找麻烦。
第二，要确认你要备份的盘符，在 PE 环境下和在正常系统环境下可能不一样。我用过很多次 PE，每次进去第一件事就是打开命令提示符，敲diskpart然后list volume，确认哪个卷是原系统盘，而不是凭记忆直接敲C:。
第三，准备好启动介质。不管是用 Windows 安装U盘还是自定义 PE，备份本身在正常系统里也能跑，但恢复操作强烈建议在 PE 或 Windows RE 里做，因为系统盘正在被占用时无法被完整覆盖写入。Windows RE 的进入方式很简单：设置 → 系统 → 恢复 → 高级启动，或者开机时连续三次强制断电，也能触发自动修复模式。
3.2 捕获系统分区：/Capture-Image 完整参数与脚本
下面是我常用的备份命令，注意先确认卷路径再执行：
rem 进入 PE 后先确认分区状态 diskpart list volume exit rem 备份系统分区到指定位置 Dism /Capture-Image /ImageFile:D:\Backup\Win10_Backup.wim /CaptureDir:C:\ /Name:"Workstation-2025-06" /Description:"Daily backup after patch update" /Compress:fast /CheckIntegrity/CaptureDir根目录就是被捕获分区的根，C:\ 会被处理成整个 C 分区的内容。/Name 必须填写，否则命令直接报错；/Description 可选，但我建议写上日期和备份原因，不然过两个月你看着一堆 /Name 一样的镜像根本分不清哪个新哪个旧。/Compress:fast 是速度和体积的折中，如果是给客户做最终交付镜像，我会改用 /Compress:max 压得更小；/CheckIntegrity 会在写入过程中校验文件完整性，牺牲一点时间，换一个“这镜像能用”的确定性，值。
备份完成后，我习惯顺手跑一条：
Dism /Get-ImageInfo /ImageFile:D:\Backup\Win10_Backup.wim确认索引数量和名称没问题，再关命令窗口。备份文件生成后不要直接扔在那里就不管了，我见过有人备份了半年，想恢复的时候发现 WIM 文件损坏，原因就是备份介质有坏道。所以备份完，拷贝到第二个位置再校验一次，多花十分钟，省得后面崩溃。
3.3 恢复系统的两种方式：WinRE 命令与 PE 下的完整流程
恢复系统时，如果系统还能进高级启动，就用 WinRE 里的命令提示符；如果完全黑屏，就进 PE。流程是我经过多次验证的稳定路径，以 PE 为例：
rem 1. 格式化目标分区 format C: /fs:NTFS /q rem 2. 释放镜像 Dism /Apply-Image /ImageFile:D:\Backup\Win10_Backup.wim /Index:1 /ApplyDir:C:\ rem 3. 重建启动引导 bcdboot C:\Windows /s C: /f ALLformat是为了保证干净的分区环境，如果目标分区之前有过复杂的引导结构，不格式化直接释放镜像，后面启动时可能出现引导菜单错乱。bcdboot这步是新手最容易漏的：Apply-Image 只是把文件解出来，不会自动给磁盘写引导记录，不执行 bcdboot 的话，机器重启后会提示找不到操作系统。
如果恢复 Windows RE 环境，路径稍有差异，需要先找到系统分区对应的盘符，再用同样的三条命令处理。恢复完成后不要立刻拔U盘，先重启看一眼系统是否能进入桌面，能进再去处理后续驱动验证。这样万一引导坏了，还能回到 PE 里用 bcdboot 补救，不用二次折腾。
3.4 多索引与增量式备份：一个 WIM 文件装多个系统版本
WIM 格式支持在一个文件里存放多个映像索引，这给日常维护带来一个很实用的玩法：把多个时间点的备份存放在同一个 WIM 文件里，用 /Append-Image 追加索引。
Dism /Append-Image /ImageFile:D:\Backup\Win10_Backup.wim /CaptureDir:C:\ /Name:"Workstation-2025-07"这样 /ImageFile 还是原来那个文件，但它内部会多出一个索引。恢复时用/Index:2就能调到新时间点的备份。这个方式的优点是文件好管理，一个机器一个 WIM 文件搞定；缺点是文件会一直增大，而且旧索引如果不再需要，删除它需要重建整个 WIM，比较麻烦。
我的做法是：保留最近 2~3 个索引，超过的直接删掉旧文件重新捕获一次全量备份。不要试图用增量备份取代定期全量备份，WIM 格式不是文件级的增量，它是索引级的新增，做多了只会让文件膨胀到不可控，这一点在后面的避坑章节里还会再说到。
4. 离线集成驱动与补丁：把新装系统的“后处理”变成“预安装”
4.1 集成驱动：/Add-Driver 与驱动目录结构的坑
批量装机的场景里，最花时间的往往不是装系统，而是装完系统后再挨个装驱动。DISM 的离线集成功能能让你把驱动直接塞进 install.wim，这样系统第一次启动时驱动就已经就位。实际操作时，我会先把所有驱动解压到一个目录下，注意是“解压后的文件夹”，不是一堆 .exe 安装包。DISM 只能识别 .inf 驱动的展开目录。
rem 挂载镜像 Dism /Mount-Image /ImageFile:D:\ISO\sources\install.wim /Index:1 /MountDir:C:\MountDir rem 集成驱动目录，/Recurse 表示递归子目录 Dism /Image:C:\MountDir /Add-Driver /Driver:D:\Drivers\Win10_x64 /Recurse rem 确认驱动已加入 Dism /Image:C:\MountDir /Get-Drivers/Driver指向驱动根目录，/Recurse会扫描里面所有子目录，这对品牌机的驱动包特别有用，因为厂商给的驱动包通常是分层目录结构。不加 /Recurse 的话，DISM 只扫当前目录，漏掉子目录里的驱动是常事。
驱动集成这里有个容易翻车的点：有些驱动包里的 .inf 被打了第三方签名或者签名过期，DISM 默认会拒绝集成这类驱动。这时可以在 /Add-Driver 后面加上/ForceUnsigned参数强制加入，但我必须提醒：强制集成未签名驱动只适用于自己维护的测试环境，生产环境不建议用，因为 Windows 后续更新时可能因为驱动签名问题把整个系统搞出兼容性故障。
还有一个我踩过的坑：驱动目录里如果同时包含 x86 和 x64 驱动，千万别图省事把两个都放一起递归。DISM 会尝试把所有能识别的驱动都加进去，结果就是 32 位和 64 位驱动混在一个镜像里，系统安装时可能出现文件冲突。正确做法是分架构放不同目录，集成前也用dism /Get-WimInfo确认镜像的架构。
4.2 集成补丁与语言包：挂载—集成—卸载的标准流程
补丁集成比驱动简单但也更严谨。补丁文件常见格式是.msu或.cab，DISM 对这两种文件的处理方式有区别。.cab可以直接通过 /Add-Package 添加，.msu需要先解包，或者直接用 /Add-Package 指向 .msu 文件也能被识别，但实际经验告诉我，.msu 解包后以 .cab 形式集成，成功率更高，尤其是在做累积更新时会少很多奇怪的报错。
解包 .msu 的常见做法是用expand命令：
expand -F:* D:\Updates\KB5000000.msu C:\Updates\KB5000000解压后会得到几个.cab文件，其中包含Windows10.0-KB5000000-x64.cab这类命名。接下来挂载镜像并集成：
Dism /Image:C:\MountDir /Add-Package /PackagePath:C:\Updates\KB5000000\Windows10.0-KB5000000-x64.cab Dism /Image:C:\MountDir /Add-Package /PackagePath:C:\Updates\KB5000000\Windows10.0-KB5000000-x64-ssu.cab注意第二个文件是服务栈更新（Servicing Stack Update），它的集成顺序通常要排在普通累积更新之前。如果镜像本身比较旧，直接集成最新累积更新可能会因为服务栈版本太低而失败。我处理过一台基于旧版镜像做定制的机器，集成本月更新时一直报 0x800f0823，查了日志才发现是先装了补丁、没装服务栈，顺序反了。正确顺序是：服务栈更新 → 累积更新 → 其他补丁。
集成语言包用 /Add-Capability 或 /Add-Package 都可以，区别是 /Add-Capability 更适合按“功能”维度添加，比如.Net Framework 3.5：
Dism /Image:C:\MountDir /Add-Capability /CapabilityName:NetFx3~~~~4.3 提交与清理：为什么提交前一定要做组件清理
离线操作完成后，不要直接 /Unmount /Commit。因为在挂载过程中，DISM 会产生一些临时文件和组件存储的膨胀，如果不清理，提交后的 WIM 会比原始镜像大出不少。我会在提交前加一步：
Dism /Image:C:\MountDir /Cleanup-Image /StartComponentCleanup /ResetBase/StartComponentCleanup会把被更新替代掉的旧组件清理掉；/ResetBase则会把组件存储里的“可卸载”标记全部清掉，让当前所有已安装组件变成基线。这样生成的镜像体积最小。需要注意，加了 ResetBase 的镜像，之后想卸载集成进去的补丁就做不到了，所以这一招只适合做“最终交付镜像”时使用。
清理完成后再卸载提交：
Dism /Unmount-Image /MountDir:C:\MountDir /Commit提交完成后再用 /Get-ImageInfo 看一下新镜像的索引信息，确认整体大小变化符合预期。如果发现镜像体积只增不减，那大概率是挂载目录里残留了临时文件，或者驱动目录里塞了一些没必要的文件。镜像定制这事儿，过程越干净，结果越可控。
5. 避坑指南：DISM 操作中我反复踩过的 5 类坑
5.1 错误 0x800f081f：找不到源文件，别急着重新下载镜像
这个错误在 /RestoreHealth 和 /Add-Package 时都可能出现，现象就是命令跑了几秒就退出，提示“无法找到源文件”。我第一次遇到时以为系统已经坏透了，差点直接重装。后来查日志发现，这个错误的本质是 DISM 需要从 Windows Update 或指定源获取某个组件文件，但它访问不到。
出现这个报错，常见原因有两个：一个是系统里的 Windows Update 服务被禁用或者网络受限，另一个是组件存储损坏程度较重，DISM 在标准路径下找不到匹配的源。
我的解决顺序是：先加 /Source 参数指定本机挂载的 install.wim 作为源，配合/LimitAccess禁掉联网。如果镜像版本和系统版本不完全匹配，会报 0x800f081f 的变体，这时需要用同版本或更高版本的镜像作为源。还有一些情况，系统是精简版，组件存储本身缺东西，那就要先/Cleanup-Image /ScanHealth看完整损坏清单，再做恢复。
5.2 错误 0x80070002：路径找不到还是硬链接被吃了
0x80070002 看起来像是“系统找不到指定的文件”，但在 DISM 场景下，它往往不是路径写错，而是 WIM 内部的元数据损坏，或者挂载目录权限不对。我遇到过一次：给 WIM 挂载时用的是普通管理员权限，但挂载目录设置在 C 盘根目录下，DISM 创建了挂载点却不能完整读取 WIM 索引，报了 0x80070002。
这个问题的处理分两步：第一，确认挂载目录存在且为空，路径没有特殊字符；第二，把命令提示符以管理员身份运行。我后来养成的习惯是挂载目录专门建一个，比如 C:\Mount\Wim\Work，每次都固定用它，既避免权限问题，也方便排错时排查残留挂载点。
如果确认权限和路径都没问题，仍报 0x80070002，那就是 WIM 文件本身在制作时不是完全体。比如网上某些精简版镜像，内部文件被删减，DISM 操作到某一步找不到对应文件就会随机报这个码。这种情况我基本不会再纠结，直接换原版镜像。
5.3 WIM 挂载后无法卸载：句柄占用与 /ScratchDir 的玄学
挂载目录删除不了、卸载报“另一个程序正在使用此文件”，听着很玄学，实际原因大多是你在挂载目录开着资源管理器窗口，或者有什么杀毒软件在后台扫描这个目录。坑在于：资源管理器窗口你不是故意开的，是之前看文件忘了关。
解决方式是这样，先关掉所有可能占用挂载目录的程序，再执行一次强制卸载：
Dism /Unmount-Image /MountDir:C:\MountDir /Discard注意是 /Discard，不是 /Commit。如果这一步仍提示占用，看看是不是系统里那个“Windows Modules Installer Worker”进程（TiWorker.exe）在跑，这个是 Windows 更新相关的组件维护进程，确实会在后台读取挂载目录。等它结束再卸载。
还有一个我自己踩过的深层问题：临时目录空间不足也会造成挂载后无法正常卸载，报错往往伴随 0x80070070（磁盘空间不足）。这时可以用 /ScratchDir 参数指定一个空间大的临时目录来重新挂载或执行清理：
Dism /Image:C:\MountDir /Cleanup-Image /StartComponentCleanup /ScratchDir:E:\Scratch/ScratchDir 是 DISM 比较低调但关键的参数，它控制的是 DISM 工作目录的位置，默认在系统盘。系统盘紧张的时候，显式指定到其他盘符能避免很多莫名其妙的失败。
5.4 备份镜像越来越大：索引堆叠与体积失控
用 /Append-Image 做多次备份后，WIM 文件体积会线性上涨，这不算坑，真正的坑是我发现很多人在做增量追加时，没有意识到 WIM 的压缩是“整文件级别”的，不是文件块级。也就是说，哪怕你只改了一个小文件，追加新索引时，WIM 会把这个文件所在的一组数据重新压缩存储，导致新索引并不比全量备份小多少。
这个问题没太好的解法，因为它就是格式特性。我的习惯是：每个季度做一次全量备份，只留当前季度和上季度的两个索引，更早的直接拿新备份覆盖旧文件。比如一季度末尾用 /Capture-Image 生成新 WIM，然后手动删除旧 WIM，不对同一个文件盲目追加。如果你确实需要保留多个历史时间点，用一个 WIM 多索引确实是省文件的，但心里要有数：它不是“差异备份”，体积膨胀是预期内的。
5.5 版本不匹配：工具、镜像、环境三者必须一致
DISM 版本和镜像架构不匹配会引发很多连锁问题。最典型的是 64 位镜像在 32 位 PE 环境下用 DISM 操作，命令能执行但可能在某个步骤报“系统找不到指定的路径”或“接口不支持”。
原因是：32 位 DISM 对 64 位 WIM 的某些操作需要额外的 WOW64 支持，PE 环境没这个组件就会翻车。我的原则是：操作 64 位镜像，就只用 64 位 PE；操作 32 位镜像，32 位环境也够。另外，Windows 10/11 的 DISM 版本和 Windows 7 的 DISM 版本在参数上也有些微差异，老版本不支持 /ResetBase，新版本对 /RestoreHealth 的源校验更严格。
在操作用哪个版本的 DISM 之前，习惯性地跑一下版本查看命令，比踩坑后再排查舒服得多：
Dism /Version不同版本的 DISM 在错误日志的行为上也有差异，有时同一个报错码，两个版本给出的详细日志路径都不同。日志统一看C:\Windows\Logs\DISM\dism.log，但如果是在 PE 环境下，日志会写在 X 盘对应目录，找的时候别习惯性地去 C 盘翻。
6. 把 DISM 固化成维护习惯：健康巡检与一键备份脚本
6.1 一条命令判断系统健康状况
日常维护不需要每次做全量扫描，我常用的健康判断组合很简单：
Dism /Online /Cleanup-Image /CheckHealthCheckHealth 只是快速检查组件存储有没有被标记为损坏，不深入扫描，速度很快。如果它返回“未发现损坏”，那系统状态基本健康。如果返回有损坏，再上 ScanHealth 和 RestoreHealth。这套组合的执行成本很低，我会在每次系统更新完之后顺手跑一次，也就十几秒的事。
判断完组件存储，再用Dism /Online /Get-Features看功能状态，确认有没有异常关闭的功能。这个命令在排查系统某些功能消失时很有用，比如某天打印服务突然没了，先用它确认功能还在不在，再顺着去查驱动。
6.2 批处理封装：备份、日志、校验三合一
下面是我平时赛在 U 盘里的一个批处理脚本，用来对当前系统做全量备份并自动校验。它不复杂，但省掉了每次敲参数的麻烦：
@echo off set BACKUP_DRIVE=D:\Backup set BACKUP_FILE=%BACKUP_DRIVE%\Sys_%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%.wim set LOG_FILE=%BACKUP_DRIVE%\backup_log.txt echo [%date% %time%] Backup start >> %LOG_FILE% rem 检查目标盘空间，逻辑上留一手 dir %BACKUP_DRIVE% | findstr "可用字节" >nul if errorlevel 1 ( echo [%date% %time%] ERROR: Backup drive not accessible >> %LOG_FILE% exit /b 1 ) rem 执行备份，/Compress:max 换取更小体积 Dism /Capture-Image /ImageFile:%BACKUP_FILE% /CaptureDir:C:\ /Name:"AutoBackup-%date%" /Compress:max /CheckIntegrity >> %LOG_FILE% 2>&1 rem 校验产物 Dism /Get-ImageInfo /ImageFile:%BACKUP_FILE% >> %LOG_FILE% 2>&1 if not errorlevel 1 ( echo [%date% %time%] Backup OK: %BACKUP_FILE% >> %LOG_FILE% ) else ( echo [%date% %time%] ERROR: Verify failed >> %LOG_FILE% )%DATE%的格式在不同区域设置下输出不同，这个脚本在我的环境里生成的文件名是 Sys_20250615.wim，如果你的系统日期格式不是yyyy/mm/dd，需要改成对应的%DATE:~0,4%切片方式。日志文件里能看到每次备份是否成功，靠这个我能判断一台机器最近的备份状态，不用每次都去翻文件属性。
6.3 最后说一个习惯：备份完一定要做恢复演练
这个脚本我用了很久，真正救过我的不是脚本本身，而是有一次我抱着“试试看”的心态，在虚拟机里把刚备份的 WIM 恢复了一遍。结果发现 BCDBoot 那步忘了写/f ALL，导致 UEFI 机器恢复后无法引导。如果那次没演练，真到生产机器崩溃时才发现，那就不是花半小时能解决的问题了。
后来我就给自己定了一个规矩：每次调整维护流程后，至少在一台闲置机器或虚拟机上完整走一遍“备份→恢复→引导”的链路，确认没有任何环节依赖记忆。这个习惯帮我避掉了很多“应该没问题”的坑。DISM 命令本身不玄学，真正出问题的地方全在细节：源路径对不对、索引号对不对、引导修复跑没跑、空间够不够。把这些细节固化成脚本和检查清单，DISM 就会变成一套非常可靠的系统维护底座。希望这篇整理能帮到你，少走一点我走过的弯路。
本文还有配套的精品资源，点击获取
