日志与故障现场保存机制_技术探讨

编制日期 2026-10-14 ｜ 版本号 Rev 1.0

面向嵌入式固件的黑匣子机制 · 介质选型 · 写入路径 · 跨复位故障链

结论：日志只有活过重启才算数。任何一次崩溃，都必须在 RAM 蒸发之前，沿着一条短、幂等、可中断的写入路径，把最小数据集送进非易失介质，并在下一次上电时能被完整读出、拼出时间线——本文给出达成这一目标的完整机制设计与纪律清单。

报告总结

固件工程师几乎都遇到过同一个场景：设备在现场出了问题，接上调试器想看日志，却发现日志区要么是空的，要么停留在很久以前——因为日志打在 RAM 里，而故障往往以一次重启收场，RAM 日志随复位一起蒸发。本文围绕「如何让每一次崩溃都留下可追查的现场」展开：

• 讲清日志为什么会死在重启里：RAM 的易失性、崩溃后的三种抢救状态、重启风暴的覆盖效应，这是一切黑匣子设计的物理起点（第 1 章）；
• 给故障建档并推导抢救窗口：断言、硬 fault、看门狗、掉电四类故障各留多宽的窗口，直接决定写入路径该长什么样（第 2 章）；
• 给出从介质选型、写入路径、数据集与记录格式，到恢复解析、跨复位故障链、寿命预算、测试验收的全链路方案（第 3~12 章），目标是任何一环断掉都留痕；
• 给出可直接套用的附录工具：术语表、记录格式速查、故障注入清单与延伸阅读。

读者路径

三条典型阅读路线，按需取用；每章内容自包含，可跳跃阅读。

1. 故障现场的黄金几分钟：日志为什么死在重启里

1.1 RAM 日志的宿命：复位即蒸发

绝大多数固件的日志系统天生长在 RAM 里：环形缓冲、错误码、任务状态统计都以变量形式存在。RAM 是易失存储，其内容依赖持续供电；而复位——无论软复位还是硬复位——对 RAM 内容的保障几乎等于零。复位期间 RAM 是否保留取决于具体的掉电域与复位域设计，但把正确性押在「这一款芯片复位后 RAM 恰好不清零」上，是典型的脆弱设计：换一颗料、改一版电源树、甚至只是调整启动代码里的初始化段，这条隐含假设就无声失效，而失效的表现恰恰是「黑匣子在最需要时是空的」。

更严谨的视角是把复位理解为一次极短的断电：从黑匣子的角度看，复位与掉电对 RAM 的效果是同一件事——内容不可依赖。图 1 给出复位前后同一块 RAM 的对照：复位前日志缓冲、全局变量、任务栈都还在，复位后全部退化为上电初值或随机噪声。

与之对照，非易失介质（片内 Flash、外挂 NOR 与 NAND、EEPROM、FRAM）在复位后内容原样保留，因此黑匣子的最终落点必须在非易失一侧。表 1 汇总了各类存储在复位前后的去留与含义。

由此得到第一条铁律：RAM 日志只是「待写的暂存」，不是黑匣子；黑匣子的定义是内容能活过复位。后面所有章节都建立在这条铁律之上。

1.2 崩溃后的三种状态：可抢救、半抢救、不可抢救

故障发生后的系统并不是瞬间归零，而是先经历一段状态各异的窗口。按「现场还剩多少、写入路径还通不通」，可以把所有故障结局分成三带（图 2）：带与带之间的分界，就是黑匣子设计的着力点。

第一带是可抢救：软件主动停机（断言命中、错误码升级、收到复位请求），调度器与文件写入路径完好，可以从容把全量现场写完再触发复位。第二带是半抢救：硬 fault 把核心拉进异常态、看门狗在中途咬人，此时栈与寄存器快照还在 RAM 里，但调度已死或被拦腰打断，只能走不依赖 RTOS 的精简写路径，抢多少算多少。第三带是不可抢救：掉电后储能耗尽，或重启风暴反复覆盖，RAM 日志蒸发，只能依靠上一次已经落盘的记录加复位原因做推断。

