goleveldb.OpenFile需显式处理错误并确保目录可写，Put/Get的key/value必须用[]byte显式拷贝，迭代器必须调用it.Release()，并发写需自行加锁或使用WriteBatch保证原子性。
goleveldb.OpenFile 打不开数据库目录就报错
LevelDB 不是纯内存库，它必须写入磁盘，goleveldb.OpenFile 第二个参数是 *opt.Options，但很多人直接传 nil，结果在只读文件系统、权限不足或路径不存在时静默失败或 panic。真正该做的是显式处理错误，并确保目录可写。
- 调用前先
os.MkdirAll创建路径，别依赖 LevelDB 自动建目录（它不干这事） - 检查返回 error 是否为
leveldb.ErrClosed或os.IsPermission，而不是只看nil - Windows 下路径含中文或空格一般没问题，但若用
syscall.UTF16FromString手动转字符串反而容易出错——直接传 Go 原生string即可
Put/Get 时 key/value 必须是 []byte，不能传 string 直接塞
goleveldb.Put 和 goleveldb.Get 的 key/value 参数类型固定为 []byte，Go 字符串虽可隐式转切片，但底层共享底层数组——如果后续复用该字符串变量，可能被 LevelDB 内部缓冲区意外修改。这不是 bug，是设计使然。
- 安全做法：用
[]byte(s)显式拷贝，尤其当s来自用户输入或长生命周期变量时 - 性能敏感场景（如高频计数器）可复用
sync.Pool管理[]byte缓冲，但注意 Pool 中的 byte slice 长度不可控，需重置cap或用bytes.Reset - 避免对 value 做结构体
unsafe.Pointer强转——LevelDB 不认 Go 类型系统，只存字节流
迭代器遍历必须显式 Close，否则 fd 泄露
db.NewIterator 返回的 *leveldb.Iterator 是资源持有者，底层绑定了文件描述符和内存映射。它不实现 io.Closer 接口，但必须手动调用 it.Release()（不是 Close），否则进程运行久了会 hit “too many open files”。
- 常见错误：用
for it.Next() { ... }循环完就结束，忘了it.Release() - 正确姿势：用
defer it.Release()包裹整个逻辑块；若迭代中途break，也要确保Release被调用 - 注意
it.Release()可被多次调用，是幂等的，但it.Next()在Release后行为未定义，会 panic
并发写入不加锁会丢数据，但读写可并行
goleveldb 本身线程安全，允许多 goroutine 同时调用 Get 或混合 Get/Put，但多个 Put 并发写同一 key 时，结果取决于调度顺序，没有原子 compare-and-swap。它不提供事务，也没有批量写入的原子性保证（WriteBatch 是有，但默认不开启）。
立即学习“go语言免费学习笔记（深入）”；
- 需要强一致性更新？用
db.Write+leveldb.Batch，把多个操作包进一个 batch 再提交 - 高频小写入别每条都
Put，攒一批再Write(batch)，吞吐能高 3–5 倍 - 不要在
Put后立刻Get验证——LevelDB 有 memtable 到 sstable 的 flush 延迟，除非你调了sync:true选项（牺牲性能换立即可见）
OpenFile 的路径、Put 的字节切片生命周期、Iterator 的释放时机，还有并发写入的语义边界。这些地方一松懈，问题往往不是报错，而是数据慢慢不对劲。 
