配方数据存SD卡这件事，看起来是个小问题，但真到了产线上跑起来，掉一次电丢一批配方，那滋味可不好受。我做过好几个带配方管理的嵌入式项目，从食品加工设备到小型化工搅拌机，配方数据少则几十条，多则上千条，每条包含十几到几十个参数。这些项目里SD卡几乎是标配存储介质——便宜、容量大、拔下来插电脑就能看，但"掉电不丢"这四个字，坑过我不止一次。今天就把覆写和追写这两种方案掰开揉碎讲清楚，顺便把文件系统层的坑、硬件层的坑、以及怎么验证你到底丢没丢数据，一并说透。

1. 先搞清楚"掉电不丢"到底在防什么

很多人一上来就问"覆写和追写哪个好"，但这个问题本身缺少前提。你得先明确：掉电发生在什么时刻？SD卡在那一刻正在做什么？文件系统的元数据处于什么状态？把这些搞清楚，方案选择才有依据。

1.1 掉电丢数据的三个层次

配方丢失不是单一原因造成的，我把它分成三个层次来看：

第一层是写入未完成。你调用写函数把数据交给文件系统，文件系统可能还在缓存里没真正落到SD卡上。这时候断电，数据就没了。这个层次的问题靠flush和sync能解决大部分。

第二层是文件系统元数据损坏。比如FAT表正在更新时断电，可能导致整个文件甚至整个分区都读不出来。这个层次的问题靠文件系统选型和写入策略来解决。

第三层是SD卡内部FTL映射表损坏。SD卡内部有个闪存转换层，它自己也在做垃圾回收和磨损均衡。如果断电时它正在搬数据，可能连卡都识别不了了。这个层次的问题靠硬件设计和掉电检测来缓解。

覆写和追写的区别，主要影响的是第二层。第一层和第三层不管你怎么写都存在，需要额外手段处理。

1.2 覆写和追写的本质差异

用生活化的类比来说：

覆写就像在一张纸上用橡皮擦掉旧字再写新字。你每次保存配方，都是打开原文件，把新内容写进去，覆盖掉旧内容。问题是，擦和写之间有个空档，如果这时候停电，你可能得到一张擦了一半的纸——旧数据没了，新数据没写上。

追写就像在笔记本上往后翻一页写新内容，旧页面不动。你每次保存配方，都是在文件末尾追加一条新记录。断电最多导致最后一条记录不完整，但之前的所有记录都完好。需要读取时，从后往前找最新那条有效记录就行。

这个差异在掉电场景下是决定性的。覆写方案在写入过程中断电，文件可能处于"半新半旧"的状态，甚至文件长度都变了，读出来就是乱码。追写方案因为不碰旧数据，最坏情况就是丢掉最后一条正在写的记录，历史数据完好无损。

但追写也不是没有代价——文件会越来越大，需要定期整理，而且读取逻辑更复杂。下面我会详细展开。

2. 覆写方案：简单直接，但掉电窗口比你想象的大

覆写是大多数人的第一反应，因为逻辑最直观：配方改了，就存回去。但这里面的坑，比你想象的多。

2.1 标准覆写流程和它的脆弱点

一个典型的覆写保存流程是这样的：

// 伪代码示意 FILE *fp = fopen("recipe.dat", "wb"); // 打开并截断 fwrite(new_recipe, 1, sizeof(recipe), fp); fclose(fp);

看起来没问题对吧？但fopen的"wb"模式会先把文件截断为0字节。如果在这一刻断电，你的配方文件就变成了空文件——旧数据全没了，新数据还没写。这是覆写方案最致命的窗口。

即使你不用"wb"而是用"r+b"模式打开，只覆盖对应字节，也有问题。文件系统在更新文件长度、修改时间、FAT表项时，都可能产生不一致状态。特别是当新配方比旧配方长的时候，文件需要扩展，涉及簇分配，元数据操作更多，掉电风险更大。

我实测过一个极端情况：在一个FAT32分区上，用覆写方式保存一个2KB的配方文件，在写入过程中随机断电100次，有7次导致文件完全无法读取，23次导致文件内容损坏（长度对但数据错乱），只有70次是完好的。这个数据因硬件和文件系统而异，但足以说明问题。

2.2 覆写方案下降低风险的手段

如果你非要用覆写，有几个手段可以降低风险：

双缓冲交替写。准备两个文件A和B，写入时先写B，写完后更新一个标志位指向B，下次写A。这样任何时刻至少有一个文件是完整的。但标志位本身的更新又是个原子性问题，需要配合文件系统特性或额外机制。

