bbolt是go语言推荐的嵌入式kv数据库，必须用go.etcd.io/bbolt导入，禁用旧路径；打开数据库需设0600权限，务必defer db.close()；读写须分离：view仅读、update才写；桶与键值均需[]byte；建桶用createbucketifnotexists，批量写用batch，调试推荐boltbrowser。
直接用 bbolt，别自己手写 KV 存储层——99% 的本地场景，它比你写的更稳、更快、更少出错。
go.etcd.io/bbolt 是唯一推荐的导入路径
旧代码里写 github.com/boltdb/bolt 会编译失败，这个模块早在 2026 年初就归档了。新项目必须用 go.etcd.io/bbolt，否则 go mod tidy 直接报 module github.com/boltdb/bolt: not found。
安装命令是：go get go.etcd.io/bbolt@latest。打开数据库时权限别偷懒，0600 是底线，否则数据文件裸露在磁盘上，等于把钥匙挂在门把手上。
-
db, err := bbolt.Open("data.db", 0600, nil)—— 路径不存在会自动创建，但父目录得你自己确保存在 - 务必
defer db.Close()：BoltDB 对文件加独占锁，不关掉，下次Open就卡死 - 别在
Update或View外调tx.Bucket()，事务没开，返回nil，后续操作直接 panic
读写必须严格分离：View 读，Update 写
db.View() 和 db.Update() 不是风格偏好，是底层锁机制硬性要求。同一时间只允许一个 Update（写事务），但允许多个并发 View（只读事务）。
常见错误：
- 在
View里调b.Put()：静默失败，返回nil，键值根本没存进去 - 在
View里调tx.CreateBucket()：直接 panic，错误类似panic: invalid operation on read-only transaction - 高频读服务全塞进
Update：写事务排队，QPS 断崖下跌
正确姿势：View 只做 Get、ForEach、Cursor 扫描；Update 里才做 Put、Delete、CreateBucketIfNotExists。
桶和键值都必须是 []byte，序列化绕不过
BoltDB 不认识 string、int、struct，只认字节切片。传 "users" 字符串？编译报错；传 string([]byte("users"))？类型不匹配，还是错。
- 桶名必须写成
[]byte("users")，不是"users" - 小整数当 key 别用
strconv.Itoa(123)，用binary.BigEndian.PutUint64(buf, uint64(123))，保证字典序 = 数值序，方便Cursor.Seek()范围查询 - 结构体存取走
json.Marshal/json.Unmarshal最省心；gob也行，但跨语言不友好 -
b.Get(k)返回nil表示 key 不存在，不是空 slice，别用len(v) == 0判空
建桶、批量写、调试：三个高频动作的避坑点
并发初始化时手写 if b == nil { tx.CreateBucket() } 是典型竞态：两个事务同时判断失败，第二个 CreateBucket 报 bucket already exists。一律改用 tx.CreateBucketIfNotExists([]byte("logs"))，它内部带原子检查。
批量写入别用 N 次 Update，性能差 5–10 倍。用 db.Batch()，它自动合并写请求到单个事务，吞吐翻几倍。超时默认 1 秒，超时后自动降级为多次 Update，不用额外处理。
调试时别靠 print 日志猜结构。装 boltbrowser：go get github.com/br0xen/boltbrowser，然后 boltbrowser data.db，打开浏览器就能树状查看所有 bucket 和 key-value。
最易被忽略的一点：BoltDB 的写吞吐受限于单 writer 锁，哪怕你用了 Batch，也无法突破单核 I/O 瓶颈。如果真遇到写压瓶颈，优先考虑是不是业务逻辑能合并写、延迟刷盘，而不是换引擎——多数时候，问题不在 BoltDB，而在事务粒度太细。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
