Go rowslife 如何限定迭代周期

在 Go 的数据库代码里，rowslife 可以理解为一条约定：从拿到 *sql.Rows 到释放它，整个迭代周期都由同一个查询函数负责。它不是 database/sql 的内置类型。真正需要限定的是 Rows 的资源所有权，而不是给循环额外加一个计时器。

官方文档：https://pkg.go.dev/database/sql

把 Rows 的所有权收回查询函数

最稳妥的边界是“谁调用 Query，谁负责 Close”。Go 官方文档也建议在查询成功后马上执行 defer rows.Close()。完整消费结果集时，Rows 通常会在迭代结束时隐式关闭，但显式关闭能覆盖 Scan 失败、业务过滤后提前返回等路径。

func listActiveUsers(ctx context.Context, db *sql.DB) ([]User, error) {
    // 让取消信号进入数据库查询，避免请求已经结束后仍等待结果。
    rows, err := db.QueryContext(ctx,
        "SELECT id, name FROM users WHERE active = ? ORDER BY id", true)
    if err != nil {
        return nil, err
    }
    // 查询函数拥有 Rows；无论后面哪条 return 执行，都负责释放它。
    defer rows.Close()

    users := make([]User, 0, 16)
    for rows.Next() {
        var user User
        // Next 成功后才能 Scan；Scan 错误必须立即返回。
        if err := rows.Scan(&user.ID, &user.Name); err != nil {
            return nil, err
        }
        users = append(users, user)
    }
    // Next 返回 false 既可能是自然结束，也可能是驱动读取失败。
    if err := rows.Err(); err != nil {
        return nil, err
    }
    return users, nil
}

这个函数把资源边界压缩在一处：调用方只拿到 []User 和错误，不需要知道 Rows 何时关闭。若业务确实只要前几条，也应在当前函数内结束读取并让 defer 生效，不要把 *sql.Rows 当作跨层迭代器返回。

用 Err 和 Context 判断迭代是否真的结束

Rows.Next 返回 false 时，原因可能是已经没有下一行，也可能是读取过程中出现错误。只有在循环后调用 rows.Err()，才能把两种情况分开。Scan 的字段类型不匹配、NULL 处理不当等错误，则发生在循环内部，不能等到 Err 再猜。

当查询属于 HTTP 请求、任务超时或客户端主动取消的链路，应使用 QueryContext。Context 负责把取消意图传给数据库操作；它不能替代 Rows.Close，也不意味着业务代码可以省略错误检查。

需要注意的是，defer 的作用域是函数，不是 for 循环。如果一段代码在大循环里反复调用一个小查询函数，那么 Close 会在小函数返回时执行；如果把大量资源申请都写进同一个长函数，defer 可能要等长函数结束才释放，这时应拆出有清晰边界的 helper。

限定迭代周期时的几个取舍

如果只查一个唯一结果，应优先考虑 QueryRowContext，它表达的就是单行意图，不必手动维护 Rows 循环。多行查询则保留上面的四段式结构：QueryContext、defer Close、Next/Scan、Err。

不要用字符串拼接生成条件值；把参数交给查询方法的占位参数。还要留意 sql.RawBytes 的生命周期：它指向的内容可能在下一次 Next、Scan 或 Close 后失效，需要在合适时机复制。多结果集场景则在处理完一组后调用 NextResultSet，最后仍检查 Err。

func hasUser(ctx context.Context, db *sql.DB, id int64) (bool, error) {
    var found bool
    // 单行查询用 QueryRowContext，结果为空时通过 sql.ErrNoRows 表达。
    err := db.QueryRowContext(ctx,
        "SELECT EXISTS (SELECT 1 FROM users WHERE id = ?)", id).Scan(&found)
    if errors.Is(err, sql.ErrNoRows) {
        return false, nil
    }
    return found, err
}

常见问题

Rows 读完后还需要显式 Close 吗？

完整迭代通常会隐式关闭，但建议保留 defer rows.Close()，这样提前返回和未来修改循环时仍有安全兜底。

为什么不把 Rows 返回给 service 层？

跨层返回会把连接、关闭责任和错误判断分散到多个调用者。除非接口明确约定所有权，否则在查询函数内整理成切片或领域结果更容易维护。

Next 返回 false 就能认为查询成功吗？

不能。循环结束后必须检查 rows.Err()；它为空才说明迭代没有报告读取错误。