Go sql.Tx提交成功前读取结果导致事务边界混乱的修复方法

使用 sql.Tx 时，事务还没有提交就读取结果并不一定是错误；真正容易出问题的是把事务内的中间结果，当成已经持久化、可以直接返回给调用方的最终结果。修复思路是把语义分开：事务内的查询只用于校验和决策，所有结果集在提交前释放并检查错误，只有 Commit 成功后才对外返回最终状态；如果必须读取提交后的值，就用 DB 在提交后重新查询。

先把事务边界拆成可观察的三段

一个容易混乱的函数通常同时做三件事：从 Tx 读取旧值，根据旧值写入变更，再把读取结果返回给上层。这里至少要区分三种数据：用于判断是否允许写入的校验数据、尚未提交的变更，以及提交成功后调用方可以信任的持久结果。

例如库存扣减前读取库存量，读到的数量只负责判断是否足够；扣减语句成功也只说明数据库连接接受了这次变更。事务真正完成的标志仍是 Commit 返回 nil。在它之前把数量、订单状态或更新时间当成“已成功”返回，就会让上层缓存、消息通知和数据库状态产生分歧。

读取结果与提交的代码如何固定顺序

简单查询可以用 QueryRowContext 直接 Scan 到局部变量。下面的写法把“检查结果”和“返回结果”分开：变量只在提交成功后才离开函数。

func changeName(ctx context.Context, db *sql.DB, id int64) (string, error) {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return "", err
    }
    // 默认按失败处理；只有 Commit 成功后才不会触发回滚。
    committed := false
    defer func() {
        if !committed {
            // 回滚失败也不能覆盖原始错误，因此这里不改写返回值。
            _ = tx.Rollback()
        }
    }()

    var oldName string
    // 事务内读取只用于判断或构造变更，不代表已持久化。
    if err = tx.QueryRowContext(ctx,
        `SELECT name FROM users WHERE id = ?`, id,
    ).Scan(&oldName); err != nil {
        return "", err
    }

    newName := oldName + "-updated"
    // 写入仍属于未提交变更，必须继续检查错误。
    if _, err = tx.ExecContext(ctx,
        `UPDATE users SET name = ? WHERE id = ?`, newName, id,
    ); err != nil {
        return "", err
    }

    // Commit 返回 nil 才能把 newName 当作本次事务的成功结果。
    if err = tx.Commit(); err != nil {
        return "", err
    }
    committed = true
    return newName, nil
}

这段代码有一个关键细节：defer 只负责兜底回滚，不能把回滚当成成功路径。若提交阶段因为上下文取消、连接异常或驱动错误返回错误，函数必须继续返回错误，不能因为前面的 UPDATE 没报错就返回 newName。

Rows 结果集要在 Commit 前收口

当查询返回多行时，不能只看循环里是否读出了一条记录。要在提交前显式关闭结果集，并检查 Rows.Err；否则网络读取、驱动解码或上下文取消造成的尾部错误可能被漏掉。

rows, err := tx.QueryContext(ctx,
    `SELECT id, name FROM users WHERE group_id = ?`, groupID,
)
if err != nil {
    return err
}
// 先释放结果集，再判断遍历期间是否出现驱动错误。
for rows.Next() {
    var id int64
    var name string
    // Scan 错误立即结束，避免把不完整数据用于后续写入。
    if err = rows.Scan(&id, &name); err != nil {
        _ = rows.Close()
        return err
    }
    // 在这里仅记录校验信息，不向调用方宣称事务已完成。
}
// Close 让连接可以回到连接池；Err 负责捕获遍历尾部错误。
if err = rows.Close(); err != nil {
    return err
}
if err = rows.Err(); err != nil {
    return err
}
// 只有结果集收口后才进入提交判断。
if err = tx.Commit(); err != nil {
    return err
}

如果驱动允许在结果集未关闭时继续发起语句，代码也不应依赖这种宽松行为。把 Close 和 Err 放在提交前，是为了让事务边界明确，同时让连接池尽早回收资源。

需要最终值时，提交后重新查询

有些场景需要数据库最终生成的值，例如触发器改写后的时间、数据库计算列或写入后的聚合结果。此时不要把事务内读到的中间值当成最终值，先完成提交，再通过 db.QueryRowContext 发起新的读取：

if err := tx.Commit(); err != nil {
    return "", err
}
// 提交成功后使用 DB 获取持久视角下的最终值。
var finalName string
if err := db.QueryRowContext(ctx,
    `SELECT name FROM users WHERE id = ?`, id,
).Scan(&finalName); err != nil {
    return "", err
}
return finalName, nil

这会产生一个明确边界：提交成功代表写事务完成，后续查询失败只代表“结果读取失败”，不能把它反推成写入失败。上层可以据此决定是否重试读取、返回已提交提示，或记录待补偿任务。

常见问题

事务里读取的数据一定不能返回吗？

不是。若它只是经过提交确认后的业务结果，可以在 Commit 成功后返回；重点是不要在提交前把它标成最终成功状态。

Commit 失败后需要再次调用 Rollback 吗？

可以保留统一的兜底回滚，但要接受部分驱动在提交失败时事务状态已不确定。最重要的是不返回成功结果，并记录原始提交错误。

QueryRowContext 还需要 Close 吗？

Scan 会完成单行读取并释放其内部结果集；多行查询则应显式 Close 并检查 Rows.Err，不能混用两套约定。

复查这类代码时，可以按“事务内查询只做判断、结果集先收口、Commit 错误不吞、提交后再暴露最终值”的顺序检查。只要调用方拿到的成功结果都经过提交确认，事务边界就不会被局部读取结果带偏。