如何恢复被误操作损坏的GUID分区表？testdisk恢复遇阻求助

哎呀，这种手滑误操作真的太闹心了！还好你反应快立刻按^C终止了命令，虽然GUID分区表（GPT）被损坏，但这么短的时间里，命令大概率还没来得及覆盖太多关键数据，咱们一步步来尝试救回你的分区：

第一步：先锁定磁盘，确认当前状态 #

重要提醒：绝对不要对目标磁盘做任何写入操作！ 先打开终端，执行以下命令获取磁盘的只读状态信息：

diskutil list

gpt -r show /dev/disk2

加-r参数是强制只读模式，避免误操作进一步破坏残留的分区数据

这两个命令能帮你看清磁盘现在的分区结构，以及是否还残留着原分区的起始扇区、大小等关键标记。

第二步：用TestDisk尝试自动恢复GPT分区表 #

如果你之前用TestDisk遇到了问题，试试按这个标准流程走：

1. 启动TestDisk，选择Create新建一个日志文件（方便后续排查问题）
2. 精准选中你的目标磁盘/dev/disk2（别选错其他磁盘！）
3. 分区类型选择EFI GPT（和你原来的分区表类型一致）
4. 选择Analyze -> Quick Search，TestDisk会快速扫描磁盘上的残留分区痕迹
5. 扫描结束后，如果列表里出现了你原来的分区，先确认分区大小、类型是否匹配（比如HFS+分区的类型标记是AF00）
6. 选中疑似原分区的条目，按P可以预览分区内的文件，确认是不是你需要的数据
7. 确认无误后，按Write把恢复后的分区表写入磁盘，然后按Q退出TestDisk

如果快速搜索没找到，别放弃，试试Deeper Search——它会逐扇区扫描磁盘，虽然耗时更长，但能找到更隐蔽的残留分区信息。

第三步：备用方案——手动修复GPT分区表 #

如果TestDisk没成功，你可以尝试用gpt命令手动恢复（前提是你从第一步的命令里找到了原分区的参数）：

1. 先卸载整个磁盘，避免挂载冲突：

diskutil unmountDisk /dev/disk2

2. 确认磁盘的扇区大小（通常是512或4096字节）：

diskutil info /dev/disk2 | grep "Block Size"

3. 假设你查到原分区起始于扇区4096，大小为100000000扇区，类型是HFS+（标记为AF00），执行以下命令添加分区：

sudo gpt add -b 4096 -s 100000000 -t AF00 /dev/disk2

划重点：这里的-b（起始扇区）、-s（扇区数）、-t（类型标记）必须和你实际查到的原分区参数一致，绝对不能瞎填！

第四步：验证恢复结果 #

完成操作后，执行diskutil list查看分区是否恢复，然后尝试挂载分区：

diskutil mount /dev/disk2s1

如果能成功挂载，并且里面的文件都完好无损，那你就成功把数据救回来了！

如果以上方法都没奏效，千万别再对磁盘做任何写入操作，立刻停止使用它，考虑联系专业的数据恢复服务——不过你这种极早中断的情况，大概率用前面的方法就能解决问题。

内容的提问来源于stack exchange，提问作者voices