diskutil repairDisk仅能修复GPT分区表结构性错误（如主/备份表错位、校验和错误），前提是磁盘物理可读且未被覆盖；不能恢复文件、绕过加密，也不处理APFS容器或宗卷内部损坏。
diskutil repairDisk 能修什么，不能修什么
diskutil repairDisk 只能修复 GPT 分区表的结构性不一致（比如主/备份 GPT 表内容错位、校验和错误），前提是磁盘物理可读、分区数据未被覆盖、且系统能识别到 /dev/diskX 这个设备。它不恢复文件，不绕过加密，也不处理 APFS 容器或宗卷内部损坏。如果 diskutil list 显示磁盘为 Untitled、unmounted 或直接不出现分区条目，大概率是分区表已损，但需先确认是否只是“未挂载”而非“结构丢失”。
磁盘工具显示灰色/不可选，急救按钮灰掉怎么办
这是典型分区表层失效信号，不是宗卷问题，磁盘工具 → 急救 对它完全无效。此时不要反复点“急救”，它只会返回“无法检查”或卡住。必须进恢复模式操作：
- 关机后按
Command-R启动到恢复环境 - 打开终端，运行
diskutil list确认目标磁盘编号（如disk0） - 执行
sudo diskutil unmountDisk /dev/disk0（若提示 busy，用lsof +D /Volumes/xxx查占用进程） - 再运行
sudo diskutil repairDisk /dev/disk0
失败时常见报错：gpt: error: unable to open device '/dev/disk0': Operation not permitted —— 这说明 SIP 未关闭或磁盘被硬件锁定；No valid GPT found 则意味着主备 GPT 全损，repairDisk 已无能为力。
抹除时报“未能卸载硬盘”，根本原因和绕过方法
该错误本质是 macOS 正在运行的系统试图操作自身所在卷，内核禁止卸载。哪怕你在普通桌面打开磁盘工具点“抹掉”，只要目标是启动盘，就必然失败。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 唯一可靠路径：必须从外部环境操作 —— 进 Recovery（
Command-R）或网络恢复（Option-Command-R） - 若 Recovery 下仍报错，检查是否启用了 FileVault：用
diskutil cs list或diskutil apfs list看逻辑卷是否locked；未解锁前无法抹除 - 对 APFS 容器，别选“抹掉”单一分区，要选最顶层的物理磁盘（如
disk0），再点“抹掉”，格式选APFS，方案选GUID 分区图 - 仍失败？用终端强制卸载：
sudo diskutil unmountDisk force /dev/disk0（仅限 Recovery 终端，且风险略升）
repairDisk 失败后还能做什么
当 diskutil repairDisk 返回 No usable backup GPT table found 或直接静默退出，说明 GPT 元数据已不可逆损坏。这时候别再折腾命令行重建，容易把还能扫出来的数据彻底写坏。
- 立即停止任何写入操作，包括 Time Machine 新备份
- 用
dd if=/dev/disk0 count=1024 | hexdump -C快速确认开头是否有 APFS 签名（4e 58 53 42）或 HFS+（48 2b 2b 00），有则说明宗卷头尚存 - 优先尝试专业扫描工具（如 Disk Drill、R-Studio），它们跳过分区表，直接扇区级搜索宗卷结构
- 若曾启用 Time Machine，恢复模式下直接进“从时间机器备份恢复”，比修复分区更安全
真正棘手的不是命令会不会敲，而是分不清“分区表损坏”和“宗卷损坏”的边界——前者 diskutil repairDisk 可试，后者必须换思路。一旦跨过那个临界点，所有修复动作都得让位于数据抢救优先级。
