2、文件系统基础：嵌入式文件系统介绍（FAT32、LittleFS、SPIFFS）、文件系统选择策略

说到嵌入式系统的数据存储，很多人第一反应就是「直接往Flash里写数据不就行了？」。嗯，早期我也是这么干的。但后来项目越做越复杂，数据量越来越大，我才发现——没有文件系统，简直就是给自己挖坑。

文件系统说白了，就是帮你在存储介质上管理文件的「管家」。它负责分配空间、记录文件名、处理碎片。今天我就带大家看看嵌入式领域最常见的三个文件系统：FAT32、LittleFS、SPIFFS。顺便聊聊怎么选。

2.1 FAT32：老牌劲旅，兼容性之王

FAT32，全称File Allocation Table 32。这玩意儿诞生于1996年，比很多读者的年龄都大。但它至今活跃在嵌入式领域，为什么？

兼容性无敌。 你把SD卡插到电脑上，Windows、macOS、Linux都能直接认出来。我做过一个数据记录仪，客户要求把数据导出到电脑上直接看Excel。那没得选，只能用FAT32。

FAT32的结构其实不复杂。它把存储空间分成三块：

• 引导扇区：记录文件系统的基本信息，比如扇区大小、簇大小
• 文件分配表：核心中的核心，记录每个簇的使用情况
• 数据区：真正存文件内容的地方

但FAT32有个硬伤——单文件最大不能超过4GB。为什么？因为文件大小是用32位整数表示的，最大值就是2^32 - 1字节，约4GB。我在一个视频监控项目里就踩过这个坑，录了3个多小时的视频文件，直接写爆了。

2.2 LittleFS：为微控制器而生

LittleFS是ARM公司专门为微控制器设计的文件系统。它的设计目标很明确：小、可靠、抗掉电。

我最早接触LittleFS是在一个物联网网关项目里。设备需要频繁记录传感器数据，而且经常用电池供电，随时可能断电。FAT32在这种场景下根本扛不住，但LittleFS表现得相当稳定。

LittleFS的核心设计理念有两个：

• 写时复制（Copy-on-Write）：修改文件时，先写新数据，再更新元数据。如果中途掉电，最多丢失当前这次修改，不会破坏已有数据。
• 磨损均衡：Flash的擦写次数是有限的（一般1万到10万次）。LittleFS会尽量把数据分散写到不同区域，延长Flash寿命。

它的代码量也很小，ROM占用通常在10KB以内，RAM占用几百字节就够了。非常适合资源受限的MCU。

2.3 SPIFFS：专为SPI Flash设计

SPIFFS，全称SPI Flash File System。它比LittleFS出现得更早，专门针对SPI接口的Flash芯片优化。

SPIFFS的设计思路和LittleFS有点像，也是面向小容量、低功耗场景。但它有个明显的短板——不支持目录结构。所有文件都平铺在根目录下。文件多了以后，查找效率会下降。

我记得有个智能家居项目，用ESP8266配合SPIFFS存储配置文件和日志。一开始文件少，用着还行。后来功能越加越多，配置文件、固件更新包、用户数据……文件数量超过50个后，打开文件列表要等好几秒。最后不得不迁移到LittleFS。

SPIFFS的优势在于：

• 实现简单，代码量小
• 对SPI Flash的读写做了专门优化
• 支持磨损均衡

但它也有明显的不足：

• 不支持目录
• 文件名长度有限（通常32字节以内）
• 没有写时复制，掉电保护能力弱于LittleFS

2.4 文件系统选择策略

好了，三个文件系统都介绍完了。你可能会问：「那我到底该选哪个？」

我个人习惯用一张决策表来快速判断。你看下面这个：

需求场景	推荐文件系统	理由
需要和PC交换数据	FAT32	兼容性最好，即插即用
MCU资源紧张（RAM < 10KB）	LittleFS 或 SPIFFS	代码量小，内存占用低
频繁小数据写入，需抗掉电	LittleFS	写时复制，掉电不丢数据
需要目录结构管理文件	FAT32 或 LittleFS	SPIFFS不支持目录
存储容量 > 4GB	FAT32（不行）→ exFAT 或 LittleFS	FAT32单文件最大4GB
需要磨损均衡，延长Flash寿命	LittleFS 或 SPIFFS	两者都支持磨损均衡

我再补充几条实战经验：

• 如果项目需要长期稳定运行（比如工业设备），优先考虑LittleFS。它的可靠性经过了大量验证。
• 如果只是临时存点配置数据，SPIFFS也够用。但别存太多文件，否则性能会下降。
• 如果一定要用FAT32，记得加一个「文件系统检查」功能。每次启动时扫描一下，发现错误及时修复。我曾经在一个数据采集器里加了启动自检，成功避免了好几次数据损坏事故。

最后说一句：没有完美的文件系统，只有最适合你项目的文件系统。别盲目追新，也别死守老古董。搞清楚需求，选对工具，项目就成功了一半。