3. 事务边界概念

事务边界是分布式事务中最基础也最容易被忽视的概念。它定义了“哪些操作属于同一个事务”以及“事务从何时开始、何时结束”。在 Go 语言中，事务边界通常由代码结构、函数调用或显式标记来划定。

3.1 事务边界的定义

事务边界（Transaction Boundary）是指一组数据库操作在逻辑上被组合成一个原子工作单元的范围。在这个范围内，所有操作要么全部成功提交，要么全部回滚。边界由三个要素构成：

3.2 为什么需要显式边界

在 Go 的 database/sql 标准库中，默认每个 db.Exec() 或 db.Query() 调用都会自动提交。这意味着：

• 无原子性：两条 SQL 语句之间如果发生故障，第一条已提交，第二条未执行，数据处于不一致状态。
• 无隔离性：其他并发事务可以看到中间状态，破坏事务的隔离要求。
• 无回滚能力：一旦某条语句失败，无法撤销之前已执行的操作。

显式边界通过 BeginTx 和 Commit/Rollback 解决了上述问题。以下对比表清晰展示了差异：

3.3 Go 中事务边界的常见模式

Go 生态中，事务边界主要有三种实现模式。每种模式适用于不同的场景和复杂度。

3.3.1 基础模式：手动 Begin/Commit/Rollback

最直接的方式，适合简单、短小的事务：

func Transfer(ctx context.Context, db *sql.DB, from, to string, amount float64) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback() // 确保异常时回滚

    _, err = tx.ExecContext(ctx, "UPDATE accounts SET balance = balance - ? WHERE id = ?", amount, from)
    if err != nil {
        return err
    }

    _, err = tx.ExecContext(ctx, "UPDATE accounts SET balance = balance + ? WHERE id = ?", amount, to)
    if err != nil {
        return err
    }

    return tx.Commit()
}

这种模式的关键在于 defer tx.Rollback()——如果 Commit 成功，Rollback 会被安全忽略；如果中途返回错误，Rollback 确保资源释放。

3.3.2 函数式模式：回调闭包封装

将事务边界封装到高阶函数中，减少重复代码：

func WithTransaction(ctx context.Context, db *sql.DB, fn func(tx *sql.Tx) error) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()

    if err := fn(tx); err != nil {
        return err
    }

    return tx.Commit()
}

// 使用示例
err := WithTransaction(ctx, db, func(tx *sql.Tx) error {
    if err := tx.ExecContext(ctx, "UPDATE ..."); err != nil {
        return err
    }
    if err := tx.ExecContext(ctx, "UPDATE ..."); err != nil {
        return err
    }
    return nil
})

这种模式将“边界管理”与“业务逻辑”分离，是 Go 中推荐的做法。

3.3.3 嵌套事务与传播行为

在微服务或复杂业务中，事务可能嵌套调用。Go 标准库不支持真正的嵌套事务，但可以通过传播行为模拟：

3.4 事务边界可视化

以下 SVG 图展示了三种事务边界模式在 Go 代码中的生命周期对比：

3.5 边界选择决策树

在实际项目中，选择哪种事务边界模式取决于以下因素：

1. 事务长度：短事务（< 5 条 SQL）适合手动模式；长事务或复杂逻辑适合函数式模式。
2. 复用需求：如果多个函数需要共享同一个事务，必须使用嵌套传播模式。
3. 测试友好：函数式模式更容易 mock 和单元测试。
4. 错误处理：手动模式需要确保每个返回路径都正确处理 Rollback。