因为“简单”和“高性能”在本地存储里常是矛盾的——BoltDB写放大低但单写瓶颈明显，Badger吞吐高却依赖GC和goroutine调度；若只需键值存取、无事务、不联网、数据量GB级以内，自研mmap+WAL轻量引擎更可控、启动更快、内存更稳。
为什么不用直接上 BoltDB 或 Badger
因为“简单”和“高性能”在本地存储里常是矛盾的——boltdb 写放大低但单写瓶颈明显，badger 吞吐高却依赖 gc 和 goroutine 调度。如果你只需要键值存取、不需事务、不连网络、数据量在 gb 级以内，自己撸一个 mmap + wal 的轻量引擎，反而更可控、启动更快、内存占用更稳。
核心思路就两条：mmap 做只读数据区（零拷贝读），WAL 文件做顺序写入（避免随机 IO），所有写操作先落盘再更新内存索引。
如何用 mmap 实现零拷贝读取
mmap 不是银弹：它把文件映射进虚拟内存，读时才触发 page fault 加载页，适合读多写少、数据局部性好的场景。但 Go 的 syscall.Mmap 返回的是 []byte，不能直接当结构体用，必须手动解析字节布局。
- 数据文件按固定 record size 切块（比如 64 字节 header + 可变长 value），header 里存 key hash、key len、value len、timestamp
- 用
unsafe.Slice+unsafe.Offsetof定位字段，别用binary.Read—— 那会拷贝内存 - 务必在
Open()时调用runtime.LockOSThread()，防止 goroutine 迁移导致 mmap 地址失效（尤其 macOS 上容易 panic） - 关闭时调用
syscall.Munmap，否则 Linux 下/proc/meminfo的Mapped项会持续增长
WAL 文件怎么写才能不拖慢性能
WAL 不是日志，是唯一权威写源。它的设计目标只有一个：每条写入必须 fsync 成功，且不能阻塞主逻辑。常见错误是把 os.Write 和 file.Sync() 放一起，这会让每次写都等磁盘确认。
- 用
os.O_APPEND | os.O_CREATE | os.O_WRONLY打开 WAL 文件，避免自己维护 offset - 写入前先序列化到
sync.Pool里的[]byte缓冲区，避免频繁 malloc - 用单独 goroutine + channel 批量消费写请求，每 10ms 或满 4KB 触发一次
file.Write()+file.Sync() - WAL 记录格式要带 CRC32 校验（用
hash/crc32.MakeTable预生成 table），防止断电后尾部脏数据污染主文件
内存索引该用 map 还是 slice
如果 key 是定长且分布均匀（比如 UUID），用 []uint64 存 offset + size 更快；如果是任意字符串，map[string]uint64 是唯一选择，但要注意两点：
立即学习“go语言免费学习笔记（深入）”；
- 初始化时预设
make(map[string]uint64, 100_000)，避免扩容时 rehash 锁表 - 删除 key 时不
delete()，而是把对应 offset 设为 0，并在 compaction 阶段批量清理——否则高频删写下 map 碎片会越来越重 - 读操作加
sync.RWMutex，但写操作必须先锁 WAL goroutine channel，再更新 map，顺序不能反，否则可能读到未落盘的脏数据
最易被忽略的一点：mmap 映射区域的长度可能随 compaction 改变，但 Go 的 syscall.Mremap 在 darwin 上不可用，所以实际实现中应预留 10% 文件空间，靠定期 rewrite 全量数据来收缩，而不是动态 remap。