三带划分的价值在于它把设计问题转成了明确命题：让尽量多的故障落在前两带（靠检测与主动停机），为第二带准备独立的精简写路径，并接受第三带只能留痕的现实——而不是假装每一类崩溃都能全量保存。表 2 的三行，恰好对应第 4 章要拆开讲的三条写入路径。

1.3 重启风暴：同一次故障反复覆盖现场

比单次崩溃更凶险的是崩溃后自动重启、重启后再次崩溃的循环，俗称重启风暴。它的杀伤机制不是「丢」而是「覆盖」：每一轮重启都会重写 RAM 日志、重写外挂介质上同一片日志区，把上一轮残留的现场抹掉。典型循环如下：

对抗重启风暴的核心纪律有三条。其一，崩溃钩子里的写路径必须追加不回卷：宁可写失败，也不覆盖旧记录。其二，启动早期在弄清上一轮是否异常复位之前，禁止触碰上一轮日志——先读复位原因，再决定日志区怎么用（第 7 章给出上电自检的顺序）。其三，引入跨复位故障计数（第 8 章）：连续快速重启达到阈值就进入安全模式，把设备留在可检修状态，而不是无限循环到线索耗尽。

1.4 本文的承诺：任何一环断掉都留痕

一套黑匣子机制由许多环节串成：检测、抓取、写入、介质、恢复、解析。工程上不可能保证每个环节永不出错，现实的承诺只能是：任何一环断掉，都至少留下「这一环断了」的痕迹，且不破坏更早的记录。这不是保守，而是把可靠性从「环节不坏」的不可控目标，换成「坏了好查」的可控目标。

1.5 黑匣子设计目标与不追求的目标

把目标钉死，才能在资源有限时做对取舍。表 3 把目标与「明确不做的事」成对给出——后者同样重要：很多日志系统死于贪大求全，崩溃路径里塞进太多东西，结果连最关键的几笔都没来得及写。

一句话概括：黑匣子追求的是「确定的小」，而不是「可能的大」。下一章先把故障分类，弄清每类故障留给我们的窗口有多宽，再谈怎么把「确定的小」写进去。

2. 故障分类与抢救窗口

2.1 软件可预期异常：断言、错误码、主动复位

这是最友好的一类：软件自己发现异常并决定停机，因此从异常被识别到复位触发之间的每一毫秒都属于设计者。断言命中、参数校验失败、状态机进入非法态、通信超时升级为复位——它们的共同特征是调度与写入路径完好，全量现场（调用栈、任务状态表、关键变量、最近日志）都可以从容落盘。

设计要点有二。其一，把「停机」与「复位」分开：先写完现场，再触发复位，顺序不可颠倒；若担心写入本身二次崩溃，可对写入路径加保护（第 4 章的崩溃钩子设计）。其二，记录内容必须包含「为什么走到这里」的上下文：断言表达式、所在文件与行号、当时的输入参数、任务归属——这些信息体积小、价值极高，是事后定位的主线索。表 5 给出记录要点。

2.2 硬 fault 类异常：栈还在，调度已死

硬 fault 的本质是核心在硬件层撞上了非法操作：非法取指、非法地址访问、未对齐访问等，具体类别以架构手册为准。此刻有两个关键事实。第一，硬件已经把现场压入栈中——寄存器组、返回地址、故障状态都还在 RAM 里，这是半抢救状态里最值钱的资产。第二，操作系统已经失能——不能再用 RTOS 的队列、信号量与文件系统调用，任何依赖调度的操作都是二次深渊。

因此硬 fault 的写路径必须是独立的裸机精简路径：由 fault 处理器直接驱动介质，绕开调度与通用驱动栈，只写最小数据集（异常类型、栈片段、寄存器快照、关键指针）。这条路径平时必须被故障注入测试覆盖——fault 路径没跑过的黑匣子等于没装。表 6 列出此刻还能拿到什么。

2.3 看门狗复位：现场最模糊的一类

看门狗复位的尴尬在于：它只告诉你「没喂上」，不告诉你「为什么没喂上」。可能是某个任务死循环、可能是中断风暴饿死了喂狗任务、可能是低功耗模式下的时钟配置问题、也可能干脆是供电异常——复位瞬间系统正处于何种状态，几乎无从直接观察，所以说它现场最模糊。图 3 中它的残存度排在倒数第二，原因正在于此。

