来自 #112 的架构级评审建议。不阻塞合入，仅供参考是否有更好的架构解法。
💡 [建议 · 兼容] storage/zstorage/memtable.go:63
问题根因：NewMemTable() 中移除了 mt.recoverFromWAL() 调用，但未添加任何等效的恢复机制。如果将来 Raft 日志重放后需要将已提交数据恢复到 MemTable（例如重启时从快照重建），当前 NewMemTable() 创建的 active 表是空的，需要外部调用 FlushToSSTable 或逐条 Put 来加载数据。这个缺失不是 bug——WAL 本来就是死代码——但 NewMemTable 的语义变了：它不再承诺「启动时从持久化存储恢复」。
为什么低级解法不够：补一句注释说明「不再从 WAL 恢复」只解决了文档问题，没有从根本上澄清 MemTable 的持久化契约——创建之后，数据从哪里来？
架构级方案：在 NewMemTable() 的文档注释中明确其职责边界：NewMemTable 只创建空的内存结构，数据的恢复（从 Raft Snapshot / SSTable）由上层引擎在创建后通过显式调用 FlushToSSTable 或 Put 完成。可在 Engine 初始化层做一个统一的数据恢复入口（如 Engine.recover()），将「从何处恢复」的决策集中管理，而非散落在各个子组件中。
代价/收益：代价：需要写文档/注释，以及可能在 Engine 层增加一个清晰的恢复入口（目前可能已在 Raft 层处理）。收益：每个组件的职责单一，恢复流程可追踪。
💡 [建议 · 兼容]
storage/zstorage/memtable.go:63问题根因：
NewMemTable()中移除了mt.recoverFromWAL()调用，但未添加任何等效的恢复机制。如果将来 Raft 日志重放后需要将已提交数据恢复到 MemTable（例如重启时从快照重建），当前NewMemTable()创建的 active 表是空的，需要外部调用FlushToSSTable或逐条Put来加载数据。这个缺失不是 bug——WAL 本来就是死代码——但NewMemTable的语义变了：它不再承诺「启动时从持久化存储恢复」。为什么低级解法不够：补一句注释说明「不再从 WAL 恢复」只解决了文档问题，没有从根本上澄清 MemTable 的持久化契约——创建之后，数据从哪里来？
架构级方案：在
NewMemTable()的文档注释中明确其职责边界：NewMemTable只创建空的内存结构，数据的恢复（从 Raft Snapshot / SSTable）由上层引擎在创建后通过显式调用FlushToSSTable或Put完成。可在Engine初始化层做一个统一的数据恢复入口（如Engine.recover()），将「从何处恢复」的决策集中管理，而非散落在各个子组件中。代价/收益：代价：需要写文档/注释，以及可能在 Engine 层增加一个清晰的恢复入口（目前可能已在 Raft 层处理）。收益：每个组件的职责单一，恢复流程可追踪。