企业官网建设流程全解析

搞清楚启动流程之前，先说一个真实经历

前阵子帮朋友处理一台老工作站，配置不算差，但装Windows时死活进不了安装界面。折腾一晚上，最后发现问题是主板默认的启动模式是Legacy，而硬盘分区表却是GPT，Windows安装程序卡在“无法安装到这个磁盘”的提示上。这台机器本身是支持UEFI的，只要进BIOS把启动模式切过来，重新分区就能正常装。但问题是，很多人根本不知道UEFI和Legacy的区别，也不知道Windows在两种模式下走的是完全不同的启动路径。

这个案例特别典型。日常工作中我见过太多类似的情况：有人把UEFI引导U盘格式化成NTFS结果无法引导，有人在纯UEFI主板上用传统方式装系统导致无法开机，有人升级固件后启动项丢失只能干瞪眼。这些问题的根源，基本都是对UEFI和Windows启动流程缺乏整体认识。今天我就把这条链路完整拆一遍，从固件上电到Windows桌面出现，中间到底发生了什么、每一步卡住是什么症状、该怎么排查，一次性讲清楚。

这篇文章适合三类人看：一是系统运维和装机运维，需要快速定位启动故障；二是搞嵌入式或固件开发，需要理解UEFI规范在真实系统里怎么落地；三是纯粹想弄明白自己电脑启动原理的爱好者。不管你是哪个方向，我尽量用大白话把这条链路讲透。

1. 启动世界的分水岭：UEFI和Legacy本质上是两套完全不同的规则

很多人把UEFI和Legacy当成同一种东西的两种叫法，其实这是两套设计思路截然不同的固件体系。Legacy BIOS从上世纪70年代末的IBM PC时代延续下来，用了将近四十年，而UEFI是在2000年后逐步成型的新规范，到今天已经成为x86平台的事实标准。理解这两者的差异，是搞懂整个启动流程的前提。

1.1 Legacy引导为什么注定会被淘汰

传统BIOS的引导逻辑其实非常“简陋”：上电后，CPU从固定地址执行固件代码，经过自检把硬件初始化一遍，然后扫描磁盘的第一个扇区，也就是MBR（主引导记录）。MBR只有512字节，里面存着一小段引导代码和分区表，固件把这512字节加载到内存后就直接跳过去执行。之后的事情，BIOS基本就不管了，全交给MBR里的引导程序，由它再去读取活动分区的引导扇区，再一步一步把操作系统加载起来。

这套机制的问题很突出：第一个问题是512字节的引导代码能做的事情极其有限，引导程序为了兼容MBR的限制，只能把后续代码拆成一段一段放在不同位置，启动链路越长越容易出问题；第二个问题是MBR分区表最多只能分4个主分区，超过2TB的磁盘无法完整利用；第三个问题是这种引导方式没有任何安全性校验，引导链上的任何一环被篡改，系统启动后就是带毒状态。前几年大量蠕虫病毒就是通过改写MBR来实现开机自启动的，杀毒软件面对这种攻击也很被动。

1.2 UEFI更像一个微型操作系统

UEFI和BIOS相比，最大的变化是它本身就是一个完整的运行环境。UEFI固件里有自己的驱动模型、内存管理、文件系统支持（FAT格式是强制支持的）、网络协议栈，甚至内置一个命令行解释器，也就是UEFI Shell。固件不再是那个只能做“加载512字节然后放手”的角色，而是可以在启动阶段加载各种驱动、访问磁盘分区上的文件、执行可执行的EFI程序，然后把启动权根据预设规则交给真正的引导加载器。

打个比方，Legacy BIOS像是学校门口的门卫，看到你拿着学生证就放你进去，进去之后你去哪儿、干什么，他完全不关心；UEFI则像是机场安检加地勤调度，它不仅确认你的身份，还会给你指定登机口、检查你的行李、确认航班信息，再把你交接给机组。这套流程虽然更复杂，但更可控，也更安全。

1.3 模式切换的兼容层：CSM模块

纯UEFI固件理论上不再支持Legacy引导，但实际主板上几乎都保留了一个兼容层模块，叫CSM（Compatibility Support Module）。CSM的作用是在UEFI固件里模拟出一个传统BIOS环境，让那些只写了MBR引导代码的旧系统（比如Windows 7）仍然能启动。这也是为什么你会看到很多BIOS设置里有“UEFI Only”“Legacy Only”“UEFI with CSM”这几个选项。

