os.writefile 不适合 kv 持久化，因其无并发保护、崩溃易截断、全量读写导致 o(n) 复杂度且零容错；仅适用于一次性配置文件写入。
为什么别用 os.WriteFile 做 KV 持久化
它根本不是“持久化”，只是“碰巧没丢”。并发写会静默覆盖，崩溃时文件截断，改一个 key 就要全量读写——O(n) 时间、O(n) 内存、零容错。真实场景下，os.WriteFile 只适合一次性写配置文件，不能当 KV 引擎底座。
os.O_APPEND + binary.Write + file.Sync() 是 WAL 的铁三角
追加写日志（WAL）是轻量 KV 文件引擎的起点，但三者缺一不可：
-
os.O_CREATE | os.O_RDWR | os.O_APPEND打开文件，确保每次Write()都落到末尾，不覆盖旧数据 - record 格式必须固定：先写
uint32(len(key))，再写 key 字节，再写uint32(len(value))，最后写 value 字节 - 每条 record 写完后必须立刻调
file.Sync()，否则kill -9或断电就丢最后几条——这是 90% 自研引擎数据不一致的根源 - 绝对不要用
bufio.Writer包裹文件句柄，它的缓冲会绕过Sync()语义
内存 map 要加载 WAL，更要标记 dirty
纯 map[string][]byte 读快但重启即丢；只靠 WAL 又太慢。折中做法是启动时顺序扫描 WAL 加载最新值，并在内存结构里记录哪些 key 已更新但未落盘：
- 用
map[string]struct{value []byte; dirty bool}，比单独维护dirty set更省内存 -
Put()必须先写 WAL 成功，再更新内存并置dirty = true；Get()直接查内存，不碰磁盘 -
Delete()不物理删，而是写一条value长度为 0 的 tombstone record；加载时遇到 tombstone 就从 map 中delete(m, key) -
Close()做一次全量 flush——简单场景够用，也避免后台刷盘线程与 WAL 写入冲突
别自己封装 flock，os.Rename + sync.RWMutex 更可靠
Go 标准库没有跨平台文件锁封装：syscall.Flock 在 Linux 有效，macOS 要用 syscall.FcntlFlock，Windows 直接 panic。更糟的是 advisory 锁拦不住外部进程写入。
- 写新文件 →
os.Rename()原子覆盖，配合os.Chmod(tmpFile, 0600)控制权限 - 读操作用
RWMutex.RLock()，写操作用RWMutex.Lock()，锁粒度保持整个 map 一把锁即可 - 不要在锁内做任何 I/O 或耗时计算，尤其别在
LoadOrStore里嵌套文件操作 - 若需强一致性且支持热读写，优先选
go.etcd.io/bbolt——它已解决锁、崩溃恢复、并发等所有底层问题
Sync 调用时机、tombstone 解析逻辑、损坏 record 跳过策略）决定你写的到底是个玩具，还是能放进生产环境的存储模块。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
