磁盘工具对扩容中断无效，因其仅修复文件系统逻辑错误，无法处理GPT分区表结构异常（如APFS容器边界错位、ESP丢失或重叠）；正确路径是进恢复模式用diskutil重建分区表、补全EFI引导链并导出数据。
磁盘工具无法修复 macos 分区扩容中断引发的引导记录损坏。这类问题本质是分区表结构异常（如 gpt 中 apfs 容器边界错位、esp 分区被覆盖或丢失），而非文件系统逻辑错误，超出了“急救”功能的作用范围。
为什么磁盘工具对扩容中断无效
分区扩容中断（例如拖拽宗卷大小时断电或强制退出）常导致：
- GPT 分区表中容器起始/结束扇区与实际 APFS 结构不一致，出现重叠或间隙
- EFI 系统分区（ESP）被误删、压缩或写入异常，导致 UEFI 固件找不到 boot.efi
- macOS 启动所需的预boot、recovery 和 data 宗卷 UUID 关联断裂，但磁盘工具只校验单个卷元数据，不验证跨卷链路
- “急救”按钮在恢复模式中显示灰色或运行后提示“无法检查”，说明问题位于分区表层，非 volume 层级
正确修复路径：从恢复环境用 diskutil 重建分区结构
必须进入 macOS 恢复模式（开机按 ⌘ + R），打开终端操作：
- 执行 diskutil list 确认目标磁盘（如 disk0）及异常分区标识（常见为 disk0s1 是 ESP，disk0s2 是 APFS 容器）
- 若 disk0s1 缺失或大小异常（如仅 1MB），需手动重建 ESP：
sudo diskutil eraseVolume FAT32 EFI disk0s1
再用 sudo bless --mount /Volumes/EFI --setBoot --legacy 注册（仅限需要 legacy 支持的老设备） - 若 disk0s2 显示 “Invalid” 或 offset 错乱，先卸载整盘：
sudo diskutil unmountDisk /dev/disk0
再尝试修复 GPT 表：
sudo diskutil repairDisk /dev/disk0 - 修复成功后，重新挂载容器并验证：
diskutil apfs list → 查看容器是否 online
diskutil verifyVolume /dev/disk0s2 → 确认无底层错误
补全引导链：让系统真正可启动
分区结构正常后，还需恢复引导组件：
- 确保 ESP 已挂载为 /Volumes/EFI，且内含 EFI/APPLE/BOOT/BOOTx64.EFI 和 EFI/APPLE/EXTENSIONS/Drivers/AppleImageLoader.efi
- 在恢复终端中运行：
sudo bless --folder /Volumes/Macintosh\ HD/System/Library/CoreServices --bootefi --create-snapshot
（将 Macintosh HD 替换为你的系统宗卷名） - 若使用 FileVault，需额外解锁逻辑卷：
diskutil apfs unlockVolume [UUID]（UUID 来自 diskutil apfs list 输出）
失败后不要反复抹除，优先导出数据
若 repairDisk 返回 No valid GPT found 或容器始终 offline：
- 立即停止所有写入操作
- 用外接硬盘+目标盘做只读挂载（如通过 Linux Live USB 运行 apfs-fuse），拷出重要数据
- 确认硬件健康：smartctl -a /dev/disk0（需在 Linux PE 下）排除坏道诱发的写入失败
- 最后再考虑抹盘重装：
在恢复模式磁盘工具中，选最顶层物理磁盘（如 disk0）→ 抹掉 → 格式选 APFS，方案选 GUID 分区图
