Go bbolt 事务结束后保存的值切片为什么不可靠

bbolt 事务结束后保存的值切片不可靠，是因为 Bucket.Get 返回的是 bbolt 持有的字节，而不是交给调用方的独立副本。把切片赋给外部变量、放进结构体或送入 channel，都不会复制底层数据。需要跨事务使用时，必须在事务仍然打开时分配目标切片并复制；事务结束后再复制，时机已经错了。

官方地址：https://github.com/etcd-io/bbolt

让读取接口返回调用方持有的字节

假设服务从 settings 桶读取一项配置，随后放进缓存或交给后台任务。接口可以返回 (value []byte, found bool, err error)：value 是独立副本，found 表示普通键值是否存在，err 表示读取或存储结构异常。最关键的两行 make 与 copy 必须位于 View 回调内部。

package store

import (
    "errors"
    "fmt"

    bolt "go.etcd.io/bbolt"
)

// 这些错误表示存储结构或调用条件异常，而不是普通键缺失。
var ErrBucketMissing = errors.New("配置桶不存在")
var ErrNestedBucket = errors.New("目标键是子桶，不是普通值")

// LoadConfig 返回独立副本；调用方负责该副本后续的共享与同步。
func LoadConfig(db *bolt.DB, key []byte) ([]byte, bool, error) {
    if db == nil {
        return nil, false, errors.New("数据库对象为空")
    }
    var owned []byte
    var found bool
    err := db.View(func(tx *bolt.Tx) error {
        b := tx.Bucket([]byte("settings"))
        if b == nil {
            return ErrBucketMissing
        }
        if b.Bucket(key) != nil {
            return ErrNestedBucket
        }
        borrowed := b.Get(key)
        if borrowed == nil {
            // 键缺失是正常结果；不能用 len 判断存在性。
            return nil
        }
        // 必须在回调返回之前复制，不能只保存切片描述符。
        owned = make([]byte, len(borrowed))
        copy(owned, borrowed)
        found = true
        return nil
    })
    if err != nil {
        // 有错误时不向调用方交付部分结果。
        return nil, false, fmt.Errorf("读取配置失败: %w", err)
    }
    return owned, found, nil
}

这里假设 settings 桶由初始化流程建立，函数只读取，不隐式创建。缺少桶是错误，普通键缺失不是错误；目标键若是子桶，也明确报错。示例代码使用 go.etcd.io/bbolt，调用方传入已打开的 DB，并在应用生命周期结束时自行关闭数据库。不要在每次读函数中关闭共享 DB。

这份函数是实现示例，未附现场运行输出。它不保证配置永远保持最新，只保证成功返回的字节不再依赖原读取事务。后续数据库更新不会自动修改这个独立副本。

切片变量还在不代表底层字节还有效

切片可以理解为指向一段底层数组的描述符，记录指针、长度和容量。外层变量比回调活得更久，不等于它指向的 bbolt 内存也获得了更长有效期。返回值的类型同样是 []byte，但调用约定决定这些字节由谁持有、可以使用到什么时候。

// 反例：这段赋值没有复制底层字节，不能作为跨事务缓存。
var saved []byte
err := db.View(func(tx *bolt.Tx) error {
    b := tx.Bucket([]byte("settings"))
    if b == nil {
        return ErrBucketMissing
    }
    saved = b.Get(key)
    return nil
})
// 即使 err 为 nil，事务结束后也不能读取 saved 的借用字节。

反例中的 saved 与 Get 返回值是别名关系。类似的 saved = borrowed[:]、完整切片表达式或把 borrowed 赋给结构体字段，也只是在传递描述符。把它装进接口、缓存 map 或 channel，仍然没有改变底层字节的归属。

官方说明，事务结束后相关内存可能被页面重用，也可能解除映射。因此问题不一定表现为每次立刻报错；“刚刚打印还正常”不是可继续使用的保证。不要故意靠事务外读取来复现，正确边界来自 API 契约，而不是某次访问是否碰巧成功。

事务内也不能通过修改 Get 返回值来更新数据库。官方 API 明确禁止修改这段内存；需要改值时应先形成可修改的独立数据，再使用写事务中的 Put，而不是直接写 borrowed 的元素。读取副本与持久化写入是不同操作。

定义缺失值、空值和错误的返回契约

零长度值和键缺失都可能满足 len(value) == 0，所以接口不能只返回长度或据长度决定存在性。LoadConfig 在事务内检查 Get 是否为 nil，复制成功后设置 found。对于存在的空值，make 的长度是零，仍通过 found=true 表达“键存在”。

Get 对不存在的键和子桶键都返回 nil；如果业务只允许平面键值，可以约定没有子桶。本例采取更明确的做法，在 Get 前检查子桶，并将其视为结构错误，避免把“有子桶”误报成“什么都没有”。

调用时先判断 err，再判断 found，最后消费 value。函数用百分号 w 包装错误，让调用方仍能用 errors.Is 区分约定错误；不要在读取层把所有错误吞掉并返回空字节，否则闭库等异常也会被误当成正常缺失。

缓存与异步任务只接收独立副本

LoadConfig 成功返回后，owned 切片属于应用数据，可以在原 View 结束后使用，也可以按接口约定修改。它与 bbolt 原内存不共享，但不代表与其他应用消费者永远不共享：把同一个 owned 同时交给两个会修改它的 goroutine，仍需要同步，或者给各自再复制一份。

接口改造时，重点查看旧函数是否把 Get 值直接返回，是否把它放进延迟处理队列，是否只是把复制移动到了 View 调用之后。真正安全的跨事务交付边界是“在回调内完成独立副本”，不是“在业务代码开始读取前才复制”。

若只需要一个布尔结果或一个数值，可以在事务内完成计算并返回标量，不一定复制全部值。若要解析文本到结构体，解析后的对象也必须不保留对原字节的借用引用。大值复制有内存开销，应按实际消费需求设计接口；延长只读事务以避免复制，则会延长资源占用，不能无限期保留事务充当缓存。

速查表与常见疑问

读事务也有这个限制吗？

有。Get 的返回值契约以事务存活为边界，不是只针对写事务。

加锁能否让旧切片继续有效？

应用锁不会把 bbolt 的借用数据变成独立副本，也不会延长已经结束的事务。锁解决应用共享问题，复制解决数据归属问题。

复制后可以随意修改数据库中的值吗？

修改副本只改变应用中的副本。若要持久化，仍需用正确写事务调用 Put。

为什么不能用 len 判断键是否存在？

长度为零也可能是合法空值。用明确的 found 返回值承接事务内的存在性判断。

修复这个问题不必调整数据库参数：把借用值限制在事务里，把跨事务返回值做成独立数据，再明确缺失、空值与错误的接口语义即可。

参考：Bucket.Get API 契约、官方内存与事务注意事项。