
1. 做 img 镜像之前先把思路理清楚很多人一听到“制作系统镜像”第一反应就是打开某个工具点两下等着导出文件。实际上img 格式的系统镜像跟日常用的装机 ISO 完全不是一回事它更像是对整块磁盘做了一次“完整复印”里面包含了操作系统、引导程序、分区表、文件系统乃至硬件驱动信息。你做的任何一个多余操作或者系统里残留的脏数据都会原封不动地带进镜像里直接影响后续启动是否顺利。我平时接触最多的三个场景基本能覆盖 90% 的需求一是把一台物理服务器迁移到虚拟机二是给团队制作统一开发环境的“黄金镜像”Golden Image三是把定制好的 Linux 系统做成 img 文件方便写入其他磁盘或者批量部署到多台设备。无论你属于哪一种下面这套方法论都适用整体规划优先、制作前做减重、制作后做验证。请记住这十二个字它能帮你避开绝大多数坑。另外还要想清楚一个问题你要的是“整盘镜像”还是“单分区镜像”。整盘镜像包含 MBR/GPT 引导信息适合迁移和写盘单分区镜像通常只备份根分区或数据分区适合做软件备份、环境模板。两者的制作命令和后续处理方式差异很大我后面会分别讲到。2. 核心工具准备与关键参数详解制作 img 镜像本质上是对磁盘做完整或分区的复制因此工具选择非常关键。不同的操作系统和不同的目标场景工具选型完全不同。2.1 一个干净的 Linux 环境和一个 mount 点如果你要制作的系统本身是 Linux最推荐的制作环境是另一台 Linux 宿主机或者一张能启动的 Linux 安装盘进入急救模式。为什么要强调“干净”因为制作镜像的过程中被制作系统的分区不能处于挂载并被频繁读写的状态否则会复制到不一致的数据导致镜像内文件系统损坏。我踩过最大的一个坑就是在原系统运行状态下直接对根分区执行 dd。结果做出来的镜像虽然能引导但文件系统需要强制 fsck部分服务启动异常。后来学乖了制作镜像前一定把系统停到一个稳定状态——能卸载的分区全部卸载能关的服务全部关掉尽量用另一个系统来操作目标磁盘。在 Linux 环境中准备一个 mount 点也很重要一般用/mnt/sysimage这种路径。挂载分区检查、修改配置都需要这个临时目录。如果你做的是虚拟机内部磁盘的 img 文件还需要你有足够的磁盘空间来存放这个 img 文件至少在目标磁盘已用空间的两倍以上因为这些操作会产生临时文件和中间产物。2.2 dd 命令的完整语法与参数计算Linux 下最基础、最底层的镜像制作工具就是 dd。它的工作方式非常直接从输入文件读取数据原样写入输出文件。如果输入文件是一块磁盘设备输出文件是一个普通文件那你得到的就是一块磁盘的完整镜像。一条完整的整盘 dd 命令通常长这样dd if/dev/sda of/mnt/backup/system.img bs4M statusprogress convsync,noerror这里每个参数都有讲究if指定输入设备/dev/sda是你要镜像的整块磁盘。of指定输出文件/mnt/backup/system.img是镜像存放路径。bs是块大小设成 4M 或者 16M 能明显加快拷贝速度因为减少了寻道次数和系统调用。statusprogress是让你能实时看到复制进度和速度。convsync,noerror表示遇到读取错误时补零继续而不是中断这在磁盘有坏道时能救回大部分数据。不过如果你想要一个严格纯净的镜像我建议去掉noerror宁可它报错停止也不要默默补零免得后续启动时出现诡异问题。不少人会纠结块大小选择。对于现代磁盘来说bs64K、bs1M、bs128M之间的性能差异已经很小我实测下来bs4M在绝大多数 Linux 发行版上效率最高。如果你对性能敏感可以先跑一条dd if/dev/sda of/dev/null bs4M statusprogress来测一下源盘读取速度心里有个底。关于镜像大小的计算这里有个重要概念要区分开分区已用空间和分区大小。dd 复制的是整块磁盘的物理内容所以system.img的大小会等于源盘的总容量而不是系统实际占用的空间。比如你一块 500G 的盘系统只用了 50Gdd 出来的镜像仍然是 500G。这是 dd 模式最让人头疼的地方——镜像文件非常大且无法直接缩小。解决办法是后面结合qemu-img做格式转换和压缩或者改用 Clonezilla 这类按已用数据备份的工具。你如果对镜像体积有要求在这里就要做选型判断了。2.3 制作过程中为什么需要先挂载清理制作镜像前挂载到 Linux 环境中的源分区需要做几件准备工作。很多人直接开拷做完镜像后发现各种奇怪问题其实不是镜像本身有问题而是源系统本身就带着一堆“垃圾”进了镜像。第一件事是清理临时文件和日志。Linux 下的/tmp、/var/tmp、/var/log里往往堆积了大量无用数据。日志这东西在开发环境里没什么用但在镜像里会越积越多做成镜像既不干净又撑大体积。比较稳妥的做法是挂载后在目标根目录里执行清理命令清掉包管理器缓存、旧内核、临时文件。第二件事是检查磁盘剩余空间。你制作的镜像文件要放在另一个磁盘或分区上这个位置的剩余空间必须大于源盘的总容量。如果是多分区系统比如/boot单独分区、根分区、home 分区分开的情况dd 纯整盘方案会把你所有分区一股脑全部装进镜像。有机会的话我会在下一章演示一个更优雅的方案——用 Clonezilla 只备份必要的分区。第三件事是处理网卡和主机标识。Linux 系统在首次启动时会根据网卡 MAC 地址生成 udev 规则如果你把镜像部署到另一台机器上网卡名可能会从eth0变成ens33甚至出现网络无法启动的情况。虽然 Ubuntu/CentOS 的新版本已经不用/etc/udev/rules.d/70-persistent-net.rules但你依然要留意系统里固化了哪些硬件信息。对于 Windows 系统这个问题更严重会在第四章单独讲。3. 实操过程从正在运行的系统打包出可用的 img不同系统和不同场景需要不同的制作流程下面我会分三种情况来讲整盘 dd 方案、Clonezilla 分区备份方案、Windows 转虚拟机方案。这三种方案覆盖了绝大多数个人和团队的使用场景。3.1 在 Linux 宿主上用 dd 制作 raw 格式镜像这是最经典也是我平时最常用的一种方式。它特别适合源系统是一台 Linux 物理机或云主机你想把它整体迁移到 VMware/KVM 这类虚拟化平台或者你想把整个系统存档随时可以完整恢复。制作步骤大概如下准备一台 Linux 宿主机插上目标源盘通过 USB 硬盘盒转接也行确保系统能识别到它。假设识别为/dev/sdb。在宿主机的存储空间上创建一个目录比如/data/img_output。先确认盘符和分区情况避免拷错盘。用fdisk -l或lsblk查看找到目标盘的正确盘符。lsblk # 输出类似 # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT # sdb 8:16 0 232.9G 0 disk # ├─sdb1 8:17 0 512M 0 part # ├─sdb2 8:18 0 232.4G 0 part执行整盘 ddsudo dd if/dev/sdb of/data/img_output/my-system.img bs4M statusprogress耐心等待。一块 500G 机械硬盘全盘复制可能要一两个小时如果是 NVMe 固态速度会快得多大约十分钟到二十分钟。复制完成后使用sync命令确保缓存落盘然后对镜像文件做一次完整性检查sync sudo fdisk -l /data/img_output/my-system.imgfdisk -l能直接识别 img 文件里的分区表如果能正常列出分区说明镜像头部数据完整。我再强调一句dd 出来的原始 img 文件大小和源盘一模一样直接拿去用没问题但如果你要传到网盘、分发给别人建议先压缩。压缩命令放在第四章因为涉及格式转换和体积优化。3.2 用 Clonezilla 做分区镜像备份与恢复细节Clonezilla 是我非常推荐的一个工具它最大的优势是“只备份已用数据”生成的文件体积远小于 dd 整盘镜像而且恢复时可以自由选择恢复到更大或更小的目标分区不用被源盘大小绑定。它适合的场景主要有给团队做统一开发环境模板、备份系统分区、在异机间迁移 Linux 系统。使用 Clonezilla 的方式有两种一种是下载它的 ISO 做成启动盘启动后按菜单操作另一种是在现有 Linux 里安装clonezilla包通过命令行执行。我通常用前者因为制作镜像时源系统应该是离线状态启动盘方案最安全。关于 Clonezilla 的专业模式你需要了解几个关键菜单的含义device-image把分区或整盘保存成一个镜像文件。device-device直接磁盘对拷相当于磁盘克隆。选择“专家模式”Expert Mode后可以控制压缩选项、检查镜像、是否分割存储等。保存格式可以选择-q1或-q2分别对应不同的压缩比例和速度。用 Clonezilla 备份 Linux 系统时我强烈建议把/boot分区单独勾选并把根分区一同备份。恢复的时候先恢复根分区再恢复/boot顺序不对会导致引导失败。另外要注意Clonezilla 生成的镜像是一个包含多个文件的文件夹不是单一 img 文件如果你想得到的是纯 img 文件后面还需要用qemu-img convert把 Clonezilla 镜像转换成 raw 格式。虽然多了一步但在批量部署场景下Clonezilla 的方案远优于 dd。3.3 把 Windows 系统做成 img并让它在 VMware 里跑起来把 Windows 物理机做成 img 再塞进虚拟机里跑是很多人最想实现的操作。但这个流程比 Linux 复杂得多因为 Windows 对硬件抽象层HAL的变化非常敏感主板的 ACPI 接口、存储控制器、显卡驱动任何一个不匹配都可能导致蓝屏0x0000007BInaccessible Boot Device。我个人的经验是除非万不得已不要直接用 dd 把 Windows 物理盘做成 img 再启动。正确路线是用 VMware 自带的 vCenter Converter或者用 Disk2vhd 把 Windows 系统转成 VHD/VHDX 格式然后再用 qemu-img 转成 img。整体步骤是这样的在 Windows 物理机上运行 Sysprep 工具这个工具位于C:\Windows\System32\Sysprep\sysprep.exe。选择“进入系统全新体验OOBE”勾选“通用”关机选项选“关机”。Sysprep 会重置系统唯一标识SID、清除事件日志并让 Windows 在下次启动时重新枚举硬件这是 Windows 镜像能够跨硬件迁移的关键。用 Disk2vhd微软官方工具把正在运行的物理磁盘转换成 VHDX 文件。这个工具支持在系统运行时在线转换不要求关机。如果系统盘较大建议输出目录放在另一块物理磁盘上。把生成的 VHDX 拷贝到装有 VMware 的宿主机上新建虚拟机磁盘类型选 SATA 或 SCSI 都行先不要启动把虚拟机的磁盘文件指向该 VHDX。打开虚拟机的 VMX 配置文件在文件末尾加入一行ide0:0.returnToBios false这个参数很重要否则 VMware 可能会因为找不到启动设备而卡住。如果是 SCSI 控制器启动则在 VMX 里加入scsi0:0.returnToBios false启动虚拟机这时 Windows 会自动安装新硬件驱动并重启数次耐心等待完成即可。如果你真的只能拿到一个 img 文件比如同事给你拷了一个那也可以通过 VMware 的“转换物理机”功能或者直接新建虚拟机选择“使用现有虚拟磁盘”来加载。实测下来img 格式可以被 VMware Workstation 直接识别并挂载但如果启动蓝屏大概率是缺少适当驱动或硬件抽象层不匹配这种问题的排查我会在第六章里细讲。3.4 镜像压缩与格式转换让 img 文件“瘦身”并跨平台使用dd 出来的 raw img 文件动辄几百 GB不适合存储和传输。我一般会用qemu-img工具把它转换成qcow2格式或者进行压缩。qemu-img 是 QEMU/KVM 虚拟化套件里的一个命令行工具也可以独立安装在各种 Linux 发行版里。先安装依赖在 Ubuntu/Debian 上sudo apt install qemu-utilsCentOS/RHEL 系sudo yum install qemu-img最常用的是这条命令把 raw 格式转成 qcow2 并启用压缩qemu-img convert -f raw -O qcow2 -c my-system.img my-system.qcow2如果想要受限大小的镜像并且源分区是 ext4/xfs还可以用truncate或qemu-img resize先缩小文件系统再转换。这里要注意resize 是有条件限制的只能在文件系统支持缩容的前提下进行而且必须先缩文件系统再缩镜像文件顺序反了就会损坏数据。我一般习惯这样操作先挂载镜像内的根分区。用resize2fs把文件系统缩到最小。sudo resize2fs -M /dev/mapper/loop0p1用e2fsck -f检查文件系统一致性。卸载分区使用qemu-img resize把镜像缩到文件系统实际大小加上少量余量。最后再转 qcow2 并压缩。这样处理之后原本一个 60G 的 Linux 系统镜像通常能缩到 2-4G 的 qcow2 文件。如果你需要的是 imgraw格式最后再转回去即可qemu-img convert -f qcow2 -O raw my-system.qcow2 slim-system.img4. 制作镜像的优化与兼容性处理很多新人做出来的镜像能启动但在不同硬件或虚拟平台上跑起来总出问题。这一章就是专门解决这些“看起来能用但用得不爽”的情况。4.1 为什么要先改系统配置再做镜像有一类问题制作时不会立刻暴露等镜像部署到新机器才会爆发比如网卡起不来、SSH 连不上、磁盘分区无法识别。根源基本都是制作前没有清理系统里的硬件绑定信息。Linux 系统里/etc/fstab记录着文件系统挂载表和分区的 UUID。当你把系统迁移到新磁盘时如果分区 UUID 变了启动时会卡在mount阶段或者进入紧急模式。因此在制作镜像前我建议先记录一下分区 UUIDblkid /dev/sda1然后把/etc/fstab里的挂载项改成用 LABEL卷标或者改为相对路径引用。如果你不确定怎么改最稳妥的办法是保留 UUID 不变即制作镜像时保持分区顺序和分区表结构与原盘一致这正好是 dd 整盘方案的优势——分区表、UUID、文件系统结构完全原样复制。如果你要做的是部署到多种硬件的通用镜像那么fstab里还需要确认没有写死设备名比如/dev/sda尽量使用UUID或LABEL引用。另外/etc/udev/rules.d/70-persistent-net.rules这种文件如果存在直接删掉让系统重新生成。我在 CentOS 7 上就遇到过网卡从eth0变成enp2s0导致网络脚本失效的问题删除后重启即可恢复。Windows 系统更麻烦参考 3.3 节的 Sysprep 流程。这里再强调一句Sysprep 必须在系统未加入域且以管理员身份运行时才有意义如果你在制作镜像前忘了跑 Sysprep那么每个从同一镜像部署出去的 Windows 都会拥有相同的 SID在域环境中会出现各种权限和身份冲突问题。虽然在一些小规模场景下不跑 Sysprep 也能用但这是个定时炸弹强烈建议养成习惯。4.2 解决引导问题MBR、EFI、grub 修复哪怕你镜像制作步骤完全正确也很难保证目标机器的引导方式和源机器一致。比如源盘是 MBR 传统 BIOS 引导目标虚拟机是 UEFI 引导镜像就会直接启动不了。这个场景在 VMware 里非常常见所以我一般把引导问题分成两类来排查。第一类是 MBR 引导。如果你用 dd 做了整盘镜像恢复后 MBR 区域应该也恢复了。如果引导还是起不来通常是因为 GRUB 的配置文件引用的是旧磁盘设备名比如旧的grub.cfg里写着rootUUIDxxx而目标系统的 /boot 分区 UUID 变了。修复方法是用系统安装盘启动进入急救模式chroot 到目标系统重新安装 GRUB。在 Ubuntu 上grub-install /dev/sda update-grub在 CentOS/RHEL 上grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg第二类是 EFI 引导。UEFI 启动依赖 EFI 分区中的引导文件以及 NVRAM 启动项。如果你做的是整盘 dd 镜像EFI 分区也会被包含但目标机器的 NVRAM 里没有指向该 EFI 分区的启动项。解决办法是进入目标机器的 UEFI 设置里添加启动项或者在系统内用 efibootmgr 手动创建。在 Linux 中可以使用efibootmgr -c -d /dev/sda -p 1 -L MyLinux -l \\EFI\\ubuntu\\shimx64.efi这是我修复 EFI 引导最常用的命令-p 1表示 EFI 分区是第一个分区-l指定引导文件路径不同发行版路径不同Ubuntu 一般是shimx64.efiCentOS 是shimx64.efi或grubx64.efi。如果你对这类命令不熟悉最稳妥的办法是用安装盘的“尝试/救援模式”工具自动修复。4.3 Windows 系统镜像的体积优化与 SID 重置Windows 系统盘的静态体积通常很大光是一个C:\Windows目录就轻松超过 20G。做镜像前如果不做瘦身制作出来 img 文件会非常庞大传输同步都是问题。我自己在给团队做 Windows 开发环境镜像时会执行下面这些操作关闭系统还原、休眠功能删除hiberfil.sys使用powercfg /h off。运行磁盘清理工具清理系统临时文件和 Windows 更新缓存。使用vssadmin delete shadows /all删除所有系统还原点。卸载不需要的预装应用和第三方软件。清理用户目录下的下载文件、临时文件。对于 Windows 10/11 系统镜像原生体积已经非常大即使压缩也不是很理想。我的建议是至少分两个版本一个基础版只安装操作系统和必要驱动一个完整版包含团队常用开发工具。基础版用于快速部署完整版用于开发者日常使用两者用同一个 Sysprep 流程处理部署效率会高很多。SID 重置是 Windows 镜像最容易被忽略的问题。直接复制 Windows 系统而不做 Sysprep会导致所有复制出来的系统 SID 相同。SID 相同在域环境下几乎无法使用——新机器无法加入域或者加入后账户权限会互相干扰。Sysprep 的“通用”选项就是专门解决这个问题的。另外 Sysprep 之后Windows 下次启动会重新进入 OOBE这意味着你需要重新创建本地管理员账户。如果你希望部署时能自动配置可以使用unattend.xml应答文件配合 Sysprep 实现全自动配置这块内容比较多我后续会单独写一篇这里先留个引子。5. 验证与使用场景从 img 到实际运行镜像做完了别急着分发或写盘先花点时间验证它能不能正常启动。任何跳过验证的镜像部署都是耍流氓——你永远不知道哪一步会出错。5.1 用 VMware/QEMU 验证镜像最方便的验证方式是把镜像直接加载到虚拟机里测试。对于 raw 格式的 img 文件VMware Workstation 可以直接识别。新建虚拟机时硬盘类型选 SATA然后选择“使用现有虚拟磁盘”并指向 img 文件启动即可。如果不想新建虚拟机也可以用 QEMU 快速启动。QEMU 的优点在于它能把 img 文件直接当作磁盘设备来用并且支持多种格式包括 raw、qcow2、vdi、vmdk。一条很简单的命令qemu-system-x86_64 -m 2048 -hda my-system.img -boot c -net nic -net user加-enable-kvm可以启用硬件加速跑起来会流畅不少。验证时需要重点检查这几个项目能否正常引导进入系统、磁盘挂载是否全部正常、网络接口是否启用并能获取 IP、关键服务SSH、数据库、Web 服务是否自动启动。如果这些都没问题镜像基本可以认为合格。如果出现引导异常按第四章的排查思路去处理再重新生成镜像不要在坏镜像上打补丁相信能侥幸成功。5.2 把 img 写入物理磁盘用于整机替换或批量部署img 文件最典型的用途之一就是写入物理磁盘做成一张可启动的移动硬盘或者替换原来系统盘。Linux 下写入镜像的命令非常简单但也是一个容错率极低的操作。确认目标盘后再执行一旦写错数据全没。sudo dd ifmy-system.img of/dev/sdb bs4M statusprogress convsync写入完成后拔盘前先执行sync。如果目标磁盘小于源盘dd 会直接报错这个没办法绕过去只能先把目标盘换大容量。写入后首次启动有可能会因为磁盘分区表没有完全对齐导致性能降低但不影响使用。如果你用的是 UEFI 引导还需要确认目标机器设置成从你写入的那块磁盘启动。生产环境我一般不建议在线 dd 写入正在运行的机器因为写入过程中系统可能产生 I/O造成数据不一致。我惯用的做法是准备一个带 Linux 的 Live USB 启动环境在 Live 环境里完成写入。这样能保证目标磁盘没有挂载镜像一致性最好。5.3 镜像部署后的网络与安全设置这一步经常被忽略但恰恰是镜像“千人千面”的关键。从同一个镜像分发出多台机器后每台机器的 hostname、IP、SSH 密钥、机器 ID 如果完全一样轻则网络冲突重则无法同时接入同一网络。Linux 系统里需要重点修改的有/etc/hostname改成每台机器自己的主机名。/etc/machine-id删除或重新生成这是 systemd 用来标识机器的唯一 ID。U 和机器不同务必重置。SSH 主机密钥位于/etc/ssh/ssh_host_*直接删除并重启 SSH 服务让它重新生成。云平台还需要修改唯一标识比如 cloud-init 的/etc/machine-id和/var/lib/cloud/instance。Windows 系统则是通过 Sysprep 自动处理主机名和 SID开机后你只需要手动设置计算机名和网络配置即可。做镜像分发前把这些配置统一清理干净部署完的机器舒适度会高很多。6. 常见问题与排查技巧实录最后把我在多年实操中遇到的高频问题整理成表方便你快速定位。这些坑我都踩过没有一个是纸上谈兵。问题现象可能原因排查与解决思路启动后提示initramfs或UUID does not existfstab里写死了旧分区 UUID镜像恢复后分区 UUID 改变进急救模式用blkid查看实际 UUID修改/etc/fstab启动后网络接口名变了无法获取 IPudev 规则固化了旧网卡名删除/etc/udev/rules.d/70-persistent-net.rules重启网络服务Windows 镜像启动蓝屏0x0000007B缺少磁盘控制器驱动或 HAL 不匹配制作前跑 Sysprep并用 vCenter Converter 或 Disk2vhd 转换不要直接用 dd虚拟机启动后黑屏只有光标闪烁EFI 引导项丢失在 UEFI 设置里新增引导项或进入 Live 环境用 efibootmgr 修复镜像文件比源盘已用空间大得多dd 是整盘复制不区分已用和空闲用 qemu-img convert 转格式并压缩或用 Clonezilla 按已用数据备份克隆多台机器后 SSH 报 key 冲突所有机器 SSH 主机密钥相同删除/etc/ssh/ssh_host_*重启 SSH 服务重新生成Clonezilla 恢复后无法引导恢复了根分区但漏了/boot或者恢复顺序颠倒先恢复根分区再恢复/boot确认引导分区包含 GRUB 文件dd 写入后目标盘无法引导目标盘比源盘小或引导扇区不兼容换更大容量磁盘检查 MBRfdisk确认分区表必要时重装 GRUB排查问题有一条基本原则不要光看症状要追根因。启动失败先确认到哪一步失败是 BIOS/UEFI 自检前失败、引导加载器失败、内核启动失败还是用户态服务失败。最简单的办法是看启动时屏幕最后一行输出或者接串口看日志。虚拟机里就通过 VMware 的虚拟串口把内核输出导出来物理机就只能靠显示器和耐心了。个人经验里最有用的排查工具是一个能启动的 Linux Live USB再加上一份源系统的安装盘。无论是修复 GRUB、chroot 修改配置、还是重新生成 initramfs都能在 Live 环境完成。目前很多发布版提供“救援模式”本质上就是这个思路。遇到不严重的问题别急着重做镜像先进 Live 环境看看配置有没有救。另外制作大镜像时建议把源盘碎片整理干净。Windows 下可以用contig或系统自带的碎片整理Linux 的 ext4 碎片化影响不大但日志文件系统建议先执行fsck -f确保文件系统无错。一个带文件系统错误的镜像放到哪都是隐患。最后几条个人忠告我不建议你第一次做复杂镜像就直接照抄全流程最好从一台测试虚拟机开始练手。在虚拟机上跑通 dd、转换、恢复、验证这一整套流程你再迁移物理机就有底气了。镜像命名也要养成良好习惯系统名-架构-版本-日期-状态.img这种格式比如ubuntu-22.04-amd64-20250115-base.img。做过镜像维护的朋友都明白命名混乱的镜像目录就是一场灾难三个月后你自己都分不清哪个能用哪个是半成品。如果你做的镜像是长期要用的基础环境记得给“基础版本”和“软件更新版本”分开维护不要把日常更新直接覆盖到黄金镜像上否则很容易把测试机上的脏数据带进正式镜像。我自己是固定三个月更新一次基础镜像中间只做安全补丁和驱动更新应用软件尽量部署时不依赖镜像变更。这些方法目前看来已经覆盖了大多数主流场景不管是 Linux 还是 Windows物理机还是虚拟机整盘备份还是分区备份。做镜像这件事刚接触时觉得很高深做多了就会明白它本质上就是“完整复制 环境适配”两件事。把这两件事拆开一步步来最终一定能得到一个干净、稳定、可直接使用的系统镜像。