Go database/sql Rows.NextResultSet 怎么处理多结果集：扫描顺序、关闭时机与驱动差异

一次查询返回两组数据时，最容易出错的不是 SQL，而是 Go 代码把第二组结果当成了第一组的尾巴：循环结束后没有推进结果集，或者推进后直接 Scan，最后还漏掉了 Rows.Err()。database/sql 已经提供了明确的游标协议：先用 Next 消费当前结果集，再用 NextResultSet 切到下一组，切换后仍然要先调用 Next，所有集合处理完再检查错误。

先把两个游标动作分开

Rows.Next 移动的是当前结果集里的“行游标”；Rows.NextResultSet 移动的是“结果集游标”。这两个动作不是同一个层级，少一个都可能让读取逻辑看起来成功、实际丢数据。

rows, err := db.QueryContext(ctx, `CALL report_order_and_items(?)`, orderID)
if err != nil {
    return err
}
defer rows.Close()

for rows.Next() {
    var id int64
    var status string
    if err := rows.Scan(&id, &status); err != nil {
        return err
    }
    // 处理订单汇总
}

if err := rows.Err(); err != nil {
    return err
}

if rows.NextResultSet() {
    for rows.Next() {
        var itemID int64
        var sku string
        if err := rows.Scan(&itemID, &sku); err != nil {
            return err
        }
        // 处理订单明细
    }
}
return rows.Err()

这里的关键顺序是：第一组 Next 循环结束后，才调用 NextResultSet；切到第二组后，再从 Next 开始。官方文档还特别提醒，下一组可能存在但没有任何行，所以不能把“Next 返回 false”直接当成“没有下一组”。

把读取逻辑收敛成一个可检查的循环

如果结果集数量不固定，与其手写一段一段的读取，不如把“当前集合怎么扫描”和“何时切换”放在同一个外层循环里。下面的示例用列名作为证据，避免把第二组的列错扫进第一组的变量。

setNo := 0
for {
    setNo++
    columns, err := rows.Columns()
    if err != nil {
        return fmt.Errorf("result set %d columns: %w", setNo, err)
    }

    for rows.Next() {
        values := make([]any, len(columns))
        targets := make([]any, len(columns))
        for i := range values {
            targets[i] = &values[i]
        }
        if err := rows.Scan(targets...); err != nil {
            return fmt.Errorf("result set %d scan: %w", setNo, err)
        }
        // 根据 columns 和 values 映射到当前业务结构
    }
    if err := rows.Err(); err != nil {
        return fmt.Errorf("result set %d rows: %w", setNo, err)
    }
    if !rows.NextResultSet() {
        break
    }
}
if err := rows.Err(); err != nil {
    return fmt.Errorf("advance result set: %w", err)
}

这种写法的好处是证据完整：哪一组的列读取失败、哪一组扫描失败、哪一次切换失败，都能在错误中保留下来。代价是通用映射会牺牲一部分类型安全；如果存储过程的结果结构固定，优先使用前一个示例那样的强类型扫描。

三个边界最容易让测试漏掉

空结果集不是缺少结果集

第二组有列但没有行时，进入第二组后第一次 Next 会返回 false。此时要继续看 Rows.Err()，并决定是否还有后续集合；不要把一次空循环当成 SQL 没返回第二组。

提前退出必须关闭 Rows

业务只需要第一组时，读完第一组就返回也可以，但 defer rows.Close() 要在拿到 Rows 后立刻注册。显式关闭是幂等的，即使遍历到末尾自动关闭，再调用一次也不会改变 Rows.Err() 的结果。

驱动支持不是 SQL 文本决定的

database/sql 的抽象层支持多结果集，但具体驱动是否能从服务端协议取出下一组，取决于驱动对 database/sql/driver.RowsNextResultSet 的实现和数据库本身的调用方式。不要只在 SQLite 单元测试里通过，就认为生产数据库的存储过程也一定能返回多组。

用最小测试确认顺序和错误归属

测试不必一开始就接真实数据库。可以先用项目已有的 SQL mock 或测试驱动构造三种响应：两组都有数据、第二组为空、第二组切换时报错。断言应覆盖读取顺序和最终错误，而不只是断言返回条数。

如果测试只验证“第一组的两行都读到了”，它对第二组列数、空集合和切换错误都没有保护力。真正有价值的断言，是把每一步的游标动作和结果集合编号都记录下来。

常见问题：Rows.NextResultSet 怎么用才不丢数据

调用 NextResultSet 后能直接 Scan 吗？

不能。调用成功后必须先调用当前结果集的 Next，只有它返回 true 才能 Scan。

NextResultSet 返回 false 就一定没有下一组吗？

不一定，也可能是推进时发生错误。要调用 Rows.Err() 区分“确实结束”和“切换失败”。

Rows.Close 还需要手动调用吗？

建议在拿到 Rows 后立即用 defer 注册。遍历到最后一组时通常会自动关闭，但提前返回、取消上下文或中途出错时，显式 Close 更稳妥。

固定列结构能不能复用一套变量？

可以，但前提是每一组的列数、顺序和可扫描类型都稳定。只要存储过程后续增加一列，就应让测试先暴露这个变化，而不是继续复用旧变量。

提交前的核对清单

• 每组数据都由 Next 驱动，切换由 NextResultSet 驱动。
• 每次 Scan 的目标与当前集合列结构匹配。
• 行循环结束后检查过 Rows.Err()，切换返回 false 后也检查过。
• 拿到 Rows 后立即注册 Close，并覆盖提前返回路径。
• 用目标驱动做一次真实多结果集验证，不能只依赖 mock。

多结果集读取本质上是一个双层游标协议。把“行结束”“集合切换”“最终错误”和“资源释放”分别写进代码和测试，后续换驱动或调整存储过程时，问题会在边界处暴露，而不是等到业务数据悄悄缺一组才发现。