擦除是将Flash单元恢复为全“1”态的不可逆操作，受限于寿命、扇区粒度和耗时，需通过统一对象数组（定长头+变长体、位图管理、写时追加）规避频繁擦除；实战采用惰性擦除、双扇区轮换与原子提交保障可靠性。
理解擦除特征的本质约束
擦除不是清零，而是将Flash物理单元恢复为全“1”态（0xFFFFFFFF），这是写入新数据的前提。它不可逆、有寿命限制（通常1万–10万次）、以扇区为最小单位（如STM32中16KB–128KB），且耗时远高于读/写操作。这些硬性约束意味着：不能为每个小对象单独分配一个扇区；不能频繁擦除同一区域；更不能把内存数据库的“动态更新”逻辑直接套用到Flash上。
统一对象数组的关键设计原则
所谓“统一对象数组”，是指在固定大小的连续内存块（如一块Flash扇区）中，不按传统结构体对齐方式布局，而是采用紧凑打包+元数据驱动的方式组织任意类型的数据实体。其核心不在于“擦除本身”，而在于**规避擦除频次、延长扇区寿命、并保证运行期可安全访问**。
- 定长头+变长体结构：每个实体前置4–8字节头，含类型ID、有效长度、校验和、状态标记（如VALID/DELETED/PENDING）；主体紧随其后，无填充，无指针。
- 位图（Bitmap）管理空闲空间：不维护链表或空闲块列表，而用1 bit代表1字节是否已被占用。擦除前整扇区置为0xFF，写入时从低位起扫描位图找连续空位；删除仅翻转对应位图+置头状态为DELETED，不立即擦除。
- 写时追加，读时聚合：新增实体总追加到扇区末尾可用区；读取某ID实体时，需遍历全部头信息并取最新有效版本（类似LSM-tree的SSTable读路径），旧版本自动被忽略。
实战中如何应对擦除触发时机
真正的挑战不在写入，而在何时、为何、如何擦除——这决定了系统能否长期稳定运行。
- 惰性擦除（Lazy Erase）：仅当空闲空间低于阈值（如15%）且追加失败时，才启动后台擦除流程。优先选择已标记DELETED最多、有效数据最少的扇区。
- 双扇区轮换（Two-Sector Swap）：始终维护两个扇区A/B。写操作只在当前活跃扇区进行；擦除时，将另一扇区中所有VALID实体迁移至当前扇区尾部，再擦除原扇区。这样每次擦除前，目标扇区已为空，无需读-改-写，极大降低掉电风险。
- 原子提交与断电防护：每个写入操作以“头校验+体CRC+尾标记”三段式落盘；擦除前先写入元数据日志（如扇区切换指令、迁移摘要）到独立小扇区；重启后依日志回放，确保状态一致。
超紧凑内存数据库的落地要点
该设计本质是面向嵌入式非易失存储的轻量级IMDB，不是通用SQL引擎。它适合保存设备配置、传感器快照、事件日志等生命周期明确、查询模式简单（按ID查最新/按时间范围扫）的数据。
- 不支持就地更新：修改某实体 = 写入新版本 + 标记旧版本为DELETED。靠读时过滤保障语义正确性。
- 类型ID即调度入口：运行期通过类型ID查注册表，获取解析函数指针、序列化尺寸、校验规则，实现异构实体统一管理。
- 压缩可选但推荐：对数值型字段（如温度、时间戳）启用Delta+RLE编码，配合列式感知（虽是行存，但同字段相邻存放），实测可再降40% Flash占用。
