Go sql.RawBytes 为什么只能在下一次 Next 前使用

先说结论：sql.RawBytes 不是一份由业务代码拥有的长期副本，而是引用数据库内部内存的字节切片。Rows.Scan 读入后，只能使用到下一次 Rows.Next、Rows.Scan 或 Rows.Close；如果数据要跨行保存、交给异步任务或放进缓存，就必须先复制。

官方地址：https://pkg.go.dev/database/sql#RawBytes

先确认 RawBytes 的有效窗口

官方文档把 RawBytes 定义为“引用数据库自身拥有内存”的字节切片。这个定义决定了它的使用方式：它适合在当前行里读取，不适合直接当成业务对象的长期字段。

一旦对同一个 Rows 调用下一次 Next，或者再次调用 Scan、关闭结果集，之前读到的 RawBytes 就不再处于可依赖的有效窗口。这里的“失效”不是要求你立刻看到一个固定的错误，而是说明调用方不能再把其中的字节当成稳定数据。

因此，排查这类问题时可以先看三个指标：RawBytes 是否跨过了行边界、是否跨过了下一次 Scan、是否在 Close 后仍被读取。只要其中一项成立，就应该回到 Scan 位置补一份业务拥有的副本。

当前行内直接消费，不要提前缓存引用

如果二进制字段只需要在本轮循环中解析，最省事的做法是在 Scan 后立即消费它。下面的函数只演示生命周期边界；真实项目中的 SQL 驱动、表名和查询参数应按自己的数据库配置替换。

func readPayloads(ctx context.Context, db *sql.DB) error {
    rows, err := db.QueryContext(ctx, "SELECT id, payload FROM events")
    if err != nil {
        return err
    }
    defer rows.Close() // 无论循环如何结束，都释放结果集资源

    for rows.Next() {
        var (
            id      int64
            rawData sql.RawBytes
        )
        // Scan 后 rawData 只在当前 Rows 操作窗口内可靠。
        if err := rows.Scan(&id, &rawData); err != nil {
            return err
        }

        // 当前行内立即解析；不要把 rawData 直接交给下一行仍会使用的缓存。
        if err := consumePayload(id, rawData); err != nil {
            return err
        }
    }
    // Next 返回 false 可能是正常结束，也可能是遍历错误。
    return rows.Err()
}

这里的关键顺序是 Next → Scan → consumePayload → 下一次 Next。consumePayload 可以把数据解码成结构体、计算摘要或做字段校验，但它不应该把 rawData 保存到会在循环外继续使用的对象里。

如果需要把它转成字符串用于当前日志或当前行的判断，可以在这段有效窗口内完成转换。若后续代码还会异步读取，就不要把这个“当前行内可用”的假设带到异步边界。

需要跨行保存时主动复制

跨函数、跨 goroutine、跨缓存或跨下一次 Next 保存数据时，要把借用内存复制成由应用自己拥有的切片。一个不依赖具体数据库驱动的写法是 append([]byte(nil), rawData...)。

type Event struct {
    ID      int64
    Payload []byte
}

func collectEvents(ctx context.Context, db *sql.DB) ([]Event, error) {
    rows, err := db.QueryContext(ctx, "SELECT id, payload FROM events")
    if err != nil {
        return nil, err
    }
    defer rows.Close() // 复制完成后仍要按 Rows 约定关闭结果集

    events := make([]Event, 0, 16)
    for rows.Next() {
        var (
            id      int64
            rawData sql.RawBytes
        )
        if err := rows.Scan(&id, &rawData); err != nil {
            return nil, err
        }

        // 复制发生在下一次 Next 之前，副本的底层数组归业务代码所有。
        owned := append([]byte(nil), rawData...)
        events = append(events, Event{ID: id, Payload: owned})
    }
    if err := rows.Err(); err != nil {
        return nil, err
    }
    return events, nil
}

复制的价值不在于改变字节内容，而在于改变所有权。下一次 Next 可以继续让驱动复用它自己的内存，events 中的 Payload 仍然保持不变。代价是一次分配和一次拷贝，所以只有当数据确实要越过当前行边界时才复制。

把 Scan、复制和业务边界放在同一处

最容易出错的代码不是显式的 append，而是把复制动作藏在另一个函数之后。例如先把 rawData 放进任务队列，等消费者稍后再处理；此时生产者很可能已经执行了下一次 Next，生命周期假设已经被打破。

更清晰的做法是让“是否复制”紧挨着 Scan。如果任务队列需要拥有数据，就在入队前复制；如果业务函数只在当前行内运行，就把它限制在同一次循环迭代中。

为什么再次 Scan 也算边界

很多排查只关注“下一次 Next 会不会覆盖数据”，但官方契约同时把下一次 Scan 和 Close 列为失效边界。也就是说，即使还没有进入下一行，只要复用了同一个 Rows 读取流程，之前的借用引用也不应继续被长期持有。

可以把一次行处理理解成一个很短的租借窗口：Scan 让当前字段可读，业务代码在窗口内完成转换；要越过窗口，就把数据复制出来。这个模型比“驱动可能会不会复用缓冲区”的猜测更稳，因为它直接遵守 database/sql 的公开契约。

相关问题

RawBytes 和 []byte 有什么区别

底层类型都是字节切片，但 RawBytes 明确表示它引用数据库拥有的内存，生命周期受 Rows 操作约束；普通业务 []byte 通常由应用自己管理。把 RawBytes 赋值给另一个切片变量不会自动复制底层数组。

用 copy 替代 append 可以吗

可以。先按长度创建目标切片，再调用 copy(dst, rawData)，效果同样是让目标拥有自己的底层数组。选择哪种写法主要取决于代码风格和是否需要预先控制容量。

空字段也要复制吗

如果空字段会被长期保存，仍然应让业务对象的空值语义保持明确。可以根据业务约定保存为 nil 或空切片；重点是不要把一个受 Rows 生命周期支配的引用直接泄漏到长期对象。

循环结束后为什么还要检查 rows.Err

Next 返回 false 既可能表示没有下一行，也可能表示准备下一行时发生错误。循环结束后调用 rows.Err()，才能把正常结束与遍历错误区分开。

记住一条边界即可：sql.RawBytes 适合“当前行立即用”，不适合“以后再用”。只要数据要跨过下一次 Next、Scan 或 Close，就在当前窗口内复制成业务自己拥有的 []byte。