Go SQL 事务中间错误的回滚结构

Go SQL 事务处理中间错误时，可以采用“显式提交、延迟回滚兜底”的结构：BeginTx 成功后立即注册 defer Rollback，后续任何语句或业务检查失败都直接返回，所有操作成功后才调用 Commit，并检查提交错误。defer 不是自动提交器，也不能把 Commit 失败变成已确认成功。

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

把库存扣减与预留记录放进同一个事务

考虑一个简化的库存预留任务：先减少商品可用数量，再写入预留记录。如果第二步失败，却已经对外返回成功，就会留下难以解释的业务状态。这里需要的不是在每个 return 前手写一遍回滚，而是把事务结束责任集中在一个函数内。

这个模式只解决同一数据库事务内的原子修改。发短信、调用外部HTTP接口或写另一套存储，不会因为放在这个函数中就自动跟随数据库回滚。下面不扩展分布式事务，也不假设数据库驱动、隔离级别和表引擎全都相同。

用一个函数承担提交和清理责任

示例假设 stock.sku_id 唯一、available非空且可参与整数计算，reservations.request_key有唯一约束，两张表支持同一事务。SQL采用问号参数占位符；实际数据库或驱动使用其他形式时应替换占位符，不能把这个片段当成跨库通用DDL或完整库存系统。调用方负责驱动注册、连接初始化与表结构迁移。

package reservation

import (
    "context"
    "database/sql"
    "errors"
    "fmt"
    "log"
)

// 调用方提供已初始化的db；表必须支持事务，占位符需符合实际驱动。
func Reserve(ctx context.Context, db *sql.DB, key string, sku, qty int64) error {
    if key == "" || sku = ?",
        qty, sku, qty)
    if err != nil {
        return fmt.Errorf("扣减可用库存: %w", err)
    }
    n, err := result.RowsAffected()
    if err != nil {
        return fmt.Errorf("读取受影响行数: %w", err)
    }
    if n != 1 {
        return fmt.Errorf("商品不存在或可用库存不足")
    }

    // 第二条语句仍使用同一个tx，失败时不再继续提交。
    _, err = tx.ExecContext(ctx,
        "INSERT INTO reservations (request_key, sku_id, quantity) VALUES (?, ?, ?)",
        key, sku, qty)
    if err != nil {
        return fmt.Errorf("写入预留记录: %w", err)
    }
    if err := tx.Commit(); err != nil {
        return fmt.Errorf("提交预留事务: %w", err)
    }
    // 只有Commit明确成功，才向调用方返回成功。
    return nil
}

扣库存语句同时表达数量条件，并检查受影响行数。没有命中时不是SQL语法错误，却仍然是不能提交的业务结果，所以一样直接返回。第二条插入失败时，函数不会走到Commit；延迟清理会对未结束的事务调用Rollback。

调用方看到 nil 才能把本次操作视为已确认成功。即便两条 ExecContext 都返回 nil，也不能提前发布成功事件或给用户确认信息，因为提交本身是一个独立的失败点。本例为说明性原创代码，没有连接数据库运行，也没有虚构扣减成功记录。

为什么成功提交后还可以保留defer回滚

defer捕获的是事务对象的清理责任，不依赖某个外层err变量的最终值。事务已经结束时，再调用Rollback会遇到sql.ErrTxDone；清理逻辑把它作为已结束状态处理，不把它记成新的业务失败。这样就不需要为了成功分支额外维护一个容易漏改的布尔开关。

真实的回滚错误则作为清理异常单独记录，不替换正在返回的原始错误。否则，“插入预留记录失败”可能在离开函数时被“回滚失败”覆盖，最重要的故障线索反而丢失。本例日志仅演示记录位置，生产环境应使用应用的日志策略，控制驱动错误中的敏感信息。

不要写成“err不为空才回滚”，却让内部短变量声明把真正的错误藏在另一个作用域里。这里始终执行兜底清理，因此无论错误分支怎样返回，都不靠err变量的巧合来决定是否结束事务。也不要在事务函数中使用log.Fatal或os.Exit作为普通错误处理，它们会直接退出进程，不能依赖常规defer收尾。

Commit报错时能不能再回滚然后重试

Commit返回错误，必须把此次事务的查询和执行结果视为不能向业务确认的结果；不能因为之前更新过一行就返回成功。事务对象也不应继续承载新查询。后面的defer只是清理兜底，不是“第二次确认提交”的机制。

特别是网络通信异常时，不应仅凭客户端收到的错误就断言远端一定没有生效。应结合数据库和驱动的错误语义，以及业务请求键、持久状态和恢复机制判断后续动作。不能在同一个tx上循环Commit，也不能不分错误类型地重新扣一次库存。

request_key唯一约束有助于防止同一个请求生成多份预留，但唯一约束本身不等于完整幂等接口：重复请求如何返回既有结果、提交结果待确认时如何核对状态，仍需业务层设计。本例没有内置自动重试，避免把结果确认问题掩盖成“重试一下”。

事务结构正确仍需守住哪些边界

BeginTx接收的context作用于事务生命周期，取消会触发database/sql的回滚处理，提交也可能因此失败。代码中的ExecContext仍应继承适当的上下文；不要一边用请求context开事务，一边用Background试图在请求取消后强行继续提交。驱动对取消的支持也会影响操作返回的及时性。

此外，事务内需要一起提交的语句必须调用tx的方法，不能混用db.ExecContext并误认为它自动加入当前事务。默认选项nil使用驱动或数据库默认行为；需要非默认隔离级别时还要确认驱动支持。把事务范围保持为必要数据库工作，减少在持有事务时等待无关外部操作。

常见补充问题

defer tx.Rollback能撤销成功提交吗？

不能。提交成功后事务已经结束，后续回滚不会把已确认提交的修改反向撤销。

第二条语句报错，第一条会立刻自动回滚吗？

不要依赖跨数据库通用的“每条错误立即自动回滚”假设。应用应停止正常提交路径，明确结束事务；本结构通过函数退出时的兜底承担这项责任。

能否只在最后写return tx.Commit？

可以返回提交错误，但在上层需要定位阶段时，带有“提交预留事务”描述并保留错误链更清楚；关键仍是前面已经注册回滚兜底，且中间失败不会走到提交。

事务结构的判断标准不是有没有写BeginTx，而是所有退出路径是否有结束责任、所有业务成功是否建立在Commit成功之上，以及失败信息是否保留了真正出错的阶段。

Go官方事务指南：https://go.dev/doc/database/execute-transactions。