如果你的主板支持UEFI，但你在设置里看到CSM相关选项，说明固件做了兼容处理。开了CSM，启动走Legacy路径；关掉CSM，走纯UEFI路径。日常装机时我强烈建议直接关掉CSM，因为开启CSM会降低启动安全性，有些情况下还会导致UEFI启动项异常重复。除非你确实需要启动一个老系统，否则没有理由开着它。

2. UEFI启动链路的完整时序：从上电到操作系统接管

现在进入正题，看看UEFI标准的启动流程里，硬件和固件到底做了哪些事。这里我以典型的x86平台为例，按照UEFI规范分成七个阶段来说。

2.1 七个阶段，一次讲透

UEFI规范把启动过程分成七个明确的阶段，从按下电源键开始依次是：SEC（安全验证）、PEI（EFI前期初始化）、DXE（驱动执行环境）、BDS（启动设备选择）、TSL（临时系统加载）、RT（运行时）、AL（灾难恢复）。

第一个阶段是SEC，这个阶段做的事情极简单：CPU和主板一上电，首先执行的是一小段几乎不可修改的安全代码，它的任务是验证后续固件代码的完整性，顺便把CPU缓存配置成可以当内存用的临时仓库。为什么要用CPU缓存当内存？因为此时内存条还没初始化，代码需要有个地方暂存数据。这个阶段如果出错，机器就是完全黑屏，连厂商Logo都不显示。

第二个阶段是PEI。此时内存仍然处于初始化的早期，PEI阶段的核心任务是把内存控制器配置好。每个内存控制器都有自己的一套初始化时序参数，这些参数一般存放在主板上的SPD芯片里，PEI读取SPD，按照里面的延迟参数配置内存控制器。这个阶段出问题，最常见的现象是黑屏、蜂鸣器报警，或者开机后不断重启。如果你遇到内存相关的问题，基本可以锁定在这个阶段。

第三个阶段是DXE，这是整个UEFI固件中最庞大的部分。进入DXE阶段时，内存已经完全可用，固件开始加载各种驱动：主板芯片组驱动、SATA/RAID控制器驱动、USB控制器驱动、显示输出驱动、网卡驱动等。DXE阶段做完，固件就能看到一个基本可用的硬件环境了。此时如果你按Del键、F2键或F12键能进入BIOS设置界面，说明DXE已经完成，固件界面已经跑起来。

第四个阶段是BDS，也是和日常装机关系最密切的阶段。BDS负责读取UEFI启动管理器中的启动项配置，然后按照顺序尝试启动每一个启动项。启动项指向的一般是一个EFI应用，比如磁盘上的\EFI\Microsoft\Boot\bootmgfw.efi，这个文件就是Windows Boot Manager。如果某个启动项启动失败，BDS会尝试下一个；全部失败就会出现你常见的“找不到启动设备”或直接黑屏。

第五个阶段是TSL，也就是操作系统引导加载器开始执行的阶段。Windows Boot Manager启动后，系统已经从固件控制权过渡到了引导加载器控制。第六个阶段是RT，操作系统内核完全接管，固件进入运行时服务模式，操作系统可以通过UEFI运行时服务接口读取固件设置、操作NVRAM变量。第七个阶段是AL，纯粹用于灾难恢复，当系统无法正常启动时，固件会尝试从备份固件或恢复分区加载一个最小化的恢复环境。

2.2 各阶段异常的外观表现

从实际观测角度来看，不同阶段的异常表现差异很大：

• SEC/PEI阶段异常：黑屏、无任何显示、风扇转但屏幕不亮、蜂鸣代码报错、反复重启。

• DXE阶段异常：能显示厂商Logo但卡住不动、按不进BIOS设置、USB键盘鼠标无响应。

• BDS阶段异常：显示Logo后提示找不到启动设备、自动进入网络启动、多个启动项重复、直接跳到UEFI Shell。

• TSL阶段异常：出现Windows图标但转圈后蓝屏、加载完引导后直接重启、提示文件损坏。

日常装机遇到启动问题，先判断是哪个阶段的异常，能省下大量排查时间。比如能进BIOS但进不了系统，说明PEI和DXE基本没问题，问题在BDS或者之后的阶段；如果连BIOS设置界面都进不去，那就要从硬件和固件层面找原因了。

