pebble.open() 失败需显式检查错误类型，常见静默失败包括权限不足、目录不存在和manifest损坏；key不可为nil，get/put前须判空；迭代器必须close，db.close()务必defer；并发写应使用writebatch而非循环put。
pebble.Open() 失败时别只看 error == nil
直接调用 pebble.Open("data", &pebble.Options{}) 后没报错，不代表数据库可用——常见静默失败点有三个：os.IsPermission（路径不可写）、os.IsNotExist（父目录不存在）、pebble.ErrCorrupted（MANIFEST 损坏）。必须显式检查错误类型：
- 先用
os.MkdirAll("data", 0755)确保路径存在且可写，别依赖 Pebble 自动建目录 - 若错误是
os.IsPermission(err)，说明进程没权限写入该路径（尤其 Docker 容器里挂载的 volume 权限不对） - 若错误含
"MANIFEST"或"corruption"，大概率是上次异常退出导致文件损坏，删掉 data/ 下除000001.sst外所有文件再试（Pebble 不支持热修复）
Get() 和 Put() 的 key 不能为 nil，value 为空字节切片是合法的
db.Get(nil, nil) 会直接 panic：runtime error: invalid memory address；但 db.Put([]byte("k"), []byte{}) 是允许的，语义是“存一个空值”，不是删除。实际使用中必须前置判空：
- 读取前加
if len(key) == 0 { return errors.New("key cannot be empty") } - 写入前加
if key == nil { return errors.New("key cannot be nil") } - 读不到 key 时返回的是
pebble.ErrNotFound，不是nil，别用err != nil一刀切判断失败
迭代器不 Release 就 leak，Close() 漏掉就丢数据
db.NewIterator() 返回的 *pebble.Iterator 必须手动调用 it.Close()（注意不是 Release()，Pebble 已统一为 Close()），否则 fd 泄露，跑久了触发 “too many open files”；而 db.Close() 更关键——它 flush WAL、同步 memtable、释放 mmap，漏掉会导致最后一批写入永久丢失。
- 务必在 defer 中调用：
defer db.Close()，别只在 main 结束时关 - 若服务需响应 SIGTERM，用
signal.Notify捕获后主动db.Close()再退出 - 迭代器要配对使用：
it := db.NewIterator(...); defer it.Close()
并发写不加锁会覆盖，批量写要用 WriteBatch 而非循环 Put
Pebble 本身线程安全，但多个 goroutine 直接并发调用 db.Put() 仍可能因调度顺序导致逻辑覆盖（比如 A 读旧值→B 读旧值→A 算新值→B 算新值→A 写→B 写，后者覆盖前者）。高频计数器、状态更新等场景必须加锁或改用原子操作。
- 简单场景：用
sync.RWMutex包裹业务逻辑，读多写少时优先用 RLock - 高吞吐场景：用
pebble.Batch批量提交：b := db.NewBatch(); b.Set(k1,v1); b.Set(k2,v2); db.Apply(b, pebble.Sync) - 避免在循环里反复调用
db.Put()——每次都是独立 WAL 写入，性能差且易触发 write stall
db.Get() 存在 key、db.NewIterator().Next() 可遍历、db.Close() 后再 db.Get() 报 pebble.ErrClosed 这三项。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
