在 UEFI 上引导引导加载程序的概念简单直接，就像将.efi引导加载程序放在 EFI 系统分区上一样。然后该.efi文件加载相应的操作系统。但是，我仍然不明白为什么 MBR 需要一个活动分区来引导操作系统。
从我目前的研究来看，MBR 引导程序代码位于磁盘的前 446 字节，将在 POST 后由 BIOS 自动执行（作为 de-factor 标准）。它可以直接加载操作系统，但大多数时候，代码非常小，以至于它的主要工作是加载位于另一个分区某处的实际引导加载程序。
为什么我们需要将分区设置为活动分区才能从中启动？理论上，MBR 引导程序代码可以随心所欲地运行。
是的，在实践中，MBR 引导程序代码通常就是这样做的。
但是引导代码需要一些方法来找到下一阶段引导加载程序的存储位置。（整个引导加载程序绝不仅仅是 446 字节；MBR 只是它的第 1 阶段。）
拥有一个解析 MBR 分区表并查找“活动”标志的引导扇区恰好是解决此问题的一种非常通用的解决方案——它允许一个完全静态的引导扇区（不需要特殊工具来生成它），并且任何引导扇区都在做所以适用于任何操作系统。
例如，syslinux MBR 引导扇区似乎可以与 Windows MBR 引导扇区完全互换。如果你双引导 Linux 和 Windows，那么你拥有哪个引导扇区并不重要，它们都做同样的事情，所以你总是可以只交换“活动”位来交换操作系统。（安装引导扇区只是将 mbr.bin 复制到原始磁盘。）
但是不同的bootloader肯定有不同的做法：比如流行的Linux GRUB2将它的second stage存放在“post-MBR gap”中，并根据其位置动态生成bootstrap代码；即 MBR 引导扇区知道第二阶段从哪个 LBA 开始（完全忽略分区表和“活动”标志），这可能因磁盘而异，因此引导扇区必须由
grub-install程序为每个磁盘单独写入。（GRUB2 通常也不使用分区 VBR；虽然它可以“链式加载”那些，但其典型配置实际上直接访问真实文件系统并加载操作系统内核文件。）
有关 MBR 格式的历史信息，请参阅 维基百科主引导记录 。
基本上，对活动分区的需求是早期 IBM/DOS 引导加载程序的设计选择，并且从那以后一直如此。
这些早期的引导加载程序会扫描 MBR 的嵌入式分区表中的分区列表，找到唯一标有活动标志的分区，然后加载并运行这个活动分区的卷引导记录 (VBR)。
这只是 IBM PC 生命中的另一个早期设计决策，此后一直存在，没有其他原因，只是一些早期开发人员团队的决定（甚至可能只有一个人做出）。