Go database/sql Tx.Commit 为什么可能返回连接错误

Tx.Commit 返回连接错误，并不一定表示“数据库肯定没有提交”。它把提交动作交给底层驱动；如果提交阶段连接断开，客户端可能只知道通信失败，却不知道服务端是否已经完成提交。另一方面，如果事务上下文已取消，Commit 甚至可能在调用驱动前就返回上下文错误。

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

Tx.Commit 到底在什么位置返回连接错误

database/sql 的 Tx 绑定一条底层连接，Commit 会调用驱动提供的 driver.Tx.Commit。驱动返回什么错误，database/sql 通常就把这个错误返回给调用方；随后事务结束，并把连接按错误状态归还或丢弃。

因此，连接错误常见于提交请求已经发出、连接却在响应返回前失效的窗口。driver.ErrBadConn 还承担“连接已经不可复用”的信号，连接池会据此处理资源，但它不是“这次业务写入绝对没有发生”的证明。

先排除提交前就已经失败的情况

调用 Commit 时，第一件事不是立刻重试，而是确认错误发生在哪个阶段。事务关联的上下文如果已经结束，database/sql 会先返回上下文错误；事务已经提交或回滚过，则返回 sql.ErrTxDone。这两类结果都不是“重新执行 Commit 就能修好”的连接问题。

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

func finishOrder(ctx context.Context, db *sql.DB, orderID int64) error {
    // 事务总生命周期受 ctx 约束，超时后不要继续把它当作可提交对象。
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("begin transaction: %w", err)
    }
    // 兜底回滚在已提交时会返回 ErrTxDone，可安全忽略。
    defer tx.Rollback()

    if _, err := tx.ExecContext(ctx,
        "UPDATE orders SET status = ? WHERE id = ?", "paid", orderID,
    ); err != nil {
        return fmt.Errorf("update order: %w", err)
    }
    if err := tx.Commit(); err != nil {
        // 这里保留原始错误链，供 errors.Is 和日志分类使用。
        return fmt.Errorf("commit order: %w", err)
    }
    return nil
}

这个写法的重点是让 Commit 只调用一次，并用 %w 保留错误链。生产日志还应带上业务请求号、订单号和事务开始时间，不能只记录一段模糊的“commit connection error”。

把连接错误和提交结果未知分开处理

如果驱动返回的是明确的约束错误、死锁错误或权限错误，通常可以根据数据库返回的错误码做业务分类；但如果是网络断开、连接被服务端关闭或驱动返回 driver.ErrBadConn，客户端可能失去确认提交结果的能力。

这时要把状态分成三类：提交前失败可以安全回滚；已拿到明确的提交失败可以按驱动语义处理；提交请求发出后连接中断则标成“未知”，通过业务幂等键或数据库侧查询恢复，而不是直接再执行一遍写操作。

为什么不能看到连接错误就重试

driver.ErrBadConn 在很多普通查询场景中可以帮助 database/sql 换一条连接重试，但事务提交是有副作用的边界。官方驱动文档明确提醒：如果数据库服务器可能已经执行操作，就不应返回 ErrBadConn 来触发重复操作。对调用方来说，同样不能把未知提交结果当成“肯定没写入”。

更稳妥的落地方式是：

• 写入带业务唯一键，例如订单号、支付流水号或请求幂等键。
• 提交返回未知错误后，先按幂等键查询业务状态。
• 只有确认事务未生效，且业务允许重试时，才重新创建事务；绝不复用已经结束的 Tx。

一份简短的排障清单

结论可以压缩成一句话：Tx.Commit 报连接错误时，先判断它发生在提交前还是提交确认阶段；只要存在“请求已发出但结果未确认”的可能，就把它当作未知状态处理。连接池会负责坏连接的生命周期，业务代码则负责幂等、查询和恢复。

常见问题

Commit 返回连接错误后还能调用 Rollback 吗？

事务已经进入结束流程，继续调用通常只会得到 sql.ErrTxDone。可以保留 defer tx.Rollback() 作为兜底，但不要把它当成确认数据库未提交的手段。

把 Commit 放进重试循环可以吗？

不建议。每次重试都应创建新事务，并先用业务幂等键确认上一次提交是否已经生效；直接重复调用同一个 Tx 没有意义，直接重放写入还可能造成重复副作用。