Badger v1 升级到 v2/v3 遇“manifest has unsupported version”需导出/导入迁移；Update 比 View 慢因写锁和 WAL；value.log 涨满需启用 RunValueLogGC；并发读写需避免复用 Txn 并正确使用快照。
BadgerDB 初始化时 panic: “manifest has unsupported version” 怎么办
这是 Badger v1 升级到 v2/v3 后最常遇到的兼容性问题：旧数据目录无法被新版直接打开。Badger 不做向后兼容，v1 的 MANIFEST 文件格式和 v2+ 完全不兼容。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认版本：用
go list -m github.com/dgraph-io/badger/v3查你实际依赖的是 v2 还是 v3（v3 是当前主线） - 不要复用 v1 的数据目录：v1 的
./badger目录不能直接传给 v3 的badger.Open() - 迁移必须走导出/导入：用 v1 版本的
badger backup命令导出 SST 文件，再用 v3 的badger restore加载（注意路径权限和--dir/--backup-dir顺序） - 新项目直接用 v3，初始化时显式指定
Options{Dir: "./data", ValueDir: "./data"}，避免默认值在不同平台行为不一致
为什么 Update 比 View 慢很多，甚至卡住
Badger 的事务模型里，Update 是写事务，会获取写锁、刷 WAL、触发 LSM merge；View 是只读快照，几乎不阻塞。但如果你在 Update 中做了耗时操作（比如网络请求、大循环），它会一直持锁，拖慢所有后续读写。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Update函数体里只做 KV 操作：调用txn.Set()、txn.Delete()，别嵌套 HTTP 调用或解析 JSON - 批量写入用
txn.SetEntry()+txn.Commit()，别每条都Set()+Commit() - 如果必须在事务中处理逻辑，先在事务外准备好
[]*badger.Entry，再一次性txn.SetEntry() - 监控
DB.Stats().WriteStall，为 true 表示 LSM 正在 compaction，此时Update会排队等待
ValueLog 文件暴涨，磁盘吃满怎么办
Badger 默认把 value 存在独立的 value.log 文件里，且不会主动回收——哪怕 key 已被删除，旧 value 仍留在 log 中，直到 compaction 把它标记为可清理。这导致磁盘空间“只增不减”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启用 value GC：定期调用
db.RunValueLogGC(0.7)（当 70% 的 value 空间无效时触发），注意该操作会阻塞写入，建议凌晨低峰期执行 - 调小
Options.ValueLogFileSize（默认 1GB）：设为 256MB 可加快 GC 效率，但会增加文件数量 - 避免存大 value：超过 1KB 的值建议转存在外部存储（如本地文件），只在 Badger 里存路径或 hash
- 检查是否误用了
WithValueThreshold(0)：这会让所有 value 都进 value log，应设为合理阈值（如 32 或 64）
并发读写时出现 Key not found 或脏读
Badger 的事务默认是快照隔离（SI），不是读已提交（RC）。同一个 View 事务内多次 Get 看到的是事务开始时刻的快照；但不同事务之间，写事务提交后，读事务不会自动刷新快照——所以你可能在 A 事务里刚写完，B 事务立刻 View 却读不到，除非 B 新建事务。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要复用
Transaction对象：每次读/写都调用db.NewTransaction()/db.NewTransactionAt() - 需要“强一致性读”时，用
db.View()包裹，它内部会自动取最新提交时间戳 - 写后立即读，别在同一个
Update事务里Set再Get——Get在写事务里查的是未提交状态，可能返回旧值或 nil - 跨 goroutine 共享
*badger.DB安全，但别共享*badger.Txn
Badger 的 value GC 和事务快照机制是它高性能的代价，不是 bug。没意识到这两点，就容易在压测或上线后突然发现磁盘涨得飞快，或者读不到刚写的数据。