补救思路是把「现场观察」从崩溃时刻挪到平时：喂狗任务在喂狗的同时，把「我是谁、我的心跳序号」以小记录形式周期性落盘；看门狗复位发生后，上电自检从落盘心跳反推最后还活着的是哪个环节。心跳落盘的频率与介质开销的平衡，在第 9 章的擦写预算里统一核算。表 7 汇总看门狗复位后可用的线索。

2.4 掉电类故障：供电消失时的最后写窗口

掉电与前三类的根本区别：故障原因本身就在掐断写入的能力。从检测掉电到 RAM 内容真正失效，中间隔着一段由储能决定的窗口——这就是最后写窗口。窗口的长短取决于电源架构（储能电容、掉电检测阈值、维持电路），量级通常在毫秒级，具体以电源设计与实测为准。窗口内能做的事极少，也正因为少，才必须把规矩定死：

2.5 抢救窗口的物理边界：储能与写介质时间

最后写窗口能不能完成任务，是一道物理不等式：储能能维持的写入时间，必须大于末笔写入所需时间的数倍，余量用于应对电压跌落过程中的性能劣化。图 4 把这道不等式画在一条时间轴上：储能给出上限，各类介质的单笔写入耗时给出下限，两者的相对关系决定了谁有资格承接掉电前的最后一笔。

从图 4 可以直接读出选型结论：单笔等待极短、无擦除延迟的介质最适合承接末笔；带擦除延迟的介质，若正常运行期没有预先擦好备用页，擦除时间可能吃掉整个窗口——所以第 3 章的介质纪律之一就是「预擦备用页，崩溃路径绝不现场擦」。表 8 把约束与对策逐项对齐，作为本章的收束。

至此，问题的全貌已经清楚：RAM 靠不住（第 1 章），窗口有边界（本章）。接下来的三章依次回答：把日志写在哪儿（第 3 章）、怎么写进去（第 4 章）、写哪些内容（第 5 章）。

3. 落盘介质选型：把日志写在哪儿

日志机制的一切上限，都由「写在哪种介质上」决定。介质决定了擦写寿命预算、单次写入耗时、掉电瞬间的行为，也决定了崩溃钩子里那几十毫秒能救回多少东西。本章从片内 Flash 的隐性代价讲起，依次评估外挂 SPI NOR、SPI NAND 与小容量 EEPROM、FRAM，给出五类介质的对照结论与「由外向内」的选型优先序，最后落到一条最容易被忽视的纪律：日志分区必须与业务分区物理隔离。

3.1 片内 Flash 的代价：擦写寿命与执行中断

片内 Flash 看起来是最省事的日志去处：不用加器件、不用新总线、地址直接可寻，一行代码就能把数据写进去。正因为「顺手」，它也是被滥用得最多的位置。把流水日志持续写进片内 Flash，代价会在几个月后才显现，而且一旦显现往往已经无法挽回。

第一项代价是擦写寿命。片内 Flash 的擦写次数通常只有万次量级，而日志是典型的高频小写入：追加位置相对固定，系统每次记录都落在同一片擦写单元附近，擦除又必须以整个扇区为单位进行。一次擦除摊到每条记录上的磨损远比开发者直觉的大，写放大在这里被悄悄放大了几十倍。等现场反馈「设备运行一段时间后开始报写入失败」，回过头核算才发现，光是日志就吃掉了整个存储器的寿命预算。

第二项代价是执行中断。多数单片机的代码正是从这片 Flash 里取指执行的。擦写期间 Flash 控制器被占用，取指被暂停或显著变慢，所有正在运行的代码——包括与日志毫无关系的高优先级任务和中断服务程序——都会被这一次擦写拖住。它最阴险的地方在于症状的迷惑性：时序抖动与日志写入在时间上严格同步，但代码路径上完全看不到关联，排查时很容易绕开真正的原因。

此外还有几个次要但真实的约束：中断服务程序里等待一次毫秒级擦写，等于变相长时间关中断；片内 Flash 通常没有坏块管理，某页写坏就是永久损坏；日志擦写与业务读写共享同一控制器带宽，业务性能也会被连带拖慢。把这些代价汇总成一张表，结论就清楚了。

