固件对的写回变量

【踩坑实录】固件对的写回变量

▍现象
虚拟机工程的固件采用 edk2 双单元结构：代码单元只读、变量单元可写。装机运行基本正常，但客户机系统的启动设置不持久（改过的启动顺序、安全设置重启即丢）——变量像是没存上。

▍定位过程
变量丢失类问题查写回链：变量单元的写请求（客户机运行时的设置修改会写固件变量）——模拟层的写回实现（写请求要落到变量单元的存储）——持久化文件（变量单元的内容要落到宿主侧文件，跨重启存在）。逐段查发现写回的实现缺口：变量写请求在会话内生效（内存态变了），但向宿主文件的持久化时机与完整性有问题——会话结束或快照时刻的写回不完整，重启后变量回到旧值。工程记录里这族问题的修复有编号：修好 pflash 单元的写回后，快照保存的固件状态才可靠。

▍根因
可写固件单元的语义是文件级持久化：模拟层必须保证变量状态到宿主文件的落盘时机（何时写）、完整性（写一半崩溃的防护）、一致性（与快照点的对齐）。缺任何一条，症状都是变量丢失或错乱，而且都是静默的——没有报错，只有用户重启后的一声咦。

▍对策
写回时序修复（关键节点显式落盘：设置修改后、会话结束前、快照保存时各一次写回）；原子写保护（临时文件加改名，防写一半损坏）；快照对齐（快照时的变量状态与档的一致性点绑定——上上篇实录的关联项）。

▍方法论沉淀
持久化三问 checklist（何时写、写坏了怎么办、与快照对齐了吗）适用于一切可写状态管理——不止固件：应用配置、数据库、会话状态，问的是同样三个问题。

虚拟机工程固件对（code 只读加 vars 可写）的完整登记在适配全记录，apps 板块 56 篇欢迎对照。