Go Gin同一处理函数内多次执行Postgres查询的疑问与最佳实践

针对你三个问题的逐一解答 #

1. 重复赋值rows后defer rows.Close()的执行逻辑 #

你当前的写法有明确隐患，不是正确的资源处理方式：

• 首先Go的defer在注册时就会完成所有参数（包括方法接收者）的求值绑定，所以两次defer rows.Close()确实会分别绑定两次查询返回的不同*sql.Rows实例，函数退出时会按照后进先出顺序依次关闭两个实例，不存在编译器追踪不到实例的问题。
• 第一个严重问题：你把defer rows.Close()写在了错误判断之前。如果pgClient.Query()执行失败，返回的rows是nil，此时注册的defer会在函数退出时触发空指针panic，直接导致接口返回500。正确顺序是先判断Query的错误，确认err为nil之后再注册defer Close。
• 第二个性能问题：第一次查询的rows在遍历完成后就不再使用，但defer会把它的关闭时机拖到整个handler执行结束，这段时间它会一直占用数据库连接池的连接，高并发场景下很容易把连接池打满。

2. 循环中复用id变量是否合规 #

完全符合规范，不需要在每个循环内重新声明id。
rows.Scan(&id)的逻辑是把当前行的列值拷贝到id指向的内存地址，你最终append到切片的是int类型的值拷贝，不管复用变量还是新建变量，都不会出现数据错乱。反而复用同一个变量能减少不必要的内存分配，效率更高。
唯一例外场景：如果你后续要存储id的指针（比如把&id存到指针切片），那复用变量会导致所有指针都指向同一个内存地址，最终拿到的都是最后一次赋值的结果，但你当前的值传递场景完全没有问题。

3. 多查询场景的优雅实现方案 #

如果有大量同模式的查询，完全可以封装通用方法消除重复代码，这也是生产环境的常见实践。
你当前的代码还漏了一个关键逻辑：rows.Next()遍历结束后，必须调用rows.Err()检查遍历过程中是否出现了网络错误、数据解析错误——这类错误会直接让rows.Next()返回false，如果不检查Err，你会误以为遍历正常结束，拿到不完整的脏数据。
给你一个可直接用的单字段int查询封装：

// queryInts 执行查询，收集结果集第一列的int值返回
func queryInts(ctx context.Context, query string, args ...any) ([]int, error) {
    rows, err := pgClient.QueryContext(ctx, query, args...)
    if err != nil {
        return nil, err
    }
    // 确认无错误后再注册关闭逻辑，避免空指针
    defer rows.Close()

    var res []int
    var val int
    for rows.Next() {
        if err := rows.Scan(&val); err != nil {
            return nil, err
        }
        res = append(res, val)
    }
    // 检查遍历过程中的错误
    if err := rows.Err(); err != nil {
        return nil, err
    }
    return res, nil
}

封装后原来的handler逻辑可以简化成：

// 传递请求上下文，客户端断开时可及时取消数据库操作
userIds, err := queryInts(c.Request.Context(), getUserIdsQuery)
if err != nil {
    // 统一错误处理逻辑
    return
}
bookIds, err := queryInts(c.Request.Context(), getBookIdsQuery)
if err != nil {
    // 统一错误处理逻辑
    return
}

额外最佳实践建议 #

• 所有数据库操作都优先使用带Context的版本（QueryContext/ExecContext），把Gin请求的上下文传入，请求取消时能及时中断数据库操作，避免资源浪费。
• 尽量避免在循环中执行单条SQL，能通过IN语句、批量查询合并的逻辑尽量合并，减少和数据库的网络交互次数。
• Go 1.18+支持泛型后，可以封装支持任意字段类型、任意结构体的通用查询方法，不用为每个查询重复写遍历扫描逻辑。
• rows.Close()是幂等操作，重复调用不会报错，哪怕你提前手动关闭了rows，defer再执行一次Close也不会有问题。

内容的提问来源于stack exchange，提问作者Most Wanted