Flash存储管理中的erase优化策略：面向高性能与长寿命的系统级设计
在工业现场调试一个边缘网关时，我曾遇到这样一幕：设备连续运行187天后突然无法启动。用逻辑分析仪抓取启动过程，发现NAND Flash在加载Bootloader阶段反复超时——不是代码损坏，而是某几个关键block的erase时间从2.3 ms飙升到18 ms以上，控制器直接判定为坏块并跳过。拆开设备用量产工具检测，那几块P/E计数已突破9万次，而数据手册标称寿命仅10万次。这不是偶然故障，是“擦除”这个看似简单的动作，在长期运行中悄然积累的系统性熵增。
Flash的物理真相很朴素：它不支持“覆盖写”，只接受“先清空、再填入”。就像你不能在一张写满字的纸上直接涂改某个词，必须先把整页纸浸水漂白（erase），才能重写。而这张“纸”的大小，就是erase block——通常是64 KiB到1 MiB。更残酷的是，每张纸最多漂白10⁵次（SLC）甚至只有3×10³次（TLC）。一旦漂白次数用尽，纸就脆化失效，哪怕其他部分完好无损。
于是，“如何擦”就成了嵌入式存储设计中最沉默也最致命的一环。它不像CPU主频那样炫目，也不像内存带宽那样容易量化，但它决定着设备是稳定服役十年，还是半年就进返修库。本文不谈抽象理论，只聚焦三个工程师每天都会撞上的真实问题：
- 为什么改一行配置，要擦掉整个128 KiB块？
- 为什么日志写得越快，Flash死得越早？
- 为什么固件升级总在最后5%失败？
答案不在驱动层补丁里，而在对“擦除”这件事的系统级重定义。
擦除粒度：别再让冷数据为热数据陪葬
多数开发者第一次接触Flash驱动时，拿到的是一份固定映射表：逻辑块0 → 物理块0 (128 KiB)，逻辑块1 → 物理块1 (128 KiB)……这种映射简洁、省RAM、易实现，但它是把固件镜像和传感器日志关进同一个牢房——只要日志需要更新，整块牢房（包括固件）就得被“集体放风”（即擦除）。
我们做过一个实测：某网关固件占240 KiB，存放在物理块0–1；传感器缓存占16 KiB，本可放在块2，但因分区对齐要求，硬塞进块0末尾。结果每秒30次日志写入，导致块0每天被擦除420次。不到11个月，块0报废，固件丢失。
真正的解法，是让逻辑地址空间拥有“弹性皮肤”：
- 固件这类冷数据，用大块（如512 KiB）承载，映射表条目少，RAM占用低；
- 日志这类热数据，则把一个物理大块虚拟成8个16 KiB小块，每次只擦其中1个；
- 当某冷区突然出现局部热点（比如校准参数频繁修改），再动态分裂——就像给皮肤打补丁，而不是换整张皮。
关键不在“能不能分”，而在“何时分”。我们不用复杂AI模型，只盯两个数字：
-update_freq_per_hour
