不能直接用buntdb.Open启动生产服务，因其默认读写模式下不区分“文件不存在”与“权限拒绝”，遇磁盘不可写、目录无权限或路径非法会直接panic；须预建目录、设权、预判路径存在性后调用。
为什么不能直接用 buntdb.Open 启动生产服务
因为 buntdb.Open 默认以读写模式打开文件，如果路径不存在会自动创建，但若磁盘不可写、目录权限不足或路径含非法字符，会直接 panic 并返回 panic: open /path/to/data.db: no such file or directory 这类底层错误——它不区分“文件不存在”和“权限拒绝”，也不提供可配置的 fallback 机制。实际部署时必须显式检查路径、预建目录、设置 umask，并用 os.Stat 预判再调用 buntdb.Open。
- 先
os.MkdirAll("/var/lib/myapp", 0755)确保父目录存在 - 用
os.Chmod("/var/lib/myapp", 0755)显式设权（尤其在容器中 uid 变更后） - 打开前做
if _, err := os.Stat("/var/lib/myapp/data.db"); os.IsNotExist(err) { ... }判断是否首次启动
如何安全地在 Goroutine 中复用同一个 DB 实例
BuntDB 的 *buntdb.DB 实例本身是并发安全的，但它的事务（Update/View）不是嵌套的，且每个事务内部不允许跨 goroutine 调用 Get/Set。常见错误是把 tx 传给另一个 goroutine，导致 panic: transaction closed 或数据不一致。
- 所有数据库操作必须在
db.Update(...)或db.View(...)的回调函数内完成，不要逃逸出闭包 - 若需并发写多个 key，用单个
Update批量操作，而非启多个 goroutine 各自调用Update（会串行阻塞） - 读多写少场景下，优先用
View；写操作必须用Update，且避免在Update中做耗时计算（如 HTTP 请求、加密）
内存模式不是纯内存：":memory:" 仍依赖临时文件系统
文档说 buntdb.Open(":memory:") 是内存数据库，但实际它仍会创建临时 WAL 文件（如 /tmp/buntdb-xxxxx），并在进程退出时尝试删除。若 /tmp 不可写或被挂载为 noexec，会报 open /tmp/buntdb-xxx: permission denied，甚至导致程序 crash。这不是 bug，是底层 BoltDB 的设计约束。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 真正无磁盘依赖的方案：改用
github.com/etcd-io/bbolt自定义Options.NoFreelistSync = true+ 内存os.File替换，但 BuntDB 不暴露该能力 - 稳妥做法：明确指定一个可写的临时路径，如
filepath.Join(os.TempDir(), "myapp-buntdb.db")，并确保该路径存在且可读写 - 测试环境可用
:memory:，但 CI/CD 流水线里要确认 runner 的/tmp权限，否则测试随机失败
过期键（TTL）必须手动轮询清理，没有后台 GC
BuntDB 没有内置 TTL 机制。所谓 “支持 TTL” 是指你可以在 Set 时存一个时间戳字段，然后靠外部逻辑扫描判断过期。典型误用是以为 Set("key", "val", 10*time.Second) 会自动删——这行代码根本不存在，Set 只接受三个参数：(key, value, opts ...buntdb.SetOption)，而 buntdb.SetExpiry 是唯一相关选项，但它只写入元数据，不触发自动删除。
立即学习“go语言免费学习笔记（深入）”；
- 必须自己起一个 ticker goroutine，定期执行
db.Update(func(tx *buntdb.Tx) error { ... })扫描带EXPIRY标记的 key - 扫描时用
tx.Ascend("", func(k, v string) bool { ... })配合tx.Get(key)拿元数据，不能依赖遍历顺序保证时效性 - 高频写入场景下，每秒扫描一次可能拖慢主业务；建议按 key 前缀分片，错峰清理
真正需要自动 TTL 的场景，别硬套 BuntDB，直接上 Redis 更省心。BuntDB 的定位是嵌入式、低依赖、强一致的本地 KV，不是功能完备的缓存中间件。