这不是说片内 Flash 不能碰。它适合承担的是「低频、少量、可预期」的记录：最近一次复位原因、故障计数器、进入安全模式的标记。这些写入一天几次甚至几天一次，寿命压力可以忽略；只要把它们安排在固定的预留扇区、与代码区隔开，片内 Flash 依然是有价值的故障记录位。流水日志则应当另寻去处。

3.2 外挂 SPI NOR 与 SPI NAND 的日志分区

外挂串行 Flash 是日志分区的最常见载体，NOR 与 NAND 两条路线各有明确分工。选型时真正要 对齐的不是容量，而是写入模型与管理成本——日志记录格式必须与介质的编程粒度、擦除粒度匹配，否则会在运行期付出成倍的擦写代价。

SPI NOR 的特点是容量在 MB 量级、按页编程、按较小扇区擦除，擦写寿命在十万次量级，随机读出快且几乎没有位翻转问题。对日志而言它是「顺手的环形纸带」：定长条目逐条追加，写到分区末尾回卷到开头，回卷时只需擦一个较小的扇区，代价可控。崩溃后解析时还可以现场翻查，不必整块导出。绝大多数嵌入式产品的流水日志分区，NOR 都是默认答案。

SPI NAND 的容量大一个数量级以上，但整页编程、整块擦除，擦除慢且按块计寿命；位翻转是常态，必须配 ECC；出厂就可能带坏块，使用中坏块还会增加，需要维护坏块名单与跳块策略。它适合的是大体量历史记录与事故序列归档——例如黑匣子场景下要保存跨多次重启的完整故障链。用 NAND 存日志，记录格式必须自带校验字段，读出先验后用；写入侧要在 RAM 攒够一页再落，避免半页写入浪费寿命。

实践中还有一个容易忽略的差异：写入耗时分布。NOR 的页编程耗时短而稳定，适合做可预期时序的落盘任务；NAND 的块擦除耗时明显更长且不可压缩，落盘任务必须按「擦除是长操作」来设计——擦除期间让出 CPU，绝不阻塞对时序敏感的路径。这一点直接决定了第 4 章写入路径的形态。

分区大小怎么定，是两种介质选型后共同的下一问。思路是反向算账：先估计设备生命周期内日志的总写入量（写入频率乘以单条大小再乘以服役年限），再除以介质的擦写寿命次数，得到「把寿命摊匀所需的最小分区面积」，最后向上取整到擦写单元的整数倍。算出来的数字往往比直觉大——这正是很多产品日志分区偏小的直接后果：磨损集中在几块单元上，寿命提前耗尽。NAND 还要在此基础上额外预留坏块替换余量，预留比例以所选器件的出厂坏块规格为准。

3.3 EEPROM 与 FRAM：小而稳的故障记录位

流水日志之外，还有一小撮数据对可靠性要求最高、对容量要求最低：崩溃计数器、最后一次复位原因、安全模式标志、掉电前最后一条摘要。这撮数据适合放在 EEPROM 或 FRAM 里——它们容量只有 KB 量级，却能在最恶劣的掉电场景下把最后几个字节稳稳留住。

EEPROM 支持字节级改写，擦写寿命在百万次量级，价格便宜、货源充足。缺点是写入耗时在毫秒级，写期间需要等待，且部分器件的内部页缓冲在掉电时可能把当次写入丢掉。因此 EEPROM 里适合放「允许重写、丢了也能重建」的状态，写入时机安排在相对从容的时刻，不与掉电赛跑。

FRAM 几乎是为此而生的介质：字节级改写、写入速度接近 RAM、擦写次数近乎无限、写入即持久不依赖页缓冲。掉电窗口内抢救数据的最后几笔写入，FRAM 的成功率显著高于其它介质。代价是单位容量成本高、容量小，所以用法很明确：只放最小故障数据集中最关键的那几项，而不是拿它当流水日志的容器。

把两者放进整体架构，就形成了经典的分层保存：FRAM 或 EEPROM 放「最后时刻」——崩溃瞬间的最小数据集；NOR 放「近期过程」——环形流水日志；NAND 放「全部历史」——事故序列与归档。三层各司其职，任何一层失效，上层仍有残存线索可用。

