直接用 github.com/tecbot/gorocksdb 易编译失败，因依赖本地 RocksDB C++ 开发包及匹配编译环境；初始化 Options 须慎设内存、WAL 等参数；写入优先用 WriteBatch 并及时 Destroy；关闭 DB 前须依次调用 db.Close()、db.Destroy()、options.Destroy()。
为什么直接用 github.com/tecbot/gorocksdb 容易编译失败
因为 RocksDB 是 C++ 库，Go 通过 CGO 调用，必须本地有匹配的 C++ 编译环境和依赖头文件。常见错误是 fatal error: rocksdb/c.h: No such file or directory，本质是没装 RocksDB 的开发包，或版本不匹配。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Linux 上先装
librocksdb-dev（Ubuntu/Debian）或rocksdb-devel（CentOS/RHEL），不是只装rocksdb运行时包 - macOS 用 Homebrew 装：运行
brew install rocksdb，再确认pkg-config --modversion rocksdb能输出版本 - 如果用自编译 RocksDB（比如要启用 LZ4 或 ZSTD），务必导出
CGO_CFLAGS和CGO_LDFLAGS，例如：export CGO_CFLAGS="-I/path/to/rocksdb/include"<br>export CGO_LDFLAGS="-L/path/to/rocksdb/lib -lrocksdb"
- Go module 中禁用 vendor 模式时，
go build可能跳过 CGO 环境检查，建议显式加CGO_ENABLED=1 go build
初始化 gorocksdb.Options 时哪些参数不能乱设
RocksDB 启动即加载选项，错配会导致打开 DB 失败、性能骤降甚至静默数据损坏。最常踩坑的是内存相关和 WAL 配置。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
options.SetCreateIfMissing(true)必须设，否则 DB 目录不存在时直接 panic，错误信息是IO error: While open a file for random read - 别碰
options.IncreaseParallelism(n)默认值（通常是 CPU 核数），设太高反而因线程争抢降低吞吐；压测时可调到n-1试试 -
options.SetWalDir()如果和dataDir不在同块盘上，WAL 写入可能成瓶颈；SSD 上建议和 data 放一起，HDD 上可分离但需确认 I/O 路径无冲突 - 开启压缩（如
options.SetCompression(gorocksdb.SnappyCompression)）前，确认链接时带了对应库（-lsnappy），否则运行时报undefined symbol: snappy_compress
写入时用 WriteBatch 还是单条 Put？
单条 Put 每次都触发 WAL flush + memtable 插入，吞吐低、延迟抖动大；WriteBatch 把多操作合并为一次原子写，但要注意 batch 大小和生命周期管理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 批量写场景（如导入、同步）必须用
batch := gorocksdb.NewWriteBatch()，每 100–1000 条batch.Put()后db.Write()一次，避免 batch 占用过多内存 -
batch用完必须调batch.Destroy()，否则 C++ 对象不释放，长期运行会内存泄漏——这是 Go 用户最常漏的一步 - 不要在 batch 里混用
Delete和Put同一个 key，RocksDB 不保证执行顺序，结果不可预测 - 高并发写入时，多个 goroutine 共享一个
WriteBatch会崩溃，每个 goroutine 必须独占 batch 实例
关闭 DB 前必须做三件事
Go 程序退出前没正确释放 RocksDB 资源，轻则 fd 泄漏、下次启动报 Lock file exists，重则 WAL 未刷盘导致数据丢失。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 调
db.Close()—— 这只是关 Go wrapper，C++ 层还在跑 - 紧接着调
db.Destroy()（注意不是DestroyDB），它会同步刷 WAL、释放 memtable、删 lock 文件 - 最后别忘了
options.Destroy()和rocksdb.GetVersion()相关静态资源清理（如果有调用过） - 如果你用了
gorocksdb.OpenDbForReadOnly()，关闭时要用对应的rocksdb.CloseDbForReadOnly()，混用会 crash
真正麻烦的点不在代码量，而在 CGO 跨语言生命周期管理——C 对象没销毁，Go 的 GC 一点也帮不上忙。稍不注意，就是凌晨三点看 OOM 日志。
