os.writefile 不适合 kv 持久化，因其不原子、无容错、不支持增量更新，且并发写会覆盖、崩溃导致数据丢失、全量序列化开销大、缺乏索引无法 mmap 快速定位。
为什么 os.WriteFile 不适合做 KV 持久化层
直接用 os.WriteFile 覆盖整个文件来存键值对，看似简单，实则埋下多个崩溃点：它既不原子，也不容错，更不支持增量更新。
- 并发写入时，两个 goroutine 同时调用
os.WriteFile，后执行的会静默覆盖前一个，丢失部分数据 - 进程在写入中途 panic 或被 kill，文件可能截断、乱码，整个 KV 数据不可恢复
- 哪怕只改一个
"user:123.status"，也要把全部键值反序列化进内存、修改、再全量序列化写回——O(n) 时间 + O(n) 内存 - 没有 footer、index 或 block 对齐，后续无法做 mmap 快速定位、也无法跳过无效 record
必须用临时文件 + Sync + Rename 的原因
这不是“多此一举”，而是绕不开的底层约束：Linux/macOS/Windows 的 os.Rename 在同一文件系统内是原子操作，但仅限于重命名；而 file.Sync() 是唯一能强制把页缓存刷到磁盘的 Go 标准库方法。
-
os.Create或os.OpenFile创建的文件默认走内核页缓存，断电即丢，必须显式调用file.Sync() - 临时文件（如
db.json.tmp）需与目标文件同目录，否则跨文件系统时os.Rename会退化为 copy+delete，失去原子性 - 重命名失败时，必须手动清理临时文件，否则残留
.tmp文件越积越多——建议用defer os.Remove(tmpPath)配合错误分支显式清除
JSON vs Gob：桌面应用选哪个序列化格式
选格式不是看性能高低，而是看谁更贴合你的交付场景和运维习惯。
-
encoding/json：字段必须首字母大写（导出），支持json:"key_name"标签兼容旧数据；人类可读，方便用户手动编辑或调试；Web 管理界面可直接复用 -
encoding/gob：Go 专属，支持私有字段、无 tag 映射；体积小、序列化快；但一旦结构体字段名变更（如UserName→Username），旧文件反序列化会静默丢字段 - 二者都要求启动时处理读取失败：用
os.IsNotExist(err)判断文件不存在，提供默认值 fallback，而不是panic
路径必须按平台规范获取，不能硬编码
写死 "./data.json" 或 "~/config.json" 在桌面应用中等于主动放弃 macOS Sandbox、Windows UAC 和 Linux XDG 兼容性。
- 配置类数据应存：
xdg.ConfigHome（Linux/macOS）或os.Getenv("APPDATA")（Windows） - 数据类文件（如 KV 库）应存：
xdg.DataHome或os.Getenv("LOCALAPPDATA") - 绝对不要写进二进制同级目录——打包成 UPX 或
go build -ldflags="-H=windowsgui"后该路径不可写 - 推荐用
github.com/adrg/xdg，它自动处理~/.config/%APPDATA%/~/Library/Application Support的映射
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