3. Windows引导链路的细节：bootmgfw.efi、winload.efi与内核启动顺序

硬件的启动链路结束后，接力棒交到了Windows这边。很多人不知道的是，Windows的引导过程和UEFI固件的引导过程是两个独立的世界，它们之间通过一个特定的EFI应用来“握手”。这个文件就是bootmgfw.efi。

3.1 三个关键文件和各自职责

Windows在UEFI模式下启动，涉及三个核心文件：bootmgfw.efi、winload.efi、winresume.efi。这三个文件的职责边界非常清晰。

bootmgfw.efi是Windows Boot Manager，存放在系统分区（ESP）的\EFI\Microsoft\Boot目录下。它的作用是读取BCD（启动配置数据）数据库，里面记录了所有可用的Windows启动条目：要启动哪个系统、系统分区在哪个磁盘、内核文件路径是什么、有没有开启调试选项等。BCD可以被理解成Windows启动的指挥所。

winload.efi是Windows操作系统加载器，存放在系统分区的\Windows\System32\Boot\winload.efi。bootmgfw.efi根据BCD指向的路径找到winload.efi，加载并执行它。从这一刻起，固件提供的服务就不再是核心了，winload.efi开始负责初始化Windows内核环境，它加载硬件抽象层（HAL）、读取注册表配置单元、初始化内核，最终把控制权交给ntoskrnl.exe。

winresume.efi则是负责系统休眠恢复的组件。如果你用的是休眠而不是关机，再次开机时bootmgfw.efi会检测到系统分区中存在休眠镜像（hiberfil.sys），然后直接加载winresume.efi来恢复休眠前的系统状态，而不会走完整的内核启动流程。这也是为什么休眠唤醒速度远快于正常开机。

3.2 从BCD到内核的完整链条

一个典型的UEFI模式启动Windows 10/11流程如下：

1. 固件BDS阶段读取NVRAM里的启动项，找到“Windows Boot Manager”这个启动项，它的路径指向\EFI\Microsoft\Boot\bootmgfw.efi。
2. 固件加载bootmgfw.efi到内存并执行。
3. bootmgfw.efi读取系统分区（ESP）中的BCD数据库，根据默认启动条目确定目标系统。
4. bootmgfw.efi判断系统是否处于休眠状态，如果是则加载winresume.efi，否则继续。
5. bootmgfw.efi加载\Windows\System32\Boot\winload.efi，并传入必要的启动参数。
6. winload.efi加载ntoskrnl.exe、hal.dll、关键驱动程序，初始化内存管理、进程管理和对象管理。
7. 内核接管后，启动会话管理器（smss.exe），加载剩余注册表，再启动winlogon.exe进入登录界面。

3.3 为什么ESP分区必须是FAT32

这个问题网络上讨论非常多，也是装机时最常见的坑。UEFI规范明确规定，UEFI固件必须支持读取FAT格式的分区，但不需要支持NTFS。这是为了确保任何厂商的固件都能读取磁盘上的引导文件，而不依赖微软或第三方厂商的文件系统驱动。

从实际角度看，Windows安装程序在UEFI模式下会自动创建一个约100MB（或更大）的FAT32分区作为ESP，把引导文件放在里面。如果你手动给U盘制作Windows安装盘，把U盘格式化成NTFS，那么在纯UEFI模式下（不开CSM）很多主板是无法识别和引导的，因为固件根本不认识NTFS文件系统。

有一些主板为了提升体验，会在固件里额外加入NTFS驱动支持，但这属于厂商自选行为，不是规范强制。所以制作UEFI安装U盘时，安全做法是格式化成FAT32。但FAT32有单文件最大4GB的限制，Windows 10/11的install.wim可能超过这个大小，这时候你有几个选择：一是使用微软官方的Media Creation Tool制作U盘，它会自动处理好分区和文件；二是用Rufus等工具在制作时选择“FAT32并针对UEFI优化”，工具会把大文件拆分成install.swm分卷；三是先把U盘做成FAT32，再将install.wim换成install.esd（ESD压缩率更高，通常小于4GB）。

3.4 Boot Manager与启动项的管理技巧

日常维护中，最常用的启动项管理命令是bcdedit。这个命令平时要在管理员权限的命令提示符里执行。查看当前系统BCD设置的命令是：

bcdedit /enum all

