磁盘工具“急救”仅修复宗卷及容器层面的文件系统逻辑错误，无法修复gpt分区表损坏、core storage逻辑卷组结构性损坏或物理层问题。
磁盘工具的“急救”对分区表错误完全无效，也修不了 Core Storage 逻辑卷组（LVG）的结构性损坏；它只管宗卷和容器层面的文件系统逻辑。
磁盘工具“急救”能修什么、不能修什么
“急救”本质是调用底层 fsck_apfs 或 fsck_hfs 工具，作用范围严格限定在：已识别的 APFS 容器内宗卷、APFS 容器本身、或 HFS+ 卷的目录结构与元数据。它不会碰 GPT 分区表头、不读写 LVG 元数据块、也不校验物理扇区映射关系。
常见误判场景包括：
- 磁盘在磁盘工具中显示为空白或仅显示物理设备名（如
APPLE SSD AP0512M），无任何disk0s1分区条目 → 这是 GPT 损坏，“急救”按钮灰色不可点 -
diskutil cs list显示LVG Status: corrupted或offline→ “急救”对 LVG 条目根本不可见，无法选中操作 - 启动时卡在禁止符号（），恢复模式里看不到启动磁盘 → 多数源于分区表丢失，图形界面连设备都列不出来
修复 GPT 分区表错误必须用 diskutil repairDisk
当 diskutil list 报出 gpt: error、分区大小为 0、或出现 Invalid 标记时，说明主/备份 GPT 表不一致或部分损坏。此时可尝试安全重建：
- 先卸载整盘：
sudo diskutil unmountDisk /dev/diskX（X是磁盘编号，如disk0，不是分区号） - 执行修复：
sudo diskutil repairDisk /dev/diskX - 该命令不擦除数据，仅比对并同步主/备份 GPT 表；若两者全损，则会失败并提示“no valid partition map found”
- 成功后重启进恢复模式，再打开磁盘工具——此时应能看到完整分区层级
注意：repairDisk 不适用于被 Windows 工具重写过 MBR/GPT 混合表的磁盘，那种情况需用 gpt 命令手动重建，风险极高。
Core Storage 逻辑卷组异常只能靠终端命令干预
macOS 10.12 及更早系统（含 FileVault 或 Fusion Drive）依赖 Core Storage，其 LVG 状态异常无法通过图形界面修复。关键判断依据是 diskutil cs list 输出：
- 若 LV 显示
locked且有 UUID，先试解锁：sudo diskutil cs unlockVolume LVUUID；失败提示 “invalid key” 表示密钥丢失，diskutil无绕过能力 - 若 LVG 显示
corrupted但未报 “missing metadata”，可尝试sudo diskutil cs repairVolume LVUUID，但成功率极低，且可能加剧元数据错位 - 一旦
diskutil cs list中 LVG 的LVG UUID为空或Online: No，基本意味着 LVG 结构已不可恢复，只能靠备份还原
APFS 容器不存在 LVG 概念，所以 macOS 10.13+ 用户遇到类似问题，大概率是容器损坏而非 LVG，应优先运行 diskutil apfs verifyContainer 和 sudo diskutil apfs repairContainer。
APFS 容器与宗卷错误的修复边界很窄
APFS 下多数“无法挂载”“快照异常”问题看似严重，实则常由容器元数据轻微错位引起。但要注意：repairContainer 仅修正容器头、区块映射等结构信息，不恢复文件内容；repairVolume 也只处理单个宗卷的 B-Tree 和快照链一致性。
- 若
diskutil verifyVolume /dev/diskXsY报Snapshot mismatch或Invalid checkpoint，说明快照链断裂，此时repairVolume很可能失败，需用tmutil deletelocalsnapshots清理快照后再试 -
repairContainer对“重叠的扩展区分配”类错误无效，这类提示往往指向硬件故障，diskutil会建议立即备份并更换磁盘 - 所有
repair*命令都不保证数据不丢失，尤其在多次断电、强制拔线后出现的错误，底层块分配可能已紊乱
真正容易被忽略的是：修复顺序必须从最底层往上——先 repairDisk（GPT），再 repairContainer（APFS 容器），最后 repairVolume（宗卷）。跳过中间层直接修宗卷，等于在地基裂缝上刷墙漆。
