预编译语句

在 Go 的 database/sql 里，PrepareContext 成功返回的 *sql.Stmt，关闭责任应该在“成功拿到它”的同一层建立起来。最稳妥的习惯是：准备成功后马上 defer stmt.Close()，执行查询时再把请求级 Context 传给 QueryContext 或 ExecContext。

一句话判断：DB.PrepareContext 创建的语句由调用方在不再使用时关闭；Tx.PrepareContext 创建的语句属于事务，提交或回滚会关闭它，但显式保留关闭责任仍能让提前返回的代码更清楚。

准备成功后，立即把关闭责任写下来

我在维护数据库访问函数时，最容易漏掉的不是 SQL 本身，而是“准备成功但后面提前返回”的路径。PrepareContext 返回错误时没有可关闭的语句；一旦返回了非 nil 的 *sql.Stmt，就应该把清理动作放在同一作用域里，而不是等到所有业务分支都写完再补。

func loadUser(ctx context.Context, db *sql.DB, id int64) (string, error) {
    // PrepareContext 的 Context 只控制准备阶段。
    stmt, err := db.PrepareContext(ctx, "SELECT name FROM users WHERE id = ?")
    if err != nil {
        return "", fmt.Errorf("prepare user query: %w", err)
    }
    // 准备成功后立刻建立关闭责任，覆盖后续所有提前返回。
    defer stmt.Close()

    var name string
    // 查询阶段继续传入请求 Context，控制本次执行的取消。
    if err := stmt.QueryRowContext(ctx, id).Scan(&name); err != nil {
        return "", fmt.Errorf("query user: %w", err)
    }
    return name, nil
}

这里的两个 Context 位置不要混为一谈：前一个给准备动作，后一个给具体查询。关闭 Stmt 也不是取消正在执行的请求，它表达的是“这个预编译语句以后不再由当前所有者使用”。

DB 级和事务级 Statement 不是同一条生命周期

db.PrepareContext 返回的语句可以在后续查询中复用，*sql.Stmt 本身允许多个 goroutine 并发使用。它依附于 *sql.DB 的生命周期，适合放在一个服务对象里长期持有，也可以放在单次函数里用完即关。

事务级写法则不同。tx.PrepareContext 返回的语句在当前事务中运行；Go 官方文档说明，事务提交或回滚会关闭通过事务准备出来的语句。为了让“提前返回”也有明确的资源归属，我仍然会在获取成功后写出 defer stmt.Close()，同时用 defer tx.Rollback() 兜底，最后只让成功的 Commit 决定事务结果。

func markPaid(ctx context.Context, db *sql.DB, id int64) (err error) {
    // 事务必须在成功提交或回滚后结束，defer 覆盖中途错误。
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("begin transaction: %w", err)
    }
    defer tx.Rollback() // 已提交时 Rollback 会返回事务已完成，可安全忽略。

    stmt, err := tx.PrepareContext(ctx, "UPDATE orders SET status = ? WHERE id = ?")
    if err != nil {
        return fmt.Errorf("prepare update: %w", err)
    }
    // 事务结束会关闭它，这一行仍把当前函数的所有权写清楚。
    defer stmt.Close()

    if _, err := stmt.ExecContext(ctx, "paid", id); err != nil {
        return fmt.Errorf("update order: %w", err)
    }
    if err := tx.Commit(); err != nil {
        return fmt.Errorf("commit order: %w", err)
    }
    return nil
}

取消、执行和关闭要分别判断

实际排查时，我会把三个问题分开问。第一，准备阶段是不是因为上游 Context 已取消而失败；第二，执行阶段是不是应该用 Stmt.ExecContext 或 Stmt.QueryContext 响应本次请求；第三，语句在函数返回、事务结束或服务关闭时由谁释放。

不要用 db.PrepareContext 的 Context 代替执行 Context。官方 API 对它的说明很明确：这个 Context 用于 preparation，不会自动成为后续执行的取消信号。长时间复用的 DB 级语句可以在初始化阶段准备，在服务退出时关闭；短生命周期的语句则放进一个小函数，让 defer 自然收口。

循环中不要让 defer 绑定错作用域

如果同一条 SQL 反复执行，通常应该在循环外准备一次，在循环内调用 ExecContext，函数返回时再关闭。若每轮确实要准备不同语句，就把一轮封装成小函数，让每轮的 defer 在本轮结束，而不是把大量待关闭的语句积累到外层函数返回。

func updateMany(ctx context.Context, db *sql.DB, ids []int64) error {
    // 同一条 SQL 只准备一次，循环只复用 Statement。
    stmt, err := db.PrepareContext(ctx, "UPDATE users SET enabled = ? WHERE id = ?")
    if err != nil {
        return fmt.Errorf("prepare batch update: %w", err)
    }
    defer stmt.Close()

    for _, id := range ids {
        // 每次执行仍使用请求 Context，取消可以及时传到驱动。
        if _, err := stmt.ExecContext(ctx, true, id); err != nil {
            return fmt.Errorf("update user %d: %w", id, err)
        }
    }
    return nil
}

最后可以留下这份小清单：准备失败时直接返回；准备成功后立刻安排 Close；事务语句同时安排回滚兜底；执行取消使用执行方法的 Context；循环优先复用同一个语句；长生命周期的 Statement 在对应服务对象结束时统一关闭。

相关问题

PrepareContext 成功但没有执行，必须关闭吗？ 应该。只要不再需要，就按持有它的作用域调用 Close，不要把“没有执行过”当成不清理的理由。

Stmt.Close 会关闭数据库连接吗？ 不会。它关闭的是预编译语句；数据库连接池由 *sql.DB 管理，二者是不同层级的生命周期。

事务提交后还要再 Close 吗？ 事务语句会随提交或回滚结束；如果代码已经用 defer stmt.Close() 表达所有权，保留它能让不同返回路径一致，具体关闭结果无需覆盖已经返回的业务错误。