你会发现输出里有很多条目：Windows Boot Manager、Windows Boot Loader、还有一些与恢复环境相关的条目。每个条目都有GUID标识符，可以通过“标识符”来区分。

如果系统启动项丢失或损坏，最常见的操作是：

# 创建新的BCD存储文件，并指定系统分区 bcdedit /createstore C:\BCD # 在这个新存储中添加Windows启动条目 bcdedit /store C:\BCD /create {default} /d "Windows 10" /application osloader

但说实话，bcdedit手动重建BCD的过程比较繁琐，日常更推荐用Windows恢复环境里的“启动修复”功能，或者直接用bcdboot命令：

bcdboot C:\Windows /s S: /f UEFI /l zh-cn

这个命令的含义是：从C盘的Windows安装目录抽取引导文件，把引导文件部署到S盘（S盘就是ESP分区盘符），指定UEFI引导方式（/f UEFI），语言参数指定为中文。bcdboot是Windows自带的引导修复利器，很多情况下手动重装一般先跑它，成功率远高于“自动修复”。

4. 不同场景下的启动链路：虚拟机、特殊主板和双系统共存

启动流程虽然是标准化的，但放到不同硬件环境和应用场景里会出现很多细微差异。这里挑几个实操中经常遇到的场景单独说。

4.1 虚拟机里UEFI引导有什么不一样

在VMware Workstation里创建Windows 10/11虚拟机时，可以先选好固件类型，默认选项往往是UEFI。如果你创建虚拟机时选择了UEFI，那么虚拟机内部的“BIOS”就是一个模拟的UEFI固件（VMware把它封装在虚拟机硬件层面），安装Windows后ESP分区会是虚拟磁盘上第一个分区，引导流程和物理机一模一样。

但如果虚拟机本身是Legacy BIOS模式下装的（比如你从VMware模板或旧虚拟机克隆过来的），它的磁盘分区表通常是MBR，启动走的是模拟BIOS加MBR引导。这时候你去“改造”这个虚拟机，想让它切到UEFI引导，会麻烦一些：需要额外创建一个EFI系统分区、迁移引导文件、改分区表类型。比较实用的做法是：如果只是测试、学习UEFI引导流程，就直接新创建一个UEFI虚拟机；如果必须把存量Legacy虚拟机转成UEFI，考虑用备份工具把系统完整备份出来再恢复到新虚拟机，而不要试图原地硬切，硬切容易出各种奇怪故障。

4.2 主板固件不支持UEFI时的处理思路

“主板不支持UEFI固件”这种说法，在近十年生产的服务器主板上其实不太准确，更准确的说法是“主板固件里的UEFI支持不完整”或“当前固件版本有缺陷”。以Supermicro（超微）服务器主板为例，一些老型号的固件更新到特定版本后，UEFI引导选项在某些组合下不生效，或者把启动模式意外锁定在传统模式。

遇到这种问题，我的建议是按顺序排查：

1. 确认固件版本是否最新。去官网下载对应主板型号的BIOS/IPMI固件更新包，更新后进BIOS设置，找“Boot Mode”或“Boot Configuration”选项，看看有没有UEFI选项。
2. 检查启动模式设置是否被IPMI/BMC远程设置干扰。服务器主板常有BMC（基板管理控制器），可以通过IPMI远程设置启动模式，如果BMC里设置了Legacy Only，那么本地的BIOS设置可能会被覆盖。
3. 如果固件版本较老、找不到UEFI选项，先查看官方发布说明，确认该型号在哪个版本开始支持UEFI，然后逐级升级固件，不要直接跳板跨多个版本刷。
4. 如果确认固件本身就不支持UEFI（多见于十年前的平台），那就没有太多办法，要么继续用Legacy模式安装系统，要么更换硬件平台。

4.3 双系统引导冲突的原理和解决思路

Windows和Linux双系统共存时，常见的问题是：先装了Windows再装Linux时Linux会用GRUB接管启动，Windows和Linux的启动项都出现在GRUB菜单里；但如果先装了Linux再装Windows，Windows会认为自己是唯一系统，Linux原来的GRUB引导被覆盖，只能进Windows。

出现这个现象的原因和启动流程有关：Windows引导管理器在安装时只会把自己注册到UEFI NVRAM启动项的最前面，而不会检测已存在的其他操作系统的引导加载器。它不像Linux的GRUB那样主动搜索并添加其他系统。所以装双系统的推荐顺序是：先装Windows，再装Linux，让Linux的GRUB检测并加入Windows启动项。这个顺序可以避免很多麻烦。