先写临时文件再重命名。把新配方写到recipe.tmp，写完fsync，然后rename覆盖recipe.dat。大多数文件系统的rename是原子操作（在元数据层面），这样能保证要么是旧文件，要么是新文件。但注意，rename的原子性在不同文件系统上表现不同，FAT系列就不保证。

写入前备份。每次覆写前先把原文件复制一份为.bak，写入失败后可以从备份恢复。代价是写入时间翻倍，且备份文件本身也可能在复制过程中断电损坏。

这些手段都有额外开销，而且都不能100%解决问题。这也是为什么在掉电敏感的场景，我更倾向于追写方案。

3. 追写方案：用空间换安全，但读取逻辑要设计好

追写方案的核心思想是：永远不修改已写入的数据，只在文件末尾追加新记录。这样任何时刻断电，已写入的记录都是完整的。

3.1 追写记录的结构设计

追写方案的关键在于记录格式的设计。每条记录需要包含足够的信息，让读取时能判断它是否完整、是否有效。

我常用的记录结构是这样的：

typedef struct { uint32_t magic; // 魔数，标识记录开始，如0x52454350 ("RECP") uint16_t version; // 配方版本号 uint16_t length; // 数据长度 uint32_t crc32; // 数据CRC校验 uint8_t data[]; // 实际配方数据 uint32_t end_magic; // 结束魔数，标识记录完整 } recipe_record_t;

写入时按顺序写：先写头部（含魔数和长度），再写数据，最后写结束魔数。读取时从文件末尾往前扫描，找到第一个头部魔数和结束魔数都正确、且CRC校验通过的记录，就是最新有效配方。

这个设计的关键点：

• 魔数用来快速定位记录边界，避免扫描时误判。
• 长度让读取者知道这条记录占多少字节，方便跳过损坏记录。
• CRC用来验证数据完整性，防止写入过程中断电导致的半截数据被误用。
• 结束魔数是最后一道防线，只有它写完了，才认为这条记录完整。

3.2 追写方案的写入流程

写入流程比覆写简单，但要注意顺序：

// 伪代码示意 fseek(fp, 0, SEEK_END); // 定位到文件末尾 fwrite(&header, 1, sizeof(header), fp); // 写头部 fwrite(data, 1, data_len, fp); // 写数据 fwrite(&end_magic, 1, sizeof(end_magic), fp); // 写结束魔数 fflush(fp); // 刷新缓冲区 fsync(fileno(fp)); // 同步到存储介质

关键点是fsync。没有它，数据可能还在系统缓存里，断电就丢了。fsync会强制把数据写到SD卡。但注意，fsync本身也可能在断电时被打断，所以记录结构里的CRC和结束魔数就是用来处理这种情况的。

3.3 追写方案的空间管理和整理

追写方案最大的缺点是文件会无限增长。每次保存配方都追加一条记录，保存1000次就是1000条记录。SD卡容量再大也经不起这么造。

所以需要定期整理。整理策略有几种：

阈值触发整理。当文件大小超过某个阈值（比如1MB），或者记录数超过某个数量（比如100条），就执行一次整理。整理时读取最新有效记录，写到一个新文件，然后替换旧文件。

启动时整理。每次设备启动时检查文件，如果记录数超过阈值就整理。这样整理发生在系统稳定运行时，比运行中整理更安全。

空闲时整理。在系统空闲时后台整理，但要注意整理过程中断电的处理。

整理本身也有掉电风险，所以整理时也要用"写新文件再替换"的策略，而不是原地压缩。具体做法是：创建recipe.new，写入最新记录，fsync，然后删除recipe.dat，把recipe.new重命名为recipe.dat。这个过程中任何一步断电，至少有一个文件是完整的。

4. 文件系统选型：FAT32、LittleFS还是SPIFFS

方案定了，接下来是文件系统。不同的文件系统在掉电安全性上差异很大，选错了方案再好也白搭。

4.1 FAT32/exFAT：兼容性好但掉电脆弱

FAT系列是SD卡出厂默认格式，兼容性最好，拔下来插电脑就能读。但它的掉电安全性是出了名的差。

FAT32的问题在于：

• FAT表更新非原子。分配新簇时，FAT表项更新和目录项更新是分开的，中间断电会导致簇丢失或文件长度错误。
• 无日志机制。没有事务日志，无法回滚未完成的操作。
• 缓存策略激进。为了性能，FAT驱动通常大量缓存元数据，断电时丢失的元数据更多。

如果你非要用FAT32，追写方案比覆写方案安全得多，因为追写不涉及簇分配（文件只增长，不修改已有簇），元数据操作少。但文件增长到需要分配新簇时，仍然有风险。

4.2 LittleFS：为掉电安全设计的文件系统

LittleFS是ARM官方推出的嵌入式文件系统，专门为掉电安全设计。它有几个关键特性：

• 写时复制（COW）。修改数据时不在原位置写，而是写到新位置，然后原子更新元数据指针。这样任何时刻断电，要么是旧数据，要么是新数据，不会出现半新半旧。
• 日志式元数据。元数据更新有日志，可以回滚。
• 磨损均衡。内置动态和静态磨损均衡，延长闪存寿命。
• 掉电检测。有专门的机制检测未完成的写入。

用LittleFS的话，覆写方案也能做到掉电安全，因为文件系统层面保证了原子性。但LittleFS的兼容性不如FAT，拔下来插电脑读不了，需要通过设备导出。

4.3 SPIFFS：轻量但已过时

SPIFFS是ESP8266时代的产物，现在基本被LittleFS取代。它也有日志机制，但性能和可靠性都不如LittleFS，新项目不建议用。

4.4 文件系统对比

我的建议是：如果设备需要经常拔卡插电脑读数据，用FAT32+追写方案；如果数据只在设备内部用，优先LittleFS。

5. 硬件层：SD卡本身的掉电陷阱

方案和文件系统都选好了，还有硬件层的坑等着你。SD卡不是普通的EEPROM，它内部有个复杂的控制器，掉电时可能给你带来意外。

5.1 SD卡内部FTL的掉电风险

SD卡内部有闪存转换层（FTL），负责逻辑地址到物理地址的映射、垃圾回收、磨损均衡。这些操作对主机是不可见的，但掉电时可能出问题。

最危险的情况是：SD卡正在做垃圾回收，把数据从一个物理块搬到另一个物理块，这时候断电，映射表可能处于不一致状态，导致数据丢失甚至卡无法识别。

这个风险无法从主机端完全消除，但可以降低：

• 避免频繁小写入。小写入会触发更多垃圾回收。追写方案如果每条记录很小，反而可能增加风险。可以攒一批记录再写。
• 写入后等待足够时间。写完数据后不要立即断电，给SD卡内部整理的时间。具体等多久因卡而异，一般建议至少几百毫秒。
• 选用工业级SD卡。工业级卡在掉电处理上更稳健，但价格也更高。

5.2 掉电检测电路的必要性

如果你的设备有断电可能（比如拔电源、电池耗尽），强烈建议加掉电检测电路。原理很简单：在电源输入端加一个大电容，同时用ADC或比较器监测电压。当检测到电压开始下降时，立即触发中断，在电容电量耗尽前完成关键数据的保存。

这个电容的容量要计算：假设系统功耗100mA，需要维持50ms来完成保存，电压从5V降到3V，那么电容容量C = I × t / ΔV = 0.1A × 0.05s / 2V = 2500μF。实际要留余量，选4700μF或更大。

掉电检测的响应时间也很关键。从检测到电压下降到实际断电，可能只有几毫秒到几十毫秒。所以中断处理要极简：只做最关键的保存操作，其他事后面再说。

5.3 SD卡写入的物理特性

SD卡的写入单位是扇区（通常512字节）和块（通常几KB到几十KB）。写入小于一个块的数据时，SD卡内部会做读-改-写操作，这个过程中断电风险更高。

所以追写方案里，如果每条记录很小（比如几十字节），可以考虑攒够一个块再写。但这样又增加了内存占用和掉电时丢失的数据量。需要权衡。

6. 实测验证：怎么确认你的方案真的不掉数据

方案设计完了，不实测都是纸上谈兵。我总结了一套验证方法，可以在实验室里模拟掉电，看你的方案到底靠不靠谱。

6.1 掉电模拟测试方法

方法一：继电器控制电源。用继电器或MOS管控制设备电源，用单片机随机触发断电，每次断电后重新上电，检查配方文件是否可读、数据是否正确。这个方法的优点是接近真实掉电，缺点是测试周期长。

方法二：软件模拟。在写入函数里插入随机延迟或随机返回错误，模拟写入失败。这个方法快，但无法模拟文件系统元数据损坏和SD卡内部问题。

方法三：逻辑分析仪抓时序。用逻辑分析仪抓SD卡的命令和响应，看写入过程中断电时SD卡处于什么状态。这个方法适合深度分析，但需要专业设备。

我通常用方法一和方法二结合：先用方法二快速筛选方案，再用方法一验证最终方案。

6.2 测试用例设计

测试用例要覆盖各种边界情况：

• 写入过程中断电。在写头部、写数据、写结束魔数、fsync等各个阶段断电。
• 连续多次断电。模拟反复掉电，看文件系统是否会累积损坏。
• 文件满时断电。文件增长到需要分配新簇时断电。
• 整理过程中断电。在整理文件时断电，看是否能恢复。
• 不同容量和品牌的SD卡。不同卡的FTL行为不同，要多测几种。

每个用例至少跑100次，统计成功率。我的经验是，好的方案应该做到99.9%以上不丢数据，剩下的0.1%是SD卡内部问题，无法完全避免。

6.3 数据恢复和自愈机制

即使方案再好，也不能保证100%不丢。所以还需要数据恢复和自愈机制：

• 启动时扫描。每次启动时扫描配方文件，找到最新有效记录，如果发现损坏记录，标记或删除。
• 备份文件。保留一份备份，主文件损坏时从备份恢复。
• 默认配方。如果所有记录都损坏，加载默认配方，保证设备能启动。
• 日志记录。记录每次保存操作的结果，便于事后分析。

这些机制不能防止数据丢失，但能在丢失后尽快恢复，减少对生产的影响。

7. 我的最终方案和几个实战心得

说了这么多，最后分享一下我在实际项目中用的方案，以及踩过的坑。

7.1 推荐方案：LittleFS + 追写 + 定期整理

对于新项目，我的首选是LittleFS + 追写记录 + 定期整理。LittleFS保证了文件系统层面的掉电安全，追写记录保证了应用层面的数据完整，定期整理控制文件大小。

具体参数：

• 记录结构用魔数+长度+CRC+结束魔数，头部16字节，结束魔数4字节。
• 每条记录最大1KB，超过就分多条。
• 文件超过64KB或记录超过64条时触发整理。
• 整理在启动时执行，避免运行中整理的风险。
• 每次写入后调用fsync，确保数据落盘。

这个方案在我最近三个项目里跑了两年多，现场掉电几十次，没有丢过配方。

7.2 如果必须用FAT32

如果设备需要拔卡插电脑读数据，必须用FAT32，那就用追写方案，并且注意：

• 文件预分配足够空间，避免运行中扩展文件。可以在格式化时创建一个固定大小的文件，追写时只覆盖已有簇，不分配新簇。
• 每次写入后fsync，并且等待至少100ms再允许断电。
• 定期整理，但整理时用"写新文件再替换"策略。
• 加掉电检测电路，给保存留出时间。

7.3 几个容易忽略的细节

SD卡的热插拔问题。如果设备运行中拔卡，文件系统可能处于不一致状态。建议加卡检测电路，检测到拔卡时立即停止写入并卸载文件系统。

SD卡的寿命问题。追写方案虽然安全，但写入次数多，SD卡寿命消耗快。要选高质量卡，并且做好磨损均衡（LittleFS自带，FAT32没有）。

文件名的坑。FAT32对文件名有8.3限制（短文件名），长文件名需要额外支持。LittleFS没有这个限制。如果配方文件名很长，注意兼容性。

时区和时间戳。配方记录里通常要带时间戳，但嵌入式设备可能没有RTC。可以用启动后的运行时间或写入序号代替，读取时再转换。

多配方管理。如果设备支持多个配方，追写方案需要为每个配方维护独立的记录链，或者在一个文件里用配方ID区分。前者文件多，后者单文件大，各有优劣。

7.4 一个真实的踩坑案例

最后讲一个我踩过的坑。早期项目用FAT32+覆写方案，现场反馈偶尔丢配方。我一开始以为是写入逻辑问题，查了很久没找到。后来用逻辑分析仪抓SD卡时序，发现是SD卡内部垃圾回收导致的——写入完成后，SD卡内部还在搬数据，这时候断电就丢了。

解决方案是：写入后不立即返回成功，而是等待SD卡内部操作完成。具体做法是写入后读一次刚写入的数据，如果读出来正确，说明SD卡内部操作完成了。这个"写后读验证"虽然增加了一点时间，但大大降低了掉电丢失的概率。

这个坑让我明白，SD卡不是透明的存储介质，它有自己的"脾气"。设计掉电安全方案时，不能只考虑主机端，还要考虑SD卡内部的行为。

配方存SD卡这件事，说简单也简单，说复杂也复杂。关键是搞清楚你的场景：掉电频率多高、数据多重要、能不能接受偶尔丢失。根据这些来选方案，而不是盲目追求"最好"的方案。希望这些经验能帮你少踩几个坑。