hyaliney我不止一次被人问到同一个问题：手里拿到一个 .dmg 镜像，想把它写进一个硬盘分区，然后插到 x86 架构的机器上直接用。问的人有 Windows 用户，也有 Linux 玩家，还有刚从 macOS 生态接触这类操作的开发者。看起来就是“把文件写进去”这么简单，实际上“写进去”三个字背后藏着两套完全不同的逻辑，选错方法，轻则白折腾一下午，重则整块硬盘变成无法识别的“砖头”。
dmg 是苹果生态里的磁盘映像格式，但它在 x86 平台上的出镜率比很多人想象中高很多。比如某些恢复镜像、定制系统包、老设备维护场景，都会碰见它。之所以要专门聊这个话题，是因为 dmg 和普通 ISO 不一样，它内部可能是只读文件系统容器，也可能是一个裸分区快照，两种形态对应两种写入方式。这篇就把“写 dmg 到硬盘分区”这件事彻底讲清楚，覆盖 macOS、Windows、Linux 三种环境，适合手里正好有一个 dmg 镜像、正准备把它做成启动盘或恢复盘的人参考。
1. 先搞清楚需求：把 dmg“解开放进去”和“整盘恢复”是两回事
1.1 在 x86 环境里见到的 dmg，九成来自这三种渠道
先说结论：dmg 只是一个“包装箱”，箱子里装什么完全看制作人怎么封。我经手过的 dmg 大致能分三类。
第一类是 macOS 官方安装器衍生出来的镜像。这类最典型，比如 InstallESO.dmg、BaseSystem.dmg、RecoveryHD.dmg，本质上是一个 macOS 恢复系统或安装系统的完整根目录，内部文件系统是 HFS+ 或 APFS，设计目标就是被安装程序恢复到一个分区后启动。很多折腾 x86 引导、或者想用一台普通 PC 做恢复盘的人，手里拿到的就是这一种。
第二类是工具软件或安全厂商发布的恢复镜像。这类 dmg 往往里面还套着一层 DMG，打开之后可能只有一个 .pkg 或 .app。这种严格来说不属于“写进分区”的场景，但很多人会混在一起问，顺手提一下。
第三类比较特殊，某些 x86 架构的开源系统或嵌入式系统镜像会用 dmg 格式分发。虽然大多数时候最终会被打包成 img 或 iso，但偶尔能看到直接用 dmg 发布的，比如一些游戏系统、软路由系统、复古模拟器系统。这类镜像内部通常是裸分区数据，就等着你逐字节写进 U 盘或硬盘。batocera 这种模拟器系统，就有过类似的封装，只是多数人拿到手的是 img.gz。
为什么要费劲分这三类？因为第三类可以直接用 dd 写入，第一类则要分情况：有的能直接 asr 恢复，有的必须先做一个“可引导安装盘”，而不是单纯把镜像写进分区就完事。方向不对，后面的步骤全是白费。
1.2 文件复制和逐字节恢复，结果完全不同
假设已经明确手里是个系统镜像 dmg，接下来要选通道，而且通道只有两条。
一条是“解包复制”。把 dmg 挂载成卷，然后把里面所有文件复制到目标分区，再手动处理引导文件。macOS 官方制作启动安装盘用的 createinstallmedia，本质就是这个思路。这条路的优势是过程可控、可以中断重来，缺点是很多通用镜像没有对应的“安装套件”，你没法拿 createinstallmedia 去处理一个非 macOS 的 dmg。
另一条是“逐字节恢复”。源 dmg 必须是一个裸分区镜像格式（也叫 raw/UDRO），然后把每个扇区原样写到目标分区上。macOS 的 asr restore，Linux 和 Windows 下的 dd，都是这条路线。这条路的风险是目标分区原有数据会全部消失，优点是恢复出来的分区和源镜像一模一样，包括引导代码、分区编号、文件系统 UUID 都会保留。
所以动手前先问自己两个问题：这个分区写完之后，是要拿来启动系统，还是只是想把镜像里的文件解出来用？如果要启动，再问一句：这个 dmg 是“安装器”还是“现成系统”？前者用 createinstallmedia 或 asr，后者用 asr 或 dd。这个问题不搞清楚，后面再熟练的命令也救不了你。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. macOS 环境下写入的标准姿势：hdiutil 加 asr 的组合
2.1 读盘比写盘更重要，先花一分钟看镜像信息
在 macOS 里操作有一个天然优势：系统原生支持 dmg、HFS+ 和 APFS，不用造轮子。但原生支持不等于可以闭眼写。我见过太多人直接 sudo dd if=xxx.dmg of=/dev/diskX，结果写出来的分区连 macOS 自己都不认识，原因就是 dmg 默认是压缩格式，必须先转成裸镜像才可以用于 dd。
所以不管走哪条路，第一步永远是读镜像信息：
bash复制hdiutil imageinfo /path/to/image.dmg
重点看两个字段。第一个是 Format，如果写的是 UDZO、UDIF、UFBI 这类带压缩的格式，说明这个 dmg 不是裸镜像，不能直接拿来 dd；第二个是 Partition Scheme，如果是 “GUID Partition Table” 或 “FDisk”，表示里面带分区表，恢复目标应该是整个磁盘而不是某个分区。
如果你的目标是恢复到一个“分区”，但镜像里带分区表，通常有两条路子：要么把镜像恢复给整个磁盘（原磁盘分区表会失效），要么用 asr 的 --source 指定镜像内部卷、--target 指定你想要的分区。对普通用户，建议直接选不带分区表的 dmg 来操作，少一层麻烦。
2.2 图形化方案：磁盘工具的“恢复”功能其实就是 asr
如果你的 macOS 系统还完整，最省心的工具是“磁盘工具”里的“恢复”页签。操作路径：打开“磁盘工具”，选中要写入的目标分区，点击工具栏“恢复”，在“映像”一栏选择你的 dmg，点“恢复”。系统会弹窗警告目标分区会被抹掉，确认后就开始了。
这一步背后跑的就是 Apple Software Restore，简称 asr。图形化方案的好处是系统会自动处理很多细节，包括自动争取 root 权限、自动检查目标分区兼容性、自动校验镜像。速度方面，从 SSD 恢复到 SSD，往往可以跑到每分钟几百 GB，而且结束后会自动做一次校验。对第一次操作的人来说，这是我最推荐的方式。
但要注意，磁盘工具的“恢复”不是“克隆”，也不是简单的“擦除”。它要求目标分区必须已经存在，而且容量不能小于镜像内部卷的占用。如果手里是一块完全未分区的硬盘，需要先手动分区、格式化，再执行恢复。
2.3 命令行方案：attach 加 asr restore 的完整流程
命令行比图形化灵活，适合对分区表有精确控制需求的人。步骤固定：先挂载 dmg，再定位目标设备，最后恢复。
挂载只读：
bash复制hdiutil attach -nobrowse -readonly /path/to/image.dmg
这条命令会返回类似 “/dev/disk4s1 /Volumes/MyVolume” 的输出，左边是设备节点，右边是挂载点。如果 dmg 是压缩格式，系统会自动解压并暴露卷。
然后查看目标分区设备号：
bash复制diskutil list
假设目标是一块外接硬盘的第二个分区，在 macOS 里通常写作 /dev/disk5s2。asr 恢复建议用字符设备节点，也就是 /dev/rdisk5s2。前缀多个 r 代表“原始设备”，走底层驱动，绕过块缓冲层，速度会快不少，写盘也更稳定。
执行恢复：
bash复制sudo asr restore \
--source /dev/disk4s1 \
--target /dev/rdisk5s2 \
--erase \
--noverify
参数逐个解释。--source 可以写挂载点，也可以写设备节点，写设备节点更直接。--target 是目标分区，建议用 rdisk。--erase 表示恢复前先擦除目标，这是常规操作，不加的话如果目标分区非空，asr 会直接拒绝。--noverify 跳过源卷恢复前的校验，临时恢复建议加，省时间；如果镜像来路不明，最好把 --noverify 去掉，让它完整校验一遍。
恢复完成后，目标分区会被重新挂载，名字通常会变成源卷的名字。此时别急着拔盘，先用 diskutil list 再确认一次分区和挂载状态。
2.4 什么时候才轮到 dd 直接写
asr 能解决大部分问题，但还有两种场景必须用 dd。
第一种，源 dmg 本身就是裸镜像格式，比如你已经用 hdiutil convert 把某个 UDZO 的 dmg 转成了 UDRO，或者第三方给的镜像本来就是整块磁盘快照。这个时候 asr 反而不一定认，dd 是最朴素可靠的方式：
bash复制# 先把非裸镜像转成裸镜像，注意输出会额外加 .dmg 后缀
hdiutil convert /path/to/image.dmg -format UDRO -o /path/to/image-raw.img
# 确认目标设备编号
diskutil list
# 写入
sudo dd if=/path/to/image-raw.img of=/dev/rdisk5 bs=4m conv=sync,noerror
bs=4m 表示每次读写 4MB，对现代硬盘是合理块大小；conv=sync,noerror 的意思是遇到读错误时用零补齐继续写，防止中途中断。这里没有区分分区还是整盘：如果写的是 /dev/rdisk5，整块磁盘都会被覆盖；如果只想写一个分区，就要写成 /dev/rdisk5s1。绝大多数 dmg 裸镜像都是整盘镜像，所以一般目标都是整盘设备。
第二条命令里的 hdiutil convert，实际生成的文件名是 image-raw.img.dmg，因为 hdiutil 默认会补扩展名。这不是 bug，是它的习惯。如果你接下来要交给脚本处理，先改好文件名再传给 dd，不然很容易掉坑。
3. 在 x86 Windows / Linux 下处理 dmg 的可行路子
3.1 Windows 读不到 dmg，卡在格式和文件系统两层
很多 Windows 用户第一次拿到 dmg，会下意识拿 WinRAR 或 7-Zip 去硬开。7-Zip 确实能解开一部分 dmg 的压缩层，但那只剥了外壳，里面往往是另一个文件系统镜像，Windows 没有 HFS+ 和 APFS 驱动，打开后依然读不出内容。
真正要做的不是“打开 dmg”，而是“把 dmg 转成 Windows 能直接写盘的格式”。思路很简单：dmg 不管是 APFS 还是 HFS+，只要它是一个块级镜像，写进硬盘分区之后，分区里的格式数据并不会消失，Windows 只是不识别而已。而如果目标是“把镜像内容还原到分区”，写入这个动作本身并不依赖 Windows 能不能识别目标文件系统。所以办法是先把 dmg 转成 raw 或 img，然后像写其他系统镜像一样写进分区。
3.2 Windows 环境实操：dmg2img 转 raw，再用 Rufus 的 DD 模式写入
Windows 下最顺手的组合是 dmg2img 加 Rufus。dmg2img 是一个老牌开源工具，很多镜像站有预编译 exe。拿到后放一个目录，在命令行执行：
bat复制dmg2img.exe input.dmg output.img
转换耗时取决于文件大小和磁盘速度，一个 10GB 级别的镜像大概需要几分钟到十几分钟。转换完成后，得到一个 output.img，这就是可写的裸镜像。
接着打开 Rufus，设备选择你的 U 盘或移动硬盘，引导类型选择“磁盘或 ISO 映像”，点“选择”找到刚生成的 output.img。Rufus 识别到 img 后通常会自动提示“将以 DD 镜像模式写入”，选确定。
有一个容易被忽略的点：Rufus 的普通 ISO 模式和 DD 镜像模式完全是两回事。如果你选了一个 img，但它却没有进入 DD 模式，而是显示“可以制作可引导 U 盘”，说明它把 img 当成分区镜像在解析，最终刻出来的盘大概率无法启动。正确判断标准是：在 Rufus 界面里，启动类型图标变成一个黑底扇区图形，有“DD 模式”字样，这才是对的状态。
不想用 Rufus 的话还有两个替代。一个是 balenaEtcher，它原生支持 dmg，直接把 dmg 拖进去选目标盘就可以。另一个是 TransMac，收费软件，但可以在 Windows 下直接“还原 dmg 到 U 盘”，兼容性不错。我的习惯是用 Etcher 快速做，用 Rufus 做需要精确控制的时候再来细调。
3.3 Linux 环境实操：dmg2img 加 dd 一条龙
Linux 下的流程和 Windows 高度相似，但有个优势：Linux 的 dd、分区工具和文件系统识别工具更底层，踩坑更容易定位。
先安装 dmg2img。Debian/Ubuntu 系：
bash复制sudo apt install dmg2img
Arch 系：
bash复制sudo pacman -S dmg2img
RHEL/Fedora 系可能需要从源码编译，或者找静态二进制，不过主流发行版仓库基本都收了这个包。
转换：
bash复制dmg2img input.dmg output.img
然后确认目标设备：
bash复制lsblk
找到目标盘，比如是 /dev/sdb，写入命令：
bash复制sudo dd if=output.img of=/dev/sdb bs=4M status=progress conv=fsync
status=progress 会显示写入了多少、当前速度，推荐加上。conv=fsync 强制在命令结束前把缓存落盘，避免拔盘时数据没写完。
Linux 下如果不确定镜像是不是裸格式，可以用 file 看一眼：
bash复制file output.img
如果输出显示 “DOS/MBR boot sector” 或 “Apple HFS/HFS+ filesystem” 或 “APFS” 之类，说明已经是块级镜像；如果显示 “zlib” 或者 “gzip data”，说明外层还套着压缩层，要先解压再处理。
3.4 跨平台写入后的一件大事：引导方式与分区表
x86 机器上写完镜像之后能不能启动，往往不取决于你写的手法，而是取决于镜像里的引导程序和你的机器固件类型是否匹配。x86 平台的引导方式主要有两类：传统 Legacy BIOS 使用 MBR 分区表，从主引导记录读引导代码；UEFI 使用 GPT 分区表，从 FAT 格式的 ESP 分区（EFI System Partition）里加载 .efi 引导文件。
如果你手里的 dmg 是某个定制的 x86 系统镜像，它内部一般已经带好了对应引导程序。把整盘 dd 到目标磁盘后，整盘分区表跟着镜像走，启动通常没问题。但如果你只是把某个苹果恢复镜像恢复到磁盘的一个分区，而这个磁盘原本是 UEFI+GPT 布局，那很可能需要手动处理引导项。多数主板在 UEFI 模式下不会自动去认一个 APFS 分区里的恢复卷，你需要进启动项里手动指定“从该磁盘的恢复卷启动”，或者借助引导管理器。
这里有个通用判断逻辑：写整盘，分区表和引导程序跟着镜像走，最省心；写分区，镜像外面的分区表要靠你自己安排，容易出问题。能整盘写就整盘写，除非你明确知道自己在做什么。
4. 实操中反复踩的坑与排查链路
4.1 写完了分区不显示，问题可能出在分区表而不是写入动作
这是最高频的翻车现场：dd 结束，去“此电脑”一看，U 盘没有盘符，磁盘管理里显示一个 RAW 分区或者未分配空间。大部分人的第一反应是“没写进去”，其实写进去的概率很高，问题往往出在 Windows 不识别目标文件系统。APFS 和 HFS+ 都不是 Windows 原生格式，Windows 把这种分区显示成 RAW 是正常现象。这时候不要重新格式化，先找一个能识别的工具确认，比如 DiskGenius 或 paragon APFS 的试用版，看看分区内容是否还在。
反过来，Mac 上用磁盘工具写入，写完了目标分区却没出现在桌面，也不要着急。先到终端执行 diskutil list 看设备节点是否还在，很多时候是 macOS 因为卷名冲突或挂载异常没有自动挂载，手动 diskutil mount /dev/diskX 就能解决。
4.2 asr 报“source volume could not be mounted”，基本锁定三种原因
macOS 下用 asr 恢复时最容易碰到的报错就是类似 “source volume could not be mounted” 或者 “image is not a mountable filesystem”。排查顺序建议固定下来。
第一，源 dmg 是否损坏。用 hdiutil imageinfo 如果直接报错，就是文件坏了，重新下载。第二，是否为加密镜像。asr 不支持带加密的 dmg，需要先用 hdiutil convert -format UDRO 解开并转成裸格式。第三，源是不是一个旧版 HFS 卷镜像。某些老镜像需要你先把 dmg attach 成卷，再指定卷路径给 asr，而不是直接指定 dmg 文件路径。这个区别文档里提过，但实战中很容易忽略。
还有一种隐蔽情况：asr 恢复时报告 “The target volume is too small for the source”。这种不用细看文件系统占用率，asr 要求目标分区的总容量大于镜像内部卷已用容量再加上一部分元数据空间。比如 16GB 的 U 盘恢复 12GB 的镜像，往往在最后关头报这个错。我的建议是目标介质容量至少要是源镜像体积的 1.2 倍，别卡着边界算。
4.3 Resource busy、权限不足这类环境问题怎么处理
macOS 下 asr 和 dd 都需要 root 权限，开头忘记 sudo 会出现 Permission denied。但更讨厌的是 Resource busy，意思是目标设备被系统占用。常见于你要写入的分区正处于已挂载状态，或者它是当前系统所在的 APFS 容器成员。解决方式是先卸载目标分区：
bash复制diskutil unmountDisk /dev/disk5
如果用磁盘工具的图形界面恢复，软件会自动卸载；如果用户 dd 写一块已挂载的磁盘，必须先卸载它的所有卷，否则 dd 写进去的内容会被系统缓存覆盖，出现“写完了但分区内容没变”的灵异现象。
Windows 和 Linux 下也有对应问题。Windows 下如果目标盘在磁盘管理里显示“联机”，写盘工具可能会失败，需要先把分区“删除卷”或“脱机”；Linux 下需要确保目标盘没有在 /etc/fstab 或 systemd 挂载单元里被自动挂载，最稳妥的是先 umount /dev/sdb* 再 dd。
4.4 分区容量小于镜像，如何体面地处理
目标分区比镜像小，这个问题出现的频率不低。如果是 APFS 恢复镜像，有些镜像内部卷实际占用很小，但镜像文件体积很大，因为里面有缓存、快照和校验数据。你需要的不是更大的分区，而是先用工具看卷的真实占用，比如挂载后用 df -h。如果是 HFS+ 镜像，它要求目标分区不小于镜像内部卷容量，要么换大分区，要么用 asr 的 --noverify 碰运气，但结果大概率失败。
真正稳妥的做法是在写入前就规划好目标分区尺寸。如果用 Windows 磁盘管理或 macOS 磁盘工具预先分区，建议分得比镜像文件大出 3%-5%，给文件系统元数据和后续更新留余量。APFS 可以自扩容，恢复成功后系统首次启动会把容器扩展到整个磁盘，不需要你手动处理。但 HFS+ 或 ext4 这类不会，如果给的分区比实际需要大，恢复后会剩余空间，你需要再用磁盘工具手动调整，这一步很多新手不知道，于是出现“系统盘只有 30GB 可用，磁盘明明有 500GB 空着”的困惑。
4.5 创建 macOS 安装盘：很多情况下不需要写 dmg，createinstallmedia 才是正道
这里必须澄清一个很大的误区。很多人看到“dmg 写入分区”，第一反应就是把 InstallESO.dmg 或 BaseSystem.dmg 直接 dd 到 U 盘，结果插到机器上发现根本不能引导。原因很简单：这些 dmg 是安装器的“装载包”，不是一个自带引导逻辑的裸分区镜像，dd 过去只能得到一堆散乱数据，主板不知道该从哪里启动。
如果你想做的是“macOS 安装 U 盘”，正确做法是用 createinstallmedia：
bash复制sudo /Applications/Install\ macOS\ *.app/Contents/Resources/createinstallmedia \
--volume /Volumes/MyVolume \
--nointeraction
这里的 /Volumes/MyVolume 是已经格式化好的 U 盘卷。createinstallmedia 会把安装器 App 的核心文件、引导文件、启动固件全部部署到 U 盘，生成一个真正可引导的安装盘。
那什么时候才需要把 dmg 写入分区？当你手里拿的是“恢复镜像”或“整个系统镜像”，而不是“安装器”的时候。恢复镜像如 RecoveryHD.dmg、BaseSystem.dmg 在某些定制安装流程里确实要 asr 恢复到一个专门分区。但如果只是常规安装系统，直接下载完整安装器后跑 createinstallmedia 才是省事路径。这个顺序颠倒，是很多人卡在第一步的原因。
5. 动手之前的检查清单和收尾验证
5.1 写前校验镜像完整性，三行命令省下半天折腾
写入前花一分钟校验，比写完后花一个晚上排错效率高太多。macOS 和 Linux 下可以用 SHA-256 校验：
bash复制shasum -a 256 image.dmg
对比发布方给出的哈希值，不一致就重新下载。Linux 下如果拿到的是官网没有哈希值的 dmg，可以用 file 看一眼文件头，确认是不是真的 dmg。
另一个隐藏检查点是磁盘物理状态。写入大镜像前，建议先用 smartctl 或 macOS 磁盘工具的 First Aid 看一眼磁盘健康度，尤其对老机械硬盘。把 10GB 镜像写进一个坏道满布的机械硬盘，会浪费掉整个下午。机械硬盘分区写入前，先做一次扫描，把坏道问题暴露在写入之前。
5.2 写入成功不代表万事大吉，收尾验证的三个层次
验证不是拔盘看有没有盘符就结束，我习惯分三个层次做。
第一层，看分区表。macOS 下 diskutil list，Windows 下磁盘管理，Linux 下 lsblk -f，核心是确认目标分区依然存在、类型正确、容量没有被写穿。如果整个磁盘变成未分配空间，说明写的是整盘镜像，这可能是正常的，也可能是镜像本身分区表有问题的信号。
第二层，看文件系统。macOS 可以用磁盘工具的 First Aid 跑一遍，Linux 可以用 fsck 针对相应文件系统检查。这一步能发现因为中断写入导致的元数据损坏。第三层，如果目标是可引导设备，最直接的验证是把它接到一台测试机上，进固件设置看启动项里有没有出现对应设备标识。不要直接在主力机上反复插拔测试，万一引导失败导致数据丢失，代价太高。
5.3 我在实际操作中保持的几个习惯
最后聊点工具之外的东西。我写这类镜像的次数不算少，慢慢形成了一些习惯：能不用 dd 就不用 dd，能先用图形化就先图形化，只有在需要精确控制底层参数时才切到命令行。因为 dd 太“诚实”了，让它写什么就写什么，没有任何容错和确认机制，一个小数点打错就能把整块盘变成空盘。即便是老手，我也建议在 dd 命令末尾加一条:
bash复制sync
执行完 dd 之后，确保系统缓存真正落盘，这是很多坑的最后一个阀门。还有一个每次必提的点：写盘操作开始前，把目标盘原有的重要数据先复制走。这句话我说过无数次，但每次遇到求救的人，几乎都是因为没听这一句。写盘不像装软件，它没有撤销键，尤其 asr 和 dd 这种逐扇区复制的操作，完成之后不可能反悔。工具选对、参数看清、备份做好，这篇里的方法才能真正派上用场。