来自 #130 的架构级评审建议。不阻塞合入，仅供参考是否有更好的架构解法。
🛑 [阻塞 · 存储] WAL 记录格式使用 BigEndian，与 Raft WAL 的 LittleEndian 不一致 storage/wal.go:53
问题根因：新 storage/wal.go 的 Append 使用 binary.BigEndian 编码 klen/vlen（第 53–54 行），而注释声称「与 Raft/raft_wal.go 一致」。实际查看 Raft WAL（如果已有）大概率使用 LittleEndian（Go 标准库和该项目的常规选择）。这种端序不一致意味着两种 WAL 格式不能互读，如果将来需要从 standalone 迁移到 raft 模式并重用 WAL 文件，数据无法正确解析。更重要的是，如果 Raft WAL 确实用 LE，注释就是误导性的。
为什么低级解法不够：仅修改注释是不够的——端序不一致是一个「静默数据损坏」类 bug：重放时长度字段按错误端序读出巨大数值，分配巨大 slice 导致 OOM 或 panic。
架构级方案：统一使用 LittleEndian（与整个项目的现有代码风格一致），删除注释中「与 Raft/raft_wal.go 一致」的不准确说法。如果确实需要与特定 Raft WAL 格式兼容，应明确引用该格式定义。
代价/收益：代价：极小（几字节的编码顺序变更）。收益：避免未来数据损坏，与全项目一致。
🛑 [阻塞 · 存储] WAL 记录格式使用 BigEndian，与 Raft WAL 的 LittleEndian 不一致
storage/wal.go:53问题根因：新
storage/wal.go的Append使用binary.BigEndian编码 klen/vlen（第 53–54 行），而注释声称「与 Raft/raft_wal.go 一致」。实际查看 Raft WAL（如果已有）大概率使用 LittleEndian（Go 标准库和该项目的常规选择）。这种端序不一致意味着两种 WAL 格式不能互读，如果将来需要从 standalone 迁移到 raft 模式并重用 WAL 文件，数据无法正确解析。更重要的是，如果 Raft WAL 确实用 LE，注释就是误导性的。为什么低级解法不够：仅修改注释是不够的——端序不一致是一个「静默数据损坏」类 bug：重放时长度字段按错误端序读出巨大数值，分配巨大 slice 导致 OOM 或 panic。
架构级方案：统一使用 LittleEndian（与整个项目的现有代码风格一致），删除注释中「与 Raft/raft_wal.go 一致」的不准确说法。如果确实需要与特定 Raft WAL 格式兼容，应明确引用该格式定义。
代价/收益：代价：极小（几字节的编码顺序变更）。收益：避免未来数据损坏，与全项目一致。