Pebble 被选中因其高吞吐、低延迟、可预测性能，原生支持核心 KV 操作，且无 Badger 的 GC 卡顿和 Bolt 的写竞争问题，适合边缘设备与 CLI 工具等嵌入式场景。
为什么选 Pebble 而不是 Badger 或 Bolt
Pebble 是 CockroachDB 团队维护的纯 Go LSM-tree 存储引擎，目标明确：高吞吐、低延迟、可预测性能。它不支持事务快照隔离（不像 CockroachDB 那样封装层），但原生提供 Get、Put、Delete、NewIter 和 WriteBatch —— 这些已覆盖绝大多数嵌入式场景。Badger 的 GC 机制在低内存设备上容易卡顿；Bolt 的 B+tree 在写密集场景下易出现 page contention。如果你要跑在边缘设备或 CLI 工具里，且写入量中等（
初始化时必须设置 Options 的三个关键字段
直接用 pebble.Open 默认配置大概率出问题：默认 MaxOpenFiles 是 1024，在容器或 macOS 上常被系统限制击穿；默认 BytesPerSync 为 0，意味着日志不主动刷盘，崩溃可能丢最近写入；默认 DisableWAL 是 false，但 WAL 文件未压缩，小写入会快速堆积。
-
Options.MaxOpenFiles建议设为64～256（视宿主 ulimit 调整） -
Options.BytesPerSync设为512 （512KB），平衡延迟与安全性 -
Options.WALDir若数据目录 I/O 压力大，可单独指向 SSD 路径，避免和 SST 混争
示例：
opts := &pebble.Options{
MaxOpenFiles: 128,
BytesPerSync: 512 << 10,
WALDir: "/fast/wal",
}
WriteBatch 不是“批量提交”，而是“原子写入组”
常见误解：WriteBatch 是为了提升吞吐 —— 实际上它主要解决原子性。单个 WriteBatch 内的 Set/Delete 要么全成功，要么全失败（返回 error）。它不会自动合并 IO，也不绕过 WAL。真正影响性能的是你是否复用 WriteBatch 实例（避免反复 malloc）以及是否开启 Sync: true。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 高频小写推荐复用 batch 实例：
batch.Reset()比新建快 2–3 倍 - 若需强持久化（如金融类计数），务必传
&pebble.WriteOptions{Sync: true} - 不要在 batch 里塞超过 1MB 总数据，否则触发单次 write 阻塞超 10ms
错误示范：batch.Set(k, v, nil) —— 第三个参数应为 &pebble.WriteOptions{Sync: false} 或显式命名变量，nil 会 panic。
迭代器生命周期必须手动 Close，且不能跨 goroutine 复用
pebble.Iterator 底层持有文件句柄和内存映射视图，不 Close() 会导致 fd 泄露（尤其在 long-running service 中）。更隐蔽的问题是：iterator 不是线程安全的，哪怕只读，也不能在多个 goroutine 里并发调用 Next() 或 SeekGE()。
- 务必用
defer iter.Close()包裹整个迭代逻辑 - 若需并发扫描不同 key range，每个 goroutine 必须调用独立
db.NewIter() -
iter.First()后立即iter.Close()是安全的；但iter.SeekGE("a")后未Next()就 close，会漏掉该 key 对应的 entry
容易忽略的一点：iterator 的 Valid() 返回 false 后，不能再调用 Key() 或 Value()，否则 panic。
Options.L0StopWritesThreshold 触发后，Put 会阻塞，此时若业务没设 timeout，整个写入口就挂住。这点在资源受限设备上特别致命，得靠定期查 db.Metrics().Levels 主动降级处理。 
