直接讲结论：误删Ubuntu分区导致开机卡进grub，这个局是可以破的，而且修复思路并不复杂。核心问题是引导链断了，Ubuntu删了，但电脑固件仍然优先去找GRUB，GRUB又找不到已消失的Ubuntu内核，于是停在这个黑底命令行界面等你手动处理。
我处理过不少这类双系统事故，从最初的满头大汗到后来十几分钟搞定，中间踩过的坑和总结出的正确路径，都在这篇文章里。如果你正对着一个只有grub>提示符的黑屏发愁，或者担心以后遇到同样问题，这篇文章能帮你省下大量折腾时间。
1. 事故现场还原：为什么删掉Ubuntu分区会黑屏进grub
先搞清楚你屏幕上到底是什么状态。开机后没有进入系统选择菜单，而是直接进入一个黑底白字的界面，底部一行grub>或Grub rescue >之类的提示符，这就是GRUB（Grand Unified Bootloader）在向你求救。它不是死机，而是在等指令。
双系统引导的正常流程是这样的：电脑开机后，主板固件（UEFI或Legacy BIOS）根据启动顺序找到引导设备，然后执行引导加载器。安装Ubuntu时，它会接管引导权，把GRUB写入EFI系统分区或主引导记录。GRUB启动后展示系统列表，里面有Ubuntu和Windows，你选哪个就加载哪个的内核。
问题出在你直接删掉了Ubuntu的根分区（或整个Ubuntu相关分区）。此时电脑固件不知道Ubuntu已经没了，仍然按既定路径找到GRUB，GRUB按配置文件去查找Ubuntu的内核，结果发现文件系统没了、内核文件也没了。它找不到有效的启动项，只能停在那里，把命令行界面扔给你。
也有一种变体，你看到的是GRUB的正常菜单，但选择Ubuntu后提示error: no such partition或file not found这类信息。这种情况同样是因为GRUB指向的路径不存在了。如果菜单里压根没有Windows条目，说明GRUB的配置文件（grub.cfg）里虽然曾检测到Windows Boot Manager，但现在因为分区变化，它没能力自动更新，也就没把Windows项列出来。
这里有个关键认知：GRUB不是操作系统，它只是个引导器。它的工作就是找到内核并加载它。如果找不到，它不会自己去修复，也不会帮你联系Windows的引导程序。它的“保底设计”就是扔给你一个命令行，允许你手动输入指令去指定内核位置。这意味着，所有“进grub就完蛋了”的说法都是夸大其词，真正的问题是“怎么把引导权交还给Windows”。
在动手修复之前，你必须做一个判断：你的电脑是UEFI启动还是Legacy BIOS启动？这个判断决定了后续操作的核心思路和命令差异。一般在开机时进入主板BIOS/UEFI设置界面（通常按Delete、F2或F10，具体看主板品牌），查看启动模式选项。如果显示UEFI，就走UEFI修复路径；如果是Legacy，就走MBR修复路径。绝大多数近五年的新电脑都是UEFI模式，下文会重点覆盖，但Legacy路径也会一并交代。
2. 修复方案的总分总思路：先定位引导文件，再重建引导项
修复的核心逻辑可以这样概括：既然GRUB失去了工作能力（找不到Ubuntu内核），我们需要让它把引导权让出来，或者直接绕过GRUB，让电脑固件重新找到Windows的引导加载器。
先说原理，帮助你理解所有命令背后的意义。Windows在UEFI模式下的引导加载器是一个.efi文件，位于EFI系统分区（ESP）的EFI\Microsoft\Boot\bootmgfw.efi。主板固件通过NVRAM里的启动项记录来定位这个文件。正常情况下，你在BIOS启动菜单里能看到Windows Boot Manager这一项，它指向的就是这个efi文件。但安装了Ubuntu双系统后，GRUB可能把启动顺序调整了，让GRUB排第一位。等你删掉Ubuntu分区，GRUB损坏，NVRAM里可能还残留着“先启动GRUB”的记录，于是你被卡在grub界面。
有两种修复路径：
路径A：修复NVRAM启动项，直接指向Windows引导文件。这是最干净的方案。在GRUB命令行中手动指定加载Windows引导器，进入Windows系统，然后在Windows内部用工具重建或调整启动项。这种方式的好处是，不需要PE盘/U盘，只要能进入GRUB命令行就行。问题在于，如果你对GRUB不熟，手输命令容易出错。
路径B：用第三方介质（PE盘/Live USB）引导，重建Windows引导项。这是最稳妥的方案。做一张Windows PE启动盘或Ubuntu Live USB，从介质启动，然后在命令行里手动重建Windows引导记录和启动项。这个方法不依赖GRUB，本质上是让Windows把引导权抢回来。
我个人更推荐路径B，并会用一整节来讲透它，因为它的成功率高、对新手友好，而且能覆盖最坏的情况（比如grub命令行都进不去）。但路径A也很重要，有些场景下你手边恰好没有第二台电脑可以做启动盘，学会A能解决燃眉之急。
选择修复路径的依据就三条：手头有什么工具、是否能进入grub命令行、Windows引导文件是否完好。如果Windows引导文件还在，两条路都能走通；如果引导文件也坏了，必须走路径B甚至需要修复Windows引导文件本身。下面先讲路径A，因为它能让你最快脱离grub界面。
3. GRUB命令行下手工引导Windows：一条应急出口
如果你现在正盯着grub>提示符，不妨先试试这条路。GRUB自带一套手动命令机制，可以指定分区、指定文件路径来加载操作系统。
在GRUB下引导Windows的常见步骤是这样的：
grub> set root=(hd0,gpt1) grub> chainloader /EFI/Microsoft/Boot/bootmgfw.efi grub> boot这套命令的意思是：设置根分区为(hd0,gpt1)，然后链式加载Windows引导管理器文件，最后启动。问题在于，(hd0,gpt1)这个写法不是固定的，你得先确认Windows引导文件所在的EFI分区到底是哪个盘的第几个分区。可以先用ls命令列出所有分区：
grub> ls (hd0) (hd0,gpt1) (hd0,gpt2) (hd1,gpt1) ...然后逐个检查哪个分区里有EFI目录：
grub> ls (hd0,gpt1)/你会看到类似EFI/、System Volume Information/这样的输出，说明这个分区大概率就是EFI系统分区。接着确认一下：
grub> ls (hd0,gpt1)/EFI/Microsoft/Boot/如果显示bootmgfw.efi或bootmgfw.efi相关文件，恭喜你，引导文件完好的可能性很大。这时执行前面那三条命令就能进入Windows。
不过有几个坑我必须提醒你。第一，GRUB的磁盘分区编号是从1开始的，gpt1表示第一分区，和Windows里的“分区1”概念不同，别混淆。第二，如果你的Windows引导文件是bootmgfw.efi，路径就是/EFI/Microsoft/Boot/bootmgfw.efi，这个路径在绝大多数Windows安装中是一致的，但偶尔有人把引导文件放在了其他目录，需要用ls逐步确认。第三，输入命令时注意大小写和路径分隔符，GRUB对路径大小写敏感，efi和EFI是两个概念。
这套方法能让你临时进入Windows，但它治标不治本。进入Windows后，NVRAM里的引导顺序还是乱的，下次开机可能还会卡grub。因此进入Windows后，你还得做一件事：删掉或禁用GRUB的残留启动项，或者重建Windows Boot Manager为第一位。这需要在Windows的管理员命令行里操作，具体做法下一节会详细讲。
如果GRUB命令行显示error: unknown filesystem或ls看不到任何分区，别慌。这通常意味着GRUB对磁盘分区表的解析出了问题，可能是删分区导致的残留状态。直接走路径B吧，不要再在这里耗时间，因为手动命令的前提是GRUB还能读文件系统，如果它读不了，手动输入也无济于事。
4. 用Windows PE重建引导项：最稳的一条修复路径
PE盘是目前成功率最高的修复方式。它不依赖你硬盘上任何系统是否完好，只要主板能U盘启动就能干活。我来完整走一遍修复流程，每一步都说清楚为什么这么做。
4.1 准备一个能启动的PE盘
先准备一个U盘（建议8GB以上），在另一台正常的Windows电脑上下载PE制作工具。常见的方案有微PE、IT天空优启通、Hiren's BootCD PE等。这类工具会把Windows预安装环境写入U盘，启动后得到一个精简版Windows桌面，自带命令提示符、磁盘管理、文件资源管理器等基础工具。
如果你手边只有一台能联网的Ubuntu电脑，也可以下载Ubuntu Desktop ISO，用dd或Startup Disk Creator做一个Live USB，从Live环境进入后使用终端操作。但说实话，Windows PE在处理Windows引导文件的场景下更直观，因为bcdboot、bootrec这类工具是Windows原生的，而且PE下可以直接打开磁盘管理确认分区状态。
制作PE盘时注意一点：U盘会被格式化，务必提前备份U盘里的数据。制作过程中，BIOS启动方式要选对，如果你的硬盘是UEFI+GPT模式，PE盘的制作工具一般会同时支持UEFI和Legacy启动，但烧录完成后最好在BIOS设置里把U盘启动模式调整为UEFI，避免启动PE时模式不匹配导致U盘起不来。
4.2 进入PE后，先确认磁盘分区布局
从U盘启动进入PE桌面后，千万不要急着敲命令。先用PE自带的磁盘管理或DiskGenius看一眼磁盘现状。你要确认三件事：第一，Windows系统分区的盘符；第二，EFI系统分区是否存在及其盘符；第三，是否有MSR分区（微软保留分区）残留。
这里有个容易出错的点：PE环境下盘符分配和正常Windows环境下不一样，C盘不一定是系统盘。比如U盘启动时，U盘占用了一个盘符，Windows系统分区可能变成D盘或E盘。你在注册表、引导文件里看到的路径符号必须是实际盘符，所以每一步操作前都要核实清楚。我的习惯是打开磁盘管理，记下系统分区的实际盘符（假设为W）、EFI分区盘符（假设为S），然后全程用这两个盘符操作。
如果PE里磁盘管理没法给EFI分区分配盘符，别急着跳，先给它分配一个。方法是在磁盘管理里找到那个很小的FAT32分区（100MB到500MB之间），右键分配盘符。EFI分区一般显示为“EFI系统分区”或“恢复分区”，文件系统是FAT32。如果没有这个分区，说明你的系统可能不是标准的UEFI+GPT布局，那可能是Legacy+MBR模式，修复命令要换成bootsect或bootrec系列。
4.3 核心命令：diskpart激活EFI分区(如有必要) + bcdboot重建引导文件
进入PE的命令行（管理员模式），按顺序执行下面的命令。先说diskpart这一步，它负责把EFI分区设置为活动分区，并在必要时给它分配盘符。别小看这一步，很多修复失败都是因为EFI分区没有活动标记，主板根本没把它识别为可引导设备。
diskpart list disk sel disk 0 list partition sel partition 1 assign letter=S active exit解释一下每条命令的含义：list disk列出物理磁盘，sel disk 0选择系统所在的那块盘（根据大小和分区布局判断是哪块，别选错），list partition列出该磁盘分区，sel partition 1选中EFI分区（通常第一个分区就是），assign letter=S给它分配盘符S，active设置活动标记。如果你的EFI分区本身已经有盘符，assign那步可以省略，但active建议执行一次确保万无一失。
然后执行bcdboot重建Windows引导文件。这一步是整个修复的核心，它的作用是把当前Windows系统的引导文件（如bootmgfw.efi）复制到EFI分区，并在系统启动项里注册对应的Boot Manager。
bcdboot W:\Windows /s S: /f UEFI参数说明：W:\Windows指向实际的Windows系统目录，/s S:指定EFI分区的盘符，/f UEFI强制以UEFI方式写入。执行成功后输出“Boot files successfully created”，表示引导文件已经重建。如果输出Failure when attempting to copy boot files，通常是盘符搞错了或EFI分区空间不足（几乎不可能，EFI分区默认100M足够），重点检查盘符。
到这里，硬盘上的引导文件就搭建好了。如果你是从GRUB卡死状态直接进PE，到这里已经把Windows引导项重建了，把NVRAM里的垃圾启动项清一清就能生效。但如果你只是重建引导，没有清理旧启动项，可能会出现多个启动项并存或顺序不对的情况。别急，下一节专门说清理这个事。
4.4 用bootrec清理残留启动项(如适用)
如果你在用bcdboot之后重启发现启动菜单里还有Ubuntu残留项、或者又自动进了grub，说明NVRAM里还留着GRUB的启动记录。用bootrec清理一下。
在管理员命令行里执行：
bootrec /rebuildbcd这个命令会扫描所有磁盘，把Windows系统添加到引导配置数据（BCD）里。执行过程中它可能会让你选择是否把发现的Windows装入启动列表，选是（Y）即可。
再执行：
bootrec /fixmbr这个命令重写主引导记录，主要针对Legacy BIOS模式，在UEFI模式下其实用不上，但执行它也无害。然后执行：
bootrec /fixboot这个命令重写引导扇区。注意在PE下执行fixboot可能会提示“拒绝访问”，这是因为部分PE版本对引导扇区写入有限制。真遇到的时候，可以重启进入Windows后再以管理员身份运行一次。
最后在PE下重启，拔掉U盘。如果一切正常，你会看到Windows启动管理器，选择Windows，进入系统。如果还是进grub，那大概率是BIOS启动顺序里UEFI启动项没把Windows Boot Manager排到第一位，或者NVRAM里还残留着GRUB启动项，需要在BIOS设置里手动调整启动顺序，或者进入Windows后用bcdedit清理残留。
4.5 其他PE可用的修复命令
上面三件套是最常见的，但遇到复杂情况时，还需要用到这些命令：
bcdedit /set {bootmgr} displaybootmenu yes：开启启动菜单显示。有些Windows版本默认不显示启动菜单，修复后如果发现直接进系统界面，但你想留一个选择菜单，可以用这条命令。bcdedit /delete {GUID} /f：删除指定启动项。GUID可以通过bcdedit /enum查看，适用于清理里残留的“Ubuntu”或“grub”启动项。dism /Get-WindowsInfo /Image:W:\：检查映像信息。PE损坏或系统文件异常时，可以用来排查系统是不是健康。
每个命令都有自己的适用场景，不一定每条都用得上，但知道它们的存在会让你在处理异常时更从容。
5. 从GRUB提示符直接抢救：不依赖PE的备选战术
前面说过，如果你能进入GRUB命令行，而且GRUB还能识别磁盘和分区，那么可以直接通过GRUB启动Windows。但这种方式有两个大前提：GRUB能读取EFI分区的文件系统，以及Windows引导文件完好。在多数“删掉Ubuntu”的案例里，这两个前提是满足的，因为删掉的是Ubuntu根分区，EFI分区还在，Windows引导文件也没被动过。
如果你的GRUB版本较新，还支持search --file定位文件，那就更省心。可以直接这样：
grub> search --file /EFI/Microsoft/Boot/bootmgfw.efi grub> set root=第一行命令会直接输出包含目标文件的分区描述，比如(hd0,gpt1)，接下来设置根分区为它，再做链式加载。这比手动猜分区号高效得多。
还有一种特殊场景值得提一下：如果你能看到GRUB菜单，里面也有Windows条目，但选择Windows后会重新跳回grub菜单或报错。这种情况多数是GRUB配置文件指向的Windows引导器路径不对，或磁盘分区变化导致路径失效。可以尝试临时在GRUB命令行里手动引导，或者直接进入Windows后用工具重装/修复GRUB（比如用Boot-Repair），让它重新检测引导项。但既然你要解决的是“Ubuntu被删了”的残留问题，我反而建议别重装GRUB，理由很简单：Ubuntu都不在了，留着GRUB当引导管理器要么没用，要么还会引起新的冲突，直接把Windows Boot Manager设为唯一引导项才是最省心的状态。
如果你的GRUB是rescue模式（提示grub rescue>而不是grub>），说明GRUB连自己的配置文件grub.cfg都没读到，文件系统解析失败。此时用ls确认哪个分区有EFI目录，然后insmod加载必要模块，再手动引导。但说实话，在rescue模式下折腾，成功率远不如直接用PE盘。如果你手头有PE盘，直接跳去章节4，别在rescue模式里死磕。
6. 修复完成后的善后处理与预防建议
修复完成后，还有几件善后工作要做，否则会面临“过几天又出问题”的风险。
6.1 进入Windows后先做的事：清理冗余引导项与备份引导记录
进入Windows桌面后，以管理员身份打开命令提示符，执行：
bcdedit /enum firmware这个命令会列出所有UEFI固件启动项，里面可能有“Ubuntu”或“grub”项。如果看到，记录下它的GUID（一长串包含大括号的字符串），然后执行：
bcdedit /delete {GUID} /f把残留的Ubuntu引导项清掉，这样以后开机就不会再有GRUB的干扰。这样做还有一个附带好处：Windows启动菜单会变得干净，不再出现一个点了必报错的“Ubuntu”条目。
接着备份引导记录。打开“运行”（Win+R），输入msinfo32，在“系统摘要”里找到“BIOS模式”，如果是UEFI，就可以放心地把当前状态视为一个干净的、可复现的基线。在PE下执行过bcdboot后，引导文件已经重新生成，所以现在最值得做的是用备份工具把这套引导状态保存下来。Windows自带的“备份和还原”或DISM命令都能做映像备份，但更简单的方式是保留一份EFI分区的内容复制到一个本地磁盘文件夹里。万一以后引导再出问题，可以用PE盘重启，把备份内容放回去。
6.2 给还在用双系统的人：如何避免下次误伤引导
如果你修复完，以后还想继续用双系统（比如以后又重新安装了Ubuntu），这里有几个防止再出事的习惯：
- 删除Ubuntu分区前，先用
bcdedit /set {bootmgr} path \EFI\Microsoft\Boot\bootmgfw.efi把默认引导项改为Windows Boot Manager，确保删除Ubuntu后系统能直接引导Windows。这是我个人强烈推荐的一步，操作很简单，但能避免90%的grub卡死问题。 - 删除分区时，只删Ubuntu的根目录分区（例如挂载点为 / 的分区），保留EFI系统分区里由Ubuntu创建的目录（通常是
/EFI/ubuntu/），让它留在那里，等确认Windows正常后再清理。别一上来就把整个EFI分区格式化，那样会连Windows引导文件一起干掉，麻烦得多。 - 重要数据都装在Windows分区里的，Ubuntu分区保持轻量化，这样删Ubuntu时只需面对系统文件，不需要先抢救数据。如果你在Ubuntu里有重要文件，删分区前先转移到U盘或Windows分区。
- 养成每次重大系统变更前做完整磁盘备份的习惯。Windows下面可以用Macrium Reflect或傲梅备份，免费版就够用。
6.3 关于开机菜单的另一种解决思路：在BIOS里直接设置启动顺序
如果你不想用命令行，也不想进Windows再做一遍，还有一条更直接的路线：开机进BIOS/UEFI设置，手动把Windows Boot Manager调整为第一启动项，把GRUB对应项禁用或调后面。这样开机就会直接进Windows，完全绕过GRUB。这个方法本质上不是修复，只是“绕过”，但它确实解决了“开机进grub”的表层问题。不建议作为唯一手段，因为NVRAM里的垃圾项还在，以后会出现奇怪的启动项冲突；但如果你的Windows引导文件本来就完好，这方法又快又干净。我一般把它用作“修复完成后的最后一道保险”，先修好引导文件，再去BIOS里把Windows设为第一，双保险。
7. 虚拟机环境下的特殊场景：VMware/VirtualBox里误删Ubuntu怎么办
如果你是在虚拟机里玩双系统（比如VMware中装了Windows作为主系统，又装了Ubuntu），结果操作失误导致无法启动，处理思路和实机相同，只是进入PE的方式稍有不同。
VMware等虚拟机的BIOS固件可以设置为UEFI，磁盘分区布局可能是GPT，这时候修复步骤和实机一模一样。区别在于“U盘启动”这一步。理论上VMware可以给虚拟机挂载U盘启动，但兼容性时好时坏。更稳妥的做法是：创建一个新的虚拟机，分配一个虚拟磁盘（或者挂载旧虚拟磁盘），然后把系统安装ISO文件作为虚拟光驱引导，从ISO启动进入PE环境（比如下载一个WinPE的ISO文件），在PE里对原虚拟磁盘执行diskpart和bcdboot修复。
如果你用的是VirtualBox，操作逻辑类似。虚拟机的启动管理器里可以调整光驱优先引导，然后把PE ISO挂载为光驱，从它启动进入PE环境。修复完成后，把光驱卸载，启动顺序改回硬盘启动即可。
这里有一个坑：虚拟机的EFI分区可能比较小或没被正确初始化。在VirtualBox的VBoxManage命令里可以设置EFI固件，但默认设置可能不严格按UEFI方式引导。如果你发现自己这台虚拟机用的是Legacy BIOS引导，那么修复命令也要跟着变，采用bootsect或bootrec /fixmbr这类Legacy方式，而不是bcdboot的UEFI参数。判断方法是进入BIOS/EFI设置，看有没有UEFI字样，或者看虚拟磁盘是不是GPT分区表。
还有一个容易踩的坑是虚拟磁盘从Windows主机里复制粘贴导致引导漂移。如果你把虚拟磁盘VHD/VMDK文件换成移动盘，再用挂载方式修文件，诱因往往就是分区盘符变化。所以无论是实机还是虚拟机，修复前一定要用diskpart确认每个分区的身份，不要凭记忆猜。
对于VMware用户，还有一个低级但烦人的错误：启动虚拟机时卡在GRUB命令行，很多人以为是虚拟机坏了，其实是VMware的UEFI启动顺序里GRUB排在第一、Windows Boot Manager排在第二，而GRUB功能损坏。这时候在VM里进入虚拟机的BIOS（开机按Esc/F2），把Windows Boot Manager调成第一启动项，往往就能直接绕过GRUB启动Windows。当然，这只适合Windows引导文件本身完好的情况，只能临时绕过。
8. 最后的实操心得与几点注意事项
文章写到这里，我把整个修复过程按逻辑排了一遍。最后分享几条我折腾多次后的真实体会，它们比任何命令都更重要：
第一，修复前先冷静确认分区布局。我见过太多人一进grub界面就慌，连盘符都没核实就敲bcdboot，结果输出错误，以为系统彻底完了。其实多花两分钟把磁盘管理和分区表看清楚，后面每一步都是顺理成章。
第二，bcdboot是关键中的关键，但它的执行前提是EFI分区存在且格式正确。如果你的EFI分区因为误操作被格式化了，重建引导文件的难度会直线上升。但也不是没救：在PE里用diskpart重新创建EFI分区（需要压缩其他分区腾空间，或利用现有未分配空间），再用bcdboot写入。不过这种操作有数据风险，如果遇到，我的建议是找专业数据恢复工具先备份重要文件，再做分区调整。
第三，如果你完全不熟悉命令行，又不放心自己操作，还有一个图形化工具可以救急：Boot Repair Disk。它是一个可启动的Linux Live CD，启动后运行Boot Repair，会自动扫描并修复引导问题。但请注意，它是一个Linux环境的修复工具，倾向于把GRUB重新装回启动项首位。这正好和你的需求相反——你要的是让Windows接管引导。所以建议在它生成的修复选项里手动检查“Restore MBR”或“Restore Windows boot loader”，或者干脆用它进Live环境，再从Live环境里挂载EFI分区手动清理。这个工具更适合“Windows引导坏了但Ubuntu还在”的场景，而你现在是“Ubuntu没了、Windows要接管”，所以主要参考它的Live环境功能。
第四，修复完成后不要立刻删除PE盘或Live U盘，至少在正常进入Windows并运行了几天、确认引导稳定后再清空。我遇到过修复完当天启动正常，第二天又进grub的情况——最后查出来是主板NVRAM里残留了多个启动项，Windows Boot Manager和GRUB互相竞争，需要等Windows完全启动后执行bcdedit清理才能根除。保存一个工具盘，相当于给自己留了一条退路。
第五，重要数据永远是第一优先级。再怎么强调引导修复技巧，都不如一句“修复前先备份数据”来得实在。不管是PE盘还是Live USB，启动后第一时间把系统盘里的重要文件复制到外置设备，然后再做引导修复。文件能回来，系统可以重装，但数据丢了就是真的没了。
如果你现在正对着grub>黑屏界面发愁，按照这篇文章的流程走一遍：先确认GRUB能不能通过手工命令临时引导Windows，可以就先用起来；不行就用PE盘重建引导项，清理残留，设置启动顺序。整个流程大约需要半小时，熟练后十分钟内就能搞定。修复成功的那一刻，你会觉得这事其实并不神秘——它只是引导链路里一环坏了，接回去就好了。