如果已经搞反了顺序，Windows把GRUB覆盖了，解决方法是进入Linux的Live USB环境，重新安装GRUB到ESP分区。比如Ubuntu系统：

# 挂载系统根分区和EFI分区 sudo mount /dev/sda2 /mnt sudo mount /dev/sda1 /mnt/boot/efi # 进入chroot环境 sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo chroot /mnt # 重新安装并生成GRUB配置 grub-install /dev/sda update-grub

这条命令链就是把Linux引导重新写回ESP，并让GRUB自动搜索Windows启动项。

5. UEFI Shell与启动项的底层维修手段

说到UEFI的深度维护，很多人不清楚固件本身还带一个小型命令行环境。UEFI Shell可以让你在操作系统还没加载的时候就查看分区、执行EFI程序、修改NVRAM启动项。对启动故障排查来说，这是一个非常强大的工具。

5.1 怎么进入UEFI Shell

进入UEFI Shell的方式一般有三种：各厂商主板固件设置里自带Shell入口（联想、戴尔、惠普很多型号在BIOS设置里直接能看到“UEFI Shell”选项）；从U盘启动一个预先打包好的UEFI Shell镜像；在Windows的CMD里用工具重启进入指定固件设置界面。

需要说明的是，很多固件默认并没有把Shell编译进去，尤其是一些消费级主板。这时需要从TianoCore项目下载UEFI Shell镜像（如ShellX64.efi），放入FAT32格式的U盘中，然后在BIOS里添加一个指向这个文件的启动项，或者直接用它引导。

5.2 Shell里常用命令与场景

进入UEFI Shell后，界面是字符模式。常用命令有这么几个：

• map命令列出当前所有可用设备和文件系统映射。你会看到类似FS0:、BLK0:之类的标识，FS开头的是被固件识别为含有文件系统的设备。
• ls命令查看当前目录内容，用法和DOS的dir类似，比如ls FS0:\EFI。
• bcfg命令是管理NVRAM启动项的核心命令。查看启动项用bcfg boot dump，添加启动项用bcfg boot add 0 FS0:\EFI\Microsoft\Boot\bootmgfw.efi "Windows Boot Manager"。
• edit命令可以编辑文本文件，适合修改一些简单的配置文件。
• reset命令重启机器。

常见的实用场景是：启动项丢失，固件也识别不到Windows Boot Manager，但在Shell里能看到ESP分区和引导文件。这时候直接执行：

# 在Shell中确认ESP分区映射，然后手动添加Windows启动项 bcfg boot add 0 FS0:\EFI\Microsoft\Boot\bootmgfw.efi "Windows Boot Manager"

执行后重新开机，就能看到“Windows Boot Manager”出现在启动菜单中。这比用Windows安装U盘进修复模式再跑bcdboot要快很多，尤其是在没有Windows安装介质、只有一台能进Shell的机器时。

5.3 NVRAM变量损坏的常见症状

UEFI启动项信息存储在主板上的NVRAM里，这里存储的数据包括启动顺序、Secure Boot密钥、固件设置等等。如果NVRAM变量损坏，会出现一系列非常怪异的现象：BIOS能识别硬盘但启动菜单空白、之前保存的启动项全部消失、修改BIOS设置后重启又恢复默认、Secure Boot显示未激活但无法开启。

NVRAM损坏的处理思路一般是：先清除CMOS（拔电池或短接跳线），让固件重置NVRAM；再手动重建启动项（用Shell的bcfg或Windows的bcdboot）；如果问题依然存在，执行固件自带的“恢复默认设置”或重新刷写固件。

6. 一图流启动故障排查实战手册

排查启动故障是个实践性很强的工作，很多问题看起来复杂，但定位思路其实非常固定。我把这些年遇到的高频问题和排查路径整理成一张表，大家在现场可以照着顺序来。

6.1 高频启动故障与快速定位

6.2 去掉CSM后无法启动，原因有可能是分区表类型

比较常见的一个场景是老系统迁移：原来是在Legacy模式下装好的Windows，用第三方工具做磁盘克隆后直接搬到新机器上，新机器默认是纯UEFI模式，于是开机提示找不到启动设备。

