RocksDB因依赖多、编译体积大、需线程池与后台线程，不适用于裸机/RTOS；LevelDB虽更轻但仍含冗余模块；嵌入式需极简LSM实现——仅保留MemTable、SSTable、LSMEngine三个类，单头文件无外部依赖，硬编码配置，禁用异常/RTTI/动态内存，确保64KB内存限制与原子compaction。
为什么不用 LevelDB / RocksDB？
嵌入式场景下，RocksDB 的依赖多、编译体积大（静态链接后常超 2MB），rocksdb::DB 启动需线程池、内存分配器、后台 flush/compaction 线程——这些在裸机或 RTOS 上根本跑不起来。LevelDB 更轻但仍有 leveldb::DB 抽象层、Env 接口、Cache 和 FilterPolicy 等冗余模块。你要的不是“能用”，而是“只保留 MemTable + SSTable + 单次 Compaction”这三块骨头。
核心结构怎么砍到只剩 3 个类？
去掉所有抽象基类和工厂模式，硬编码路径与配置。三个类必须共存于单头文件（kv_lsm.h），无外部依赖：
-
MemTable：用std::map<:string std::string></:string>（非std::unordered_map，避免哈希冲突和 rehash 分配）；插入时不做任何合并，仅追加；大小阈值设为 4KB（可调），超限即冻结为ImmutableMemTable（本质是同类型对象，只读） -
SSTable：每个文件 = 一个.sst文件，格式固定：前 4 字节为 block 数量（uint32_t），后续每个 block 是key_len(uint16_t) + key + val_len(uint16_t) + val，无索引、无布隆过滤器；读取时顺序扫描（嵌入式 Flash 随机读不比顺序读快多少） -
LSMEngine：持有当前MemTable、若干已冻结的MemTable（待刷盘）、以及按层级编号的std::vector<:string></:string>记录各层 SST 文件名（L0 是最新刷出的，L1 是 L0 compact 后的……最多只维护 2 层）
Compaction 怎么做到“一次写完不中断”？
嵌入式不能边读边写、不能后台调度，所以 compaction 必须是原子同步操作：先读 L0 所有 SST + 当前 ImmutableMemTable → 归并排序去重（key 最新值胜出）→ 写入新 L1 文件 → 原子 rename 替换 → 删除旧文件。关键点：
- 归并时用
std::vector<:pair std::string>></:pair>缓存全部键值对，避免多次 malloc；总内存占用 ≤ 64KB（可配置） - 不校验 CRC，不写 footer；文件名硬编码为
"l1_001.sst"这类格式，用snprintf生成，不依赖<filesystem></filesystem> - 若 compaction 中断（掉电），下次打开时检测到 L1 文件不完整（长度非 4 的倍数，或 block 头非法），则直接删掉该 L1 并降级回 L0 模式（容忍数据丢失，不 panic）
API 设计要避开哪些 C++ 陷阱？
嵌入式环境禁用异常、RTTI、动态 new/delete（尤其在中断上下文附近）。所以：
立即学习“C++免费学习笔记（深入）”；
- 所有函数返回
int错误码：0成功，-1OOM，-2IO error，-3corrupted file -
Get()不返回std::string&或std::optional，而是要求调用方传入缓冲区：int Get(const char* key, size_t key_len, char* val_buf, size_t* val_len)；若*val_len不足，返回-1并把所需长度写入*val_len - 构造函数不抛异常，不隐式分配内存；
LSMEngine(const char* path)只做路径合法性检查（如是否含".."），真正初始化延迟到第一次Put()
最易被忽略的是：SST 文件必须用 O_SYNC（Linux）或 FILE_FLAG_WRITE_THROUGH（Windows CE）打开，否则掉电后可能只刷了部分 block。这点没做，整个 LSM 就只是个纸糊的可靠性模型。