3.4 介质特性对照与由外向内的优先序

三张轴放在一起看，选型逻辑一目了然：没有全能介质。FRAM 在寿命与速度两轴上近乎满格，容量轴却几乎归零；NAND 在容量轴上一骑绝尘，速度与管理复杂度又把它拉回专用场景。选型不是选「最好的介质」，而是把不同介质放到它们各自擅长的位置上。

在此之上可以总结出一条由外向内的优先序：优先用外挂专用介质承载日志，其次是片内专门预留的扇区，最后才考虑与业务共用的片内空间。理由有三：其一，外挂介质让日志的擦写寿命独立核算，写穿日志分区也不会拖累程序存储；其二，外挂介质的擦写不会中断取指，天然避开了 3.1 节的时序陷阱；其三，专用介质可以按日志特性选型——要速度选 FRAM，要容量选 NAND，要均衡选 NOR——不必在业务介质上勉强凑合。

由外向内不是绝对禁令。资源极度受限的小型系统可能只有片内 Flash 可用，此时纪律退化为两条：给日志划出固定预留扇区并与代码区隔离；把写入频率压到每天几次以内，并按第 9 章的方法把日志计入整机擦写预算。约束变紧，但思路不变——日志永远不该寄生在业务的存储里。

3.5 日志分区与业务分区的隔离纪律

介质选好之后，第一件要做的事不是设计记录格式，而是划地盘。日志分区与业务分区必须在地址空间上明确切开，边界固化在链接脚本或驱动常量里，任何一侧都不得越界。这不是洁癖，而是从无数现场事故中换来的教训：日志与业务混居的分区，损坏方式总是双向的——日志回卷擦掉业务数据，或业务写放大磨穿日志区。

隔离的关键在于擦写单元不混用。擦除是介质上最暴力的操作，一个擦写单元要么整块归日志、要么整块归业务，绝不把半个单元给日志、另外半个给业务。否则每次擦日志都在业务数据头上悬一把刀。同理，日志分区内部的坏块名单、磨损均衡策略、写指针，都应独立于业务文件系统维护，两套账目互不干涉。

隔离纪律的验收方法很朴素：在测试里让日志分区疯狂写入直至写穿，确认业务分区读写全程不受影响；再让业务分区执行全量擦写，确认日志内容一字不差。两个方向都通过了，隔离才算成立。这也应列入第 11 章故障注入清单的必测项。

4. 写入路径设计：从打印到落盘

介质只是仓库，写入路径才是运输线。同一条日志，从业务代码里的一次打印走到介质上的一个比特，中间的选择决定了三件事：业务时序被拖慢多少、掉电瞬间丢多少、崩溃钩子里还能不能写。本章沿着「最笨但可靠」到「精巧但需验证」的顺序，剖析同步直写、RAM 环形缓冲加落盘任务、关键事件立即写通道三条路径，再单独处理崩溃钩子这个特殊环境，最后收敛为短、幂等、可中断三条纪律。

4.1 同步直写：最简单也最容易拖垮时序

同步直写是所有人写第一版日志时的自然选择：打印的地方直接调用介质写函数，一条记录从调用到落盘一次完成。它的优点真实存在——实现最短、顺序天然正确、没有中间状态可以丢失、几乎不需要测试。如果写入频率低到一天几条，同步直写就是正确答案，任何缓冲设计都是过度工程。

问题出在它的耗时特征：写入耗时等于介质耗时。EEPROM 一次字节写是毫秒级，NOR 一次页编程是微秒到毫秒级，NAND 一次块擦除更长。这个耗时原封不动地落在调用者的执行路径上——调用者被挂住，排在它后面的所有任务全部顺延。若调用者恰好是高优先级任务或中断上下文，一次日志写入就能把全系统的实时性打穿，而且抖动与日志在时间上严格相关，排查时反而容易锁定原因，算是这类路径唯一的好处。

它还带来一个隐蔽的耦合问题：业务代码与介质驱动被直接焊在一起。换介质、改分区位置、调整记录格式，都要把散落在各处的直写调用挨个改一遍；单元测试也做不了——不接真介质就跑不了日志代码。同步直写若确定要保留，至少应把调用收敛到一个封装函数后面，给未来换成缓冲路径留一条不改业务代码的退路。

