系统还没开始加载，时间已经耗掉了

操作系统开始加载之前，主板固件要先唤醒并确认所有硬件在位且工作正常，这一步叫开机自检，缩写为 POST，在某些机器上耗时会超出预期。

冷启动时，统一可扩展固件接口按一张清单逐项执行：初始化内存、扫描已连接设备、检查存储接口、配置基本输入与输出。这些全部发生在 Windows 介入之前，固件走完清单的速度，决定了控制权在什么时候交给 Windows 启动管理器。

如果主板要花二三十秒校验内存、轮询空置的 USB 接口以及一台从不使用的光驱，再快的 NVMe 也补不回这段损耗。针对这一段，最有效的动作是在固件设置里打开 Fast Boot。

需要区分的是，这与 Windows 系统里的快速启动不是同一件事，后者的原理是让 Windows 内核部分休眠。固件层的 Fast Boot 纯粹是硬件级设置：打开后主板会跳过详尽的硬件检查，直接转向主存储盘。视主板型号而定，它可能同时关闭光驱引导、网络引导和可移动介质引导的支持；部分选项更激进，会完全隐去厂商启动画面，并把 USB 控制器的初始化推迟到 Windows 接管之后。

进入固件设置界面的方式通常是开机瞬间连按 Delete、F2、F10 或 Esc 键。如果机器启动已经太快，抓不住这个时间窗，可以改从 Windows 的高级启动进入，选择固件设置项。进去后找到引导菜单，把 Fast Boot 从 Disabled 或 Thorough 改成 Enabled 或 Minimal，保存退出即可。由于全部动作发生在操作系统之下，这属于一次性配置，之后不必重复。

交接给 Windows 之后还能再省一截

不愿改动固件设置的人还有一个纯软件选项。常规关机时 Windows 会彻底关闭一切，内存中的应用与驱动全部被清空；快速启动的做法不同，关机时它把账户注销掉，但让系统内核继续存活。下次开机直接把保存的状态读回内存，不必从零重建，按该文的说法可以把启动时间缩短 30% 到 60%。开启路径是控制面板中的电源选项，点击选择电源按钮的功能，然后勾选启用快速启动。

即便 Windows 自身加载得够快，桌面一出现就有一堆程序抢着启动，体感依然是慢。按 Ctrl+Shift+Esc 打开任务管理器并切到启动标签，可以看到所有随 Windows 启动的项目，以及各自拖慢启动的粗略程度。被标为高影响的项目，意味着它在启动瞬间占用了超过一秒的 CPU 时间，或产生了 3MB 以上的磁盘活动。清理时逐项过一遍，把不需要立刻使用的全部关掉。该文作者关停了 Steam、Epic Games 在内的所有游戏启动器，只保留了手机连接，其余程序改为需要时手动点开。

硬件确实更快，但掩盖不了系统的乱

文章并没有否认硬件的价值。老一代 SATA 固态受接口限制，速度封顶在 600 MB/s 左右；当前的 PCIe 4.0 NVMe 标称可达 7400 MB/s，PCIe 5.0 则号称能上到 14000 MB/s 以上。NVMe 协议是为闪存从头设计的，可处理多达 64000 条并发命令队列，足以吸收沉重的启动负载，这些数字本身站得住脚。

但启动过程还会被 CPU 解压、内存延迟和固件层的硬件初始化拖住，一个臃肿的启动序列才是真正的瓶颈。缺乏管理的系统会持续在后台写入无谓数据，比如页面文件反复扩缩、临时文件夹索引、维护休眠文件，这些动作长期蚕食硬盘的总写入寿命。驱动冲突、软件死循环，或者四十个应用同时加载导致桌面三十秒才可用，这类更深层的问题也不是靠读写速度能解决的。用更快的硬件去压一个混乱的系统，只是把问题藏起来，同时让硬盘磨损得更快。

软件层的优化同样有上限。硬盘本身已经老化或即将失效时，清理启动项无法弥补硬件缺陷。不过对一台状态尚可的机器来说，改固件设置大约五分钟，清理启动项再花十分钟，多数人在动硬件之前就能感受到差别——这两处也是开机变慢时最该先查的地方。

来源：How-To Geek

XDA 撰稿人 Korbin Brown 梳理了这一现象。这块存储的正式名称是 UEFI NVRAM（非易失性随机存取存储器），通常和固件镜像共处同一颗 SPI 芯片，负责保存启动顺序、安全启动状态、风扇曲线这类断电后仍需保留的设置。它的行为和普通硬盘很像：会被写入、删除，也会随时间碎片化。一旦可用空间耗尽，系统就无法保存新的启动项，也无法更新固件设置，最坏的情况是电脑干脆拒绝启动。

一、先确认空间是不是真的满了

Linux 通过 efivarfs 把这块存储挂在 /sys/firmware/efi/efivars 下，近年内核直接 df -h 即可看到 NVRAM 总容量与已用量。那位实际踩坑的用户查得 64K 容量、60K 已用、可用 0K。

抢占空间的东西不少：启动项与启动顺序、安全启动密钥数据库都在里面。其中 dbx 是问题引导程序的吊销列表，2020 年 BootHole 漏洞修复就往里追加了一批条目。部分厂商还会把错误日志直接写进 NVRAM。

更麻烦的是删除机制：删掉 EFI 变量不会立刻释放空间，固件只把它标记为无效，真正回收要等开机时触发的垃圾回收——且往往要等可用空间跌破阈值才启动。老主板或低价主板固件常处理得很糟，甚至跳过这步。

二、清理无效启动项

只有在确实撞上容量报错时才需要动手，无缘无故摆弄 EFI 变量，帮倒忙的概率远大于帮忙。

1. 在 Linux 下执行 efibootmgr -v，列出固件已知的全部启动项。
2. 如果拆过硬盘，很可能会看到指向早已不存在设备的孤儿条目。
3. 逐个删除：efibootmgr -b 条目编号 -B。

Arch Wiki 给出的处理顺序里还有一步值得优先尝试：删掉内核崩溃转储留下的记录，即清理 /sys/firmware/efi/efivars/ 目录下以 dump- 开头的文件，然后重启再试。

三、给这块「盘」做一次整理

如果空间是被无效条目占着不放，就需要整理碎片。XDA 引用的那篇博客给出的做法是进入 EFI Shell 后依次执行三条命令：dmpstore -s efi-vars 把全部变量导出到磁盘文件，dmpstore -d 清空 NVRAM，dmpstore -l efi-vars 再把它们读回来。这样固件会把变量重新连续排布。那位用户重启后的结果是已用量从 60K 降到 14K，所有设置原样保留。

需要提醒的是，这几条命令风险不低，执行前务必先用 help dmpstore 确认本机固件的具体用法。

四、更省事的替代做法

多数机器不会发生此问题：新主板容量更大、固件垃圾回收也改善不少，没碰过启动项的用户几十年都未必遇上，无需预防性整理。

但它偶尔仍会出现在现代机器上。Framework 笔记本的 GitHub issue 里就有多名用户在运行 fwupdmgr 更新固件时收到「Not enough efivarfs space」报错，解决办法是进 UEFI 菜单恢复出厂默认值，让系统把空间清出来。这本质上等同于强制做了一次整理，之前的无效空间会被重新标记为可用。对不熟悉命令行的用户来说，这是风险最低的一招。

来源：XDA Developers