Pebble 数据库需用 pebble.Open() 初始化并检查 err，Close() 必须调用以防止数据丢失；路径须可写，Options 至少设 BytesPerSync 和 FS；Get/Put 要求 []byte 且 key 不可为 nil；批量写需防超长 key；Pebble 适用于高吞吐 OLTP 场景，无 SQL、事务隔离或二级索引。
怎么打开并正确关闭一个 Pebble 数据库
直接调用 pebble.Open() 就能初始化数据库，但“打开”不等于“可用”，必须检查返回的 err；更关键的是，Close() 不是可选操作——它会 flush WAL、释放文件句柄、同步 memtable，漏掉会导致数据丢失或进程无法退出。
- 路径必须是**可写目录**，Pebble 会在其中创建
MANIFEST、LOG和000001.sst等文件，传入只读路径会报permission denied -
pebble.Options{}不能留空：至少应设BytesPerSync: 512 * 1024（防 WAL 写崩）和FS: vfs.Default（明确文件系统抽象层） - 别在
main()末尾才Close()——实际项目中要用defer db.Close()或配合context做生命周期管理，否则 panic 时数据库来不及清理
写入和读取 KV 时要注意哪些边界条件
Pebble 的 Get() 和 Put() 看似简单，但键值都要求是 []byte，且对 nil 处理极敏感：nil key 直接 panic，nil value 允许但语义是“删除”，不是“存空”。
-
db.Get(nil, &opts)会触发panic: runtime error: invalid memory address，务必先判空：if key == nil { return errors.New("key cannot be nil") } - 读取不存在的 key 时，
Get()返回pebble.ErrNotFound，不是nil错误，别用err != nil一刀切判断失败 - 批量写用
db.Write()+pebble.Batch，但注意Batch.Set()不校验 key 长度，超长 key（如 > 64KB）会导致 SST 文件写入失败，错误信息是invalid argument，需前置截断或拒绝
为什么用 Pebble 而不是 SQLite 或 Badger
不是“哪个更好”，而是“谁更贴合你的场景”：Pebble 是为高吞吐、低延迟、强一致的 OLTP 场景设计的，比如作为 CockroachDB 底层引擎；它不支持 SQL、事务隔离级别、二级索引，也不提供内置备份工具。
- 要建表、写 SQL、做 JOIN？选
sqlite—— Pebble 连 schema 都没有，纯 kv - 需要多版本并发控制（MVCC）、跨 key 原子事务、或者热备快照？
badger更接近，但 Pebble 的 write-amplification 更低，更适合写密集型服务 - 嵌入式设备内存紧张（Options.Cache 过大 OOM，建议显式设
Cache: pebble.NewCache(32 （32MB）
常见 panic 和静默失败怎么定位
Pebble 错误大多发生在运行时，且不总是抛出有意义的错误字符串。最常踩的坑是复用已关闭的 *pebble.DB，或在 goroutine 中未同步访问 pebble.Iterator。
立即学习“go语言免费学习笔记（深入）”；
-
panic: pebble: closed—— 出现在任何 DB 方法调用后，说明你用了已Close()的实例，加个if db == nil || db.Closed() { ... }防御性检查 -
iterator.Next() returns false but err == nil—— 这不是 bug，是正常结束；但若期望还有数据却提前结束，大概率是IterOptions.LowerBound/UpperBound设错，导致范围被裁剪 - 迭代器没
Close()？不会 panic，但会泄漏 goroutine 和内存，用runtime.ReadMemStats观察Mallocs持续上涨就能确认
Pebble 的复杂点不在 API，而在它把 LSM-tree 的工程细节推到了使用者面前：memtable 切换时机、SST 合并策略、block 缓存淘汰——这些默认参数在小数据量下很友好，一旦日增写入超 10GB，就得看 db.Metrics() 里的 FlushCount 和 CompactionCount 来调优，而不是靠猜。
