事务清理

Go 的 database/sql 事务必须通过 Commit 或 Rollback 结束。函数中途返回错误并不会自动替你结束事务；遗漏清理时，事务可能继续占用连接，数据库侧也可能保留相关锁或其他事务资源。常用写法是在 BeginTx 成功后立即 defer tx.Rollback()，并只在业务完成后显式检查 Commit 的结果。

以库存预留为例，SQL 没有报错但影响行数不符合要求，也是一条会提前返回的路径。只给 SQL 错误分支补 Rollback，很容易漏掉这种业务判断。

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

业务提前返回为什么也要结束事务

事务使用同一条连接执行其中的操作。请求函数返回、事务结束、连接重新可供池使用，是需要明确衔接的事情。若事务没有结束，其他请求就可能因可用连接不足而等待；至于是否持有锁、持有什么锁，则取决于数据库、语句和隔离级别，不能对所有事务一概而论。

这个问题不一定首先表现为数据错误。低流量时尚有空闲连接，问题可能不明显；业务高峰时，相同的遗漏分支被重复触发，连接等待就可能更突出。单凭等待增加也不能直接确认是事务泄漏，还要结合事务寿命与具体返回路径。

最小写法是开始成功后立即安排回滚

以下是原创的库存操作示例。假设 stock_items 的 sku 唯一，available 为可更新库存；SQL 采用 MySQL 驱动常用的问号占位符。连接配置、表结构和驱动由项目提供，本文没有运行数据库或测试。

package stock

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

// Reserve 演示 MySQL 风格的问号占位符；db 由调用方配置驱动和连接。
func Reserve(ctx context.Context, db *sql.DB, sku string) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("开始库存事务: %w", err)
    }
    defer tx.Rollback() // 覆盖后续所有提前返回；提交后该调用不再回滚已提交数据。

    result, err := tx.ExecContext(ctx,
        "UPDATE stock_items SET available = available - 1 WHERE sku = ? AND available > 0",
        sku)
    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("库存预留未命中唯一商品")
    }
    // 只有提交成功，才能向上层报告预留成功。
    if err := tx.Commit(); err != nil {
        return fmt.Errorf("提交库存事务: %w", err)
    }
    return nil
}

在 SQL 错误、影响行数读取错误和业务不满足三个分支中，函数都会返回，延迟回滚统一收尾。成功路径先提交；随后延迟调用 Rollback 不会撤销已经提交的数据，而是得到事务已结束的结果。

这里忽略延迟 Rollback 的返回值，是最小写法的明确取舍，并不表示回滚错误永远没有诊断价值。它的主要目的，是确保每个函数退出路径都安排了事务结束，而不是要求每个分支重复清理代码。

把业务操作固定在同一个 Tx 上

开始事务后，属于该事务的操作应通过 tx.ExecContext、tx.QueryContext 等方法完成。不要在同一个业务步骤中误用 db.ExecContext：后者不因局部变量 tx 的存在就自动加入事务，还可能需要另一条池连接。

也不要把创建好的事务存进全局变量，等待不确定时刻由其他请求结束。事务的创建者、使用范围和结束责任越分散，越难覆盖提前返回。对只完成一个业务动作的函数，让事务寿命与函数调用范围对应，通常更容易维护。

官方事务教程：https://go.dev/doc/database/execute-transactions。其中的延迟回滚模式适用于这类有多个失败出口的操作，但具体业务 SQL、占位符和重试策略仍应按项目设计。

需要保留回滚异常时怎么改

需要把回滚异常交给调用者时，可将函数返回值改为命名的 err，再用下面的片段替换原来的延迟回滚。

// 变体：函数使用命名返回值 (err error)，并额外导入 errors。
// 用此延迟函数替换前例的 defer tx.Rollback()，不要同时保留两份。
defer func() {
    rbErr := tx.Rollback()
    if rbErr != nil && !errors.Is(rbErr, sql.ErrTxDone) {
        // 不覆盖原来的业务错误；errors.Join 需要 Go 1.20 或以上。
        err = errors.Join(err, fmt.Errorf("回滚库存事务: %w", rbErr))
    }
}()

过滤 ErrTxDone 是因为成功提交后，或者事务已因其他原因结束后，再回滚会得到已结束错误。它不能用来判断数据库里“业务一定成功”，只是事务对象已不可继续使用。原始业务错误和提交错误仍需保留。

不要在 Commit 返回错误后直接报告成功，也不要指望再次 Rollback 就能把不确定的提交结果变成成功结论。涉及重试时，还应结合业务幂等标识及数据库侧状态判断，不能机械重跑全部写入。

从连接池等待判断是否还有遗漏

可以在同一个 DB 对象上观察连接池状态，结合请求量判断清理改造是否覆盖了异常路径。下面只提供采样片段，不展示虚构的监控结果。

// 在已有 db 对象上读取池状态；不要为了排障新建另一个连接池。
stats := db.Stats()
fmt.Printf("in_use=%d idle=%d waits=%d wait_time=%s\n",
    stats.InUse, stats.Idle, stats.WaitCount, stats.WaitDuration)

InUse 与 Idle 反映采样时刻的池状态，WaitCount 与 WaitDuration 是累计等待指标。比较同一观察窗口内的变化，比拿累计值直接当作当前等待更有意义。连接池繁忙可能来自长查询、未关闭 Rows、长事务等原因，不能只归因于 Rollback。

读者可分别覆盖 SQL 失败、业务拒绝、提交成功和上下文取消这些路径。BeginTx 的上下文取消会触发 sql 包回滚，但这不是省略显式清理的理由：如果传入的是没有取消期限的上下文，或者取消尚未发生，事务仍需要正确结束。defer 也只有在所属函数退出时执行；长循环应把每次事务封装到短函数中。

常见问题

提交后延迟回滚会把数据撤销吗？

不会撤销已提交数据。事务对象已经结束，再 Rollback 会返回 ErrTxDone。

返回业务错误，sql 包会自动回滚吗？

普通函数返回值不会被 sql 包感知。需要安排 Rollback；BeginTx 上下文取消带来的回滚是另一种机制。

把连接池上限调大能解决吗？

可能暂时缓解等待，但不会修复没有结束的事务。应先补清理路径，再按业务负载确定池大小。