你想从命令行给机器临时指定一个启动设备：用 efibootmgr 新建了一个指向优盘的启动项，又用 --bootnext 把它设成「下次启动用这个」。重启——机器眼皮都不抬，照样进了原来的系统。反复执行几次，efibootmgr -v 里明明列着你刚建的项，固件就是不理它。
如果你遇到的是这种情况，问题多半不在你的命令，而在这条启动项本身写得不完整，以及这块固件压根不认「下次启动」这套约定。
现象
几个可以互相印证的观察点：
$ sudo efibootmgr -v
BootNext: 0003
Boot0003* USB Install HD(1,GPT,...)/\EFI\BOOT\BOOTX64.EFI
Boot0000* Windows Boot Manager HD(1,GPT,...)/\EFI\Microsoft\Boot\bootmgfw.efi
启动项建了、BootNext 也设了，efibootmgr 读回来的信息一切正常。但重启后：
BootNext被清掉了（说明固件确实读过并处理了它），- 可它没有去引导
0003，而是走了自己的默认顺序，进了原来的系统。
也就是说，固件「看到了」这条设置，但「不接受」它指向的那个目标。
根因
要理解这一点，得先知道 UEFI 启动项在 NVRAM 里到底存了什么。
一条启动项并不是「一个可执行文件的名字」，而是一串**设备路径（Device Path）**加一个文件路径。设备路径是分层的，层层描述「从哪儿开始、经过哪条总线、到哪个设备」。一条完整的、指向优盘的启动项，大致需要这么几段：
PnP 路径（走 USB）→ PCI 路径（该 USB 控制器挂在哪个 PCI 地址上）→
硬盘分区路径（优盘的分区及 GUID）→ 文件路径（\EFI\BOOT\BOOTX64.EFI）
现在看 efibootmgr 自动生成的那一条：它把路径写成了 HD(...) 开头，缺少了前面的 PCI/总线前缀。这种「简写」在固件眼里是不完整的——它没法从这条路径推断出这个 HD() 到底挂在哪条总线上、该去哪儿找。固件解析失败，于是按规范「跳过无法解析的项」，继续走别的启动项。
这就是为什么 efibootmgr -v 看着没问题、固件却不用它：命令行工具和固件对「什么算一条合法的启动项」的判定标准不一致。 工具认为够用了，固件的解析器认为不够。
还有第二个层面的原因：这块主板的固件本来就一贯忽略 BootNext。BootNext 是 UEFI 规范里的一个可选行为，规范说「应当支持」，但没说「必须支持」。某些固件实现里干脆没有处理它的代码，或者只在特定条件下处理。所以就算启动项写得完全正确，--bootnext 也照样不起作用。
两个原因叠加，就得到那个现象：设置被读取、被清除，但执行环节被跳过。
解决
第一，不要依赖 efibootmgr 来临时改变启动目标。 既然是固件实现层面的差异，工具层面绕不过去。
第二，改在固件的启动菜单里手动选。 绝大多数主板都提供一次性启动菜单（开机时按 F11 / F12 / F8 / Esc 之类的键，具体看开机提示），在里面直接选设备是最可靠的方式——因为这条路径用的正是固件自己的逻辑，不存在「解析不了」的问题。
第三，如果要引导的是自定义 EFI 程序（比如自己写的引导器、或想替换掉系统默认的引导程序），不要试图靠新建启动项实现。 更可靠的做法是：替换固件实际会走的那条路径上的那个文件。
具体来说：固件引导时会按它自己的优先顺序去找 \EFI\BOOT\BOOTX64.EFI 或厂商特定的路径（如 \EFI\Microsoft\Boot\bootmgfw.efi）。你要做的是先确认「固件默认走的是哪条路径」，然后在那个路径上放你的程序（记得先备份原文件）。很多人踩的坑是：只顾着往通用回退路径 \EFI\BOOT\BOOTX64.EFI 里放文件，结果这台机器的固件优先走的是厂商那条路，通用路径根本不被访问——文件放对了，路径没走对，一样无效。
# 先确认固件实际使用哪条路径
sudo efibootmgr -v
# 找到默认 BootOrder 里排第一的那条，记下它的文件路径
# 然后把你的 EFI 程序替换到那条路径上（先备份！）
延伸与预防
这条坑的本质是：规范里写「应当」，不等于实现里「真的做了」。
UEFI 是一份很厚的规范，里面区分了「必须支持」和「应当支持」。后者给厂商留了自由度，于是同一套命令在不同主板上表现不一——这也正是 efibootmgr 这类工具「在有些机器上很好用、在有些机器上完全没用」的原因。
这个模式在别处也常见：HTTP 头里的「应当」、数据库方言对 SQL 标准的偏离、各家浏览器对同一段 CSS 的处理差异。跨过「规范层」去依赖「实现层」的行为时，一定要先在目标机器上验证一次，而不是假设它符合规范。
另外，这条经验还有个直接的操作建议：引导相关的东西，永远留一条不依赖软件设置的退路。 一次性启动菜单、物理按钮、可引导的救援优盘——这些走的是固件自己的逻辑，不依赖 NVRAM 里那些可能被忽略的设置。把默认引导程序替换掉之前，先确认自己有办法在它坏掉时从别处启动。