Go database/sql Tx 怎样保证回滚路径

Go database/sql 的事务回滚路径，最稳妥的组织方式是：BeginTx 成功后立即注册 defer 回滚兜底，只有业务成功才 Commit，并把提交错误返回给调用方。不要依赖某个容易被遮蔽的 err 变量决定是否回滚。提交成功后可以用显式标记跳过兜底；如果事务已结束，清理阶段遇到 sql.ErrTxDone 不应覆盖原始错误。

这里的“保证”是让函数具有完整的收尾尝试路径，并非保证网络异常时数据库一定完成回滚，也不是保证进程崩溃后 defer 仍会执行。官方入口：https://pkg.go.dev/database/sql#Tx；事务指南：https://go.dev/doc/database/execute-transactions。

准备事务所有权与错误约定

先把事务收尾权交给一层函数：外层负责 BeginTx、Commit 和 Rollback，内层业务函数只使用传入的 tx。这样，一个业务分支提前返回时，不必再记得补一遍回滚。内层也不能自行提交，否则外层会把一个已经结束的事务当成可继续提交的事务。

实验前提是已有可用的 sql.DB 和数据库驱动，涉及的数据操作需要数据库支持事务。下面示例不指定 SQL 方言，不创建表，也不提供连接串。它把收尾策略封装成可集成的函数；接入真实业务时，仍需按数据库能力选择事务选项。

BeginTx 成功后立即注册回滚

如果 BeginTx 返回错误，就没有可以使用的事务对象，应直接返回。只有成功拿到 tx 后才注册 defer，并紧接着进入业务代码。这样，后面的普通错误返回和正常 panic 栈展开都会经过已经注册的收尾函数。

不要写成“只有外层 err 不为 nil 才 Rollback”的隐式约定。业务代码中的短变量声明可能遮蔽外层 err；更重要的是，回滚兜底表达的是“没有成功提交就收尾”，不是“某个变量当前恰好非空”。显式 committed 标记只在 Commit 返回 nil 后设置，语义更直接。

另一种简洁写法是不加成功标记，始终 defer tx.Rollback，并接受提交后出现的 ErrTxDone。它同样可用。本文选标记方式，只是为了把“成功时不再调用 Rollback”的约定写明，不是说重复调用一定会产生第二次数据库回滚。

实现保留错误优先级的事务函数

以下独立包使用 errors.Join，需要 Go 1.20 或更高版本。代码是本次原创的集成示例，未在本轮执行；函数不包含业务 SQL，便于将已有业务回调传入。

package txscope

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

// WithTx 独占事务收尾权；fn 只执行事务内操作，不自行提交或回滚。
func WithTx(ctx context.Context, db *sql.DB, fn func(*sql.Tx) error) (err error) {
    if ctx == nil || db == nil || fn == nil {
        return fmt.Errorf("事务参数不能为空")
    }
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("开启事务: %w", err)
    }

    committed := false
    defer func() {
        if committed {
            return // 提交成功，不再发起回滚调用。
        }
        rbErr := tx.Rollback()
        if rbErr == nil || errors.Is(rbErr, sql.ErrTxDone) {
            return // 已结束事务的重复清理不覆盖原错误。
        }
        cleanupErr := fmt.Errorf("回滚收尾: %w", rbErr)
        if err == nil {
            err = cleanupErr
        } else {
            // 主错误保留在前，清理失败作为额外诊断信息。
            err = errors.Join(err, cleanupErr)
        }
    }()

    if workErr := fn(tx); workErr != nil {
        return fmt.Errorf("事务业务: %w", workErr)
    }
    if commitErr := tx.Commit(); commitErr != nil {
        return fmt.Errorf("提交事务: %w", commitErr)
    }
    committed = true
    return nil
}

命名返回值 err 的作用仅限于让 defer 追加清理诊断，不承担判断回滚与否的职责。业务失败时优先返回带“事务业务”上下文的原错误；业务成功但提交失败时返回提交错误；回滚出现非 ErrTxDone 的错误时，通过 Join 保留两份信息，而不是简单地用回滚错误替换主错误。errors.Is 和 errors.As 仍可沿错误树判断具体原因。

如果 fn 发生 panic，defer 会尝试 Rollback，原 panic 继续传播，这里没有 recover，也不把 panic 改写成成功返回。此时给 err 追加的信息不会作为正常返回值交给调用方；如果需要记录 panic 时的清理错误，应另外约定可靠的日志接口。不要声称这个版本同时解决了 panic 日志采集。

为成功、失败和取消安排检查点

接入业务时，先选可丢弃的测试数据，再由读者在隔离环境运行。下表是预期检查计划，不是已执行结果。函数单元测试可通过可控驱动观察方法调用，数据一致性则应在真实数据库的独立测试中确认。

BeginTx 使用的 context 覆盖事务生命周期，取消会触发 sql 包回滚，提交也可能因此失败。取消与收尾之间有并发关系，不应把某一个固定错误文本当成唯一判据，更不能把 ErrTxDone 当作数据库已经成功提交的凭据。

尤其要区分“提交接口报错”和“可以安全重放”。提交期间发生通信异常时，不能单凭错误就断言所有写入都不存在；这个 tx 也不再适合继续使用。应由业务的幂等标识和状态查询策略处理结果不确定性，不能在 defer 中盲目重试整段业务。

扩展与收尾时避开的陷阱

事务内的相关读写应走 tx.ExecContext、tx.QueryContext 或 tx.QueryRowContext，而不是混入 db 的同名方法。否则某条写入可能不属于这个事务，即使 tx 回滚，也不能撤销事务外的写入。回调也不应启动脱离函数生命周期的 goroutine 去继续使用 tx。

defer 并非进程级可靠性机制：os.Exit、进程被强制终止或机器故障不会按普通函数返回规则执行清理。回调永久阻塞时，函数也到不了收尾点。应让数据库操作携带合理的 context，并在返回前处理 rows、stmt 等资源的各自生命周期。

回滚错误要不要忽略？

已结束事务的 ErrTxDone 可以作为重复清理状态忽略；其他回滚错误应保留诊断信息。不要因为有业务错误就无条件抹掉清理失败，也不要反过来让清理失败遮住最初的业务原因。

Commit 出错后再 Rollback 能修复吗？

不能这样承诺。兜底调用是收尾防线，不是提交失败的补偿协议；它可能只返回 ErrTxDone。应保留 Commit 错误并停止使用这个事务。

能在业务回调里提交吗？

本文函数的契约禁止这样做。若希望调用方掌控提交，应更换接口设计，不要同时让两层都以为自己拥有事务收尾权。事务生命周期明确、主错误保留、清理结果不冒充业务结论，回滚路径才真正可维护。