同步直写的另一个隐患在掉电窗口。直写意味着调用时刻与写入完成时刻之间有一段介质操作窗口，掉电若落在这个窗口里，就会留下半条记录。频率低时撞上的概率小，但「低概率乘以高后果」在故障现场从来不是可以忽略的项。若坚持用直写，至少要求记录格式带完整性标记，让半条记录能被识别并丢弃（详见第 6 章）。

4.2 RAM 环形缓冲加低优先级落盘任务

这是产品级日志的标准形态。业务代码里的「打印」只做一件事：把记录拷贝进RAM 里的一个环形缓冲，更新头指针，立即返回——耗时微秒级，与介质速度完全无关。真正与介质打交道的是一个独立的低优先级落盘任务：它从环形缓冲取数据、攒批、擦写介质，忙不过来时宁可让缓冲增长，也绝不反压业务路径。

这条路径的收益有三层。时序解耦：介质再慢也只慢到落盘任务自己，业务路径的耗时恒定为一次内存拷贝。写合并：落盘任务可以把多条小记录合并成一次页编程，擦写次数按批而不是按条计算，直接回报到第 9 章的寿命账上。节奏可控：落盘任务的优先级与触发时机（水位、周期、空闲钩子）都可调，让日志流量服从整机调度策略。

代价同样清晰：掉电会丢掉缓冲里没来得及落盘的尾巴。环形缓冲的深度就是在「丢失窗口」与「RAM 占用」之间做的权衡——缓冲越深，崩溃前最近一段日志存活概率越大，但 RAM 花销也越大。务实的选择是接受这个丢失窗口，把「崩溃前最后一条」的保存责任交给 4.3 的立即写通道，而不是无限制加深缓冲。

实现上的要点集中在缓冲管理本身：头尾指针的更新要防并发（业务上下文与落盘任务各写各的指针）；溢出策略要明确（覆盖最旧还是丢弃最新，二选一并写进文档）；水位要有监控（缓冲长期高位意味着落盘速度跟不上，要从介质或频率上找原因）。此外，落盘任务里绝不做长擦除的忙等——NAND 的块擦除应当让出 CPU，否则这条「解耦」路径会以另一种方式把时序问题带回来。

还要想清楚写入失败怎么办。介质会坏、分区会满、擦除会失败，落盘任务不可能永远成功。失败处理至少分三档：介质暂时性失败（编程超时、擦除失败一次）按重试与跳块处理，日志继续往后写；分区写满按覆盖最旧处理，同时往日志里记一条「已回卷」的标记，避免解析时误以为时间倒流；介质彻底失效则把日志降级为 RAM 内环形缓冲并置起故障标志，等导出通道还能用的时候交出去。三档行为都要在第 11 章的注入测试里各演一遍。

4.3 关键事件的立即写通道

缓冲路径有一条固有盲区：它假设「日志可以晚一点写」。但有一类事件恰恰是不能等的——异常发生前的最后一条记录、进入安全模式的决定、看门狗喂狗失败前的状态、检测到异常复位的第一反应。这些事件若只进缓冲，很可能随掉电一起消失，而它们恰恰是故障现场最值钱的几行字。

为此需要一条与缓冲并行的立即写通道：命中关键事件判据时，绕过环形缓冲，直接调用介质驱动写入。它与 4.1 的同步直写貌合神离——同步直写是「随处可用的一般路径」，立即写通道是「事件白名单驱动的专用路径」：触发条件是显式枚举的关键事件清单，内容是预先裁剪的短记录，写路径本身独立测试过。正因为触发稀少且内容极短，它对时序的冲击完全可控。

立即写通道与缓冲路径的关系是补充而非替代。日常流水继续走缓冲，关键事件走专用通道，两条路径最终落在同一个日志分区里。为避免相互踩踏，分区内的空间安排要么分域（关键事件固定区域、流水日志环形区域），要么依赖记录格式的完整性标记自然衔接。前者更直观，后者更省空间，按第 6 章的格式设计二选一。

