pebble.Open()后必须检查err并显式管理生命周期，Close()是必须调用而非可选，Get/Put需校验nil key，批量写需防范超长key，Pebble无schema和跨key事务，仅为裸KV存储。
直接用 pebble.Open() 启动数据库不等于可用，漏掉 db.Close() 会丢数据、卡进程、占文件句柄——这不是警告，是生产事故的常见起因。
pebble.Open() 后必须检查 err 并显式管理生命周期
很多人以为 pebble.Open() 返回非 nil db 就万事大吉，其实它可能返回 nil, err（比如路径不可写），也可能返回 db, nil 但内部 WAL 初始化失败。必须立刻判 err：
-
db, err := pebble.Open("data", &pebble.Options{})后不能跳过if err != nil -
Options{}不能空：至少设BytesPerSync: 512 * 1024（防 WAL 写崩）和FS: vfs.Default（明确文件系统抽象） -
Close()不是“最好调用”，而是“必须调用”：它 flush WAL、同步 memtable、释放 mmap 文件映射；main 函数末尾才关？panic 一来就全丢 - 推荐写法：
defer db.Close()放在Open()成功后第一行，或用context.WithTimeout包裹整个 DB 生命周期
Get/Put 对 nil key 敏感，ErrNotFound 不是 nil 错误
pebble.Get() 和 pebble.Put() 接口看着像 map 操作，但底层对 nil 处理极暴力：
-
db.Get(nil, &pebble.IterOptions{})直接 panic：runtime error: invalid memory address，不是返回错误 - 务必前置校验：
if key == nil { return errors.New("key cannot be nil") } - 读取不存在的 key 时，
Get()返回pebble.ErrNotFound，类型是error但值不为nil；别写if err != nil一刀切，要显式比对：if errors.Is(err, pebble.ErrNotFound) -
Put()允许value == nil，语义是“逻辑删除”，不是存空字节
批量写要用 Write + Batch，但 key 长度无自动校验
pebble.Batch 是原子写入核心，但不像 SQL 有字段长度约束，它完全信任你传进来的 key：
立即学习“go语言免费学习笔记（深入）”；
- 超长 key（如 > 64KB）在 SST 文件落盘时失败，错误是模糊的
invalid argument，不会提示“key too long” -
batch.Set(key, value)不做任何长度检查，需业务层前置拦截或截断 - 写入前建议加长 key 审计：
if len(key) > 64*1024 { return errors.New("key exceeds 64KB limit") } - 注意
Write()调用本身也返回 error，必须检查；它可能因磁盘满、WAL sync 失败等中断
Pebble 不是 SQLite 替代品，它压根没 schema 和事务隔离
选 Pebble 前先问自己：你要的是 KV 存储，还是关系型能力？
- 没有表、没有 SQL、没有 JOIN、没有二级索引——它只存
[]byte到[]byte - 不支持跨 key 原子事务（如转账需扣 A 加 B），只有单 key 的 CAS 或批量原子写
- MVCC 是为 CockroachDB 的分布式事务服务的，暴露给上层的是 snapshot-based 读，不是
BEGIN/COMMIT接口 - 如果你需要备份、热迁移、SQL 查询、ACID 多语句事务，别硬套 Pebble；SQLite 或 Badger 更贴近需求
最常被忽略的一点：Pebble 的 “高性能” 是建立在你主动承担 schema 管理、版本编码、范围扫描边界控制之上的——它给你裸金属般的控制力，也把所有责任一起塞给你。