根本原因是：克隆出来的系统还是MBR分区表，引导文件在活动主分区里，而UEFI模式只认GPT分区表和EFI系统分区。解决路径有两个方向：一是进入BIOS开启CSM，让系统继续用Legacy方式引导，这是最省事的做法，但牺牲了UEFI的安全性优势；二是把系统从MBR转换成GPT，重建引导，这就需要用到mbr2gpt工具。

mbr2gpt是Windows 10 1709之后版本自带的一个命令行工具，可以在不格式化磁盘的情况下把磁盘从MBR转换为GPT。操作步骤如下：

1. 用管理员权限打开命令提示符。
2. 先执行mbr2gpt /validate，工具会检查当前磁盘是否满足转换条件（磁盘未加密、分区布局可转换、系统分区足够大等）。
3. 验证通过后执行mbr2gpt /convert进行转换。
4. 转换成功后，进入BIOS关闭CSM，重启即可。

这个方案比第三方分区工具稳妥，因为它是微软官方提供的，对系统分区的处理逻辑和Windows安装程序保持一致。

6.3 制作一个你可能永远用不上的“急救U盘”

启动故障往往都发生在你最着急的时候，所以提前准备一个急救U盘是运维人员和装机爱好者值得做的事。我推荐的方案：

1. 准备一个8GB以上的U盘，格式化成FAT32。
2. 用Rufus或Ventoy制作一个包含Windows PE或WinRE的启动盘。
3. 把Windows安装镜像里的bootmgfw.efi、winload.efi等关键文件提取一份，放在U盘的\\EFI\\Microsoft\\Boot下，万一系统引导文件丢失可以从U盘手动修复。
4. 顺手放一个UEFI Shell镜像进去，在某些无法正常引导到Windows的情况下可以直接进Shell操作NVRAM。

这个急救盘平时用不上，但真到现场就是救命稻草。我自己的U盘上固定放一份WinPE镜像加一份ShellX64.efi，已经用它在不同机器上救回好几次启动故障了。

7. 实操笔记：我做启动修复时的几个习惯

最后聊一些建立在实际操作中的经验，这些内容不一定在官方文档里能找到，但对日常维护非常有用。

第一个习惯是改任何启动相关设置之前，先把当前的状态记录下来。比如在BIOS里改启动模式之前，先拍下当前启动模式的设置项和启动顺序；在执行bcdedit修改之前，先执行一次bcdedit /export C:\BCD_Backup保存当前BCD。这样就算改坏了也能快速还原，不至于抓瞎。

第二个习惯是优先用Windows安装U盘而不是PE。很多第三方PE会修改系统引导文件，尤其是一些绑定推广软件的PE，装完系统之后首页被锁定、浏览器主页被改，根源都出在PE阶段。微软官方安装U盘虽然体积大一点，但它不会做任何额外动作。从Windows 10开始，官方镜像本身就自带命令行和恢复环境，大多数故障在其中就能处理。

第三个习惯是分清“启动项丢失”和“引导文件损坏”。启动项丢失是说固件里的NVRAM记录没了，系统分区上的文件还是好的，这种情况进Shell用bcfg加一条即可；引导文件损坏则是ESP分区里的bootmgfw.efi、BCD等文件本身坏了，需要复制新文件或者用bcdboot重建。这两个问题症状相似，但处理方式完全不同。很多人拿着启动修复工具反复执行，结果引导文件越修越乱，就是因为没分清问题层次。

第四个建议是不要在一台服务器或重要机器上做启动模式切换的冒险实验。哪怕你准备充分，切换UEFI/Legacy模式也可能会影响分区表可读性、影响BitLocker状态。如果机器上有重要数据，先把数据备份再做实验，永远不要图省事直接上手。我自己早期帮客户做MBR转GPT时遇到过BitLocker因为分区表变化直接要求恢复密钥的情况，虽然最终用备份密钥解锁了，但那十分钟的紧张感我现在还记得。

UEFI和Windows的启动链路，说复杂也复杂，说简单也简单。复杂是因为它横跨固件、分区表、文件系统、引导管理器多个层次，任何一层有问题都会表现为“开不了机”；简单是因为只要把每个阶段的职责、边界和交付物搞清楚，排查起来就是一层一层往下走。这篇文章里讲的这些内容，基本覆盖了我日常处理启动故障的九成场景。下次再遇到开不了机的机器，先别急着重装系统，按照启动顺序想一想它会卡在哪一步，解决问题的思路自然就出来了。