事件白名单本身需要被当作正式资产维护：每一个入选事件都要注明「为什么这条不能等」，每次新增都走评审。白名单膨胀的后果立竿见影——立即写通道被滥用成第二条直写路径，介质操作重新回到业务路径上，4.1 的时序问题整批回归。反过来，白名单过瘦也有风险：真正崩溃前的最后几条记录若不在名单里，就只剩缓冲里的残篇。名单的校准依赖第 11 章的故障注入：每次真实故障复盘后，回看「崩溃前最想要的几行字是否都在」，缺哪条补哪条。

把三条路径放在一张图里对照，选型问题就变成了事件分类问题：什么事件走哪条路？判据只有两条——这条记录晚写几分钟还能不能接受，以及生成这条记录的上下文允不允许等待。能等且允许等的走缓冲；不能等的走立即写；不允许等待的上下文（中断、崩溃钩子）要么只入队，要么走 4.4 的精简路径。把判据写成一张事件分级表，比争论「用不用缓冲」有效得多。

4.4 崩溃钩子里的精简写路径

硬 fault 处理函数与看门狗超时钩子是整个日志体系里最恶劣的运行环境：调度器可能已经停摆，任务与队列不可依赖；堆管理系统本身可能就是崩溃嫌疑人，动态分配与格式化函数一律禁用；栈区正是要抢救的对象，不能再往上面堆东西；而时间预算只有储能电容撑住的短暂窗口。常规写路径在这里全数失效，必须另备一条精简写路径。

精简写路径的设计原则是静态、直接、固定。静态：所用缓冲在编译期分配，驱动句柄预先打开，不在钩子里做任何初始化以外的新动作。直接：绕过所有中间层，从钩子直接调到介质驱动的最底层写入函数，途中不加锁、不排队。固定：写到分区里一个预定的固定位置，格式与长度编译期定死，即使只写进去一半，下次上电也能凭完整性标记认出残缺并整条丢弃。

这条路径平时必须被反复演练。它只在系统最脆弱的时刻运行，却承担着挽救现场的最后职责——任何一处「平时没问题」的偷懒（比如顺手调了个带锁的驱动接口）都会在真崩溃时以死锁或二次故障的形式爆发。第 11 章的「崩溃中途掉电组合测试」正是针对它设计的。

内容取舍上要克制住「多写一点」的冲动。崩溃钩子里每多写一个字段，就多占一份本已所剩无几的时间预算，也多一个在混乱状态下读取出错的机会。正确的顺序是：先把第 5 章最小数据集定死，再倒推出钩子路径真正要搬的字节量；凡是可以等重启后从内存残迹里挖的，一律不进钩子路径。经验上，钩子里真正值得写的往往只有三样：异常类型与位置、关键计数器、以及一条带版本号的指纹——让这段记录在几个月后还能对上是哪一版固件在什么情况下倒下的。

4.5 写入路径的三条纪律：短、幂等、可中断

无论走哪条路径，写入侧最终都收敛为三条纪律。它们不是风格偏好，而是把「日志系统自己不成为故障源」拆成了可检验的设计约束。

短：任何单条写入在介质上的耗时要有上限，落盘路径里不做长循环、不做全片扫描、不做跨页的大搬运。短是可中断的前提，也是时序风险的总量控制——每条写路径的最坏耗时都应当被实测并记录在案，而不是「应该不慢」的感觉。

幂等：同一条记录写两次，介质上的结果必须一致；掉电后重写同一条记录，不得产生相互矛盾的半条。幂等靠记录格式保证：序号加完整性标记加 CRC，让「重复」可以被识别、「残缺」可以被丢弃。没有幂等性，崩溃后恢复逻辑每前进一步都要先猜介质上的数据可信到什么程度。

可中断：写路径随时可以被更高优先级打断，不靠拉长关中断窗口来保一致。一致性由「单条记录原子性」（完整性标记）与「路径无共享可变状态」保证，而不是由「没人敢打断我」保证。可中断还有一层含义：被打断的写入在下一轮必须能安全续写或安全放弃，不留中间态锁。

三条纪律放在一起，就是写入路径的验收标准：每条路径报得出最坏耗时（短），掉电注入后介质上找不出矛盾记录（幂等），最高优先级打断后系统照常运转（可中断）。做到了这三条，写入路径就从「日志功能的实现细节」升级为「故障时可以托付的生命线」。