1. 事务概念回顾：ACID特性、本地事务与分布式事务、事务边界定义

事务（Transaction）是数据库与分布式系统中的核心抽象，它将一组读写操作捆绑为一个不可分割的逻辑单元。理解事务的本质，是正确设计 API 事务边界的前提。本节从 ACID 特性出发，逐步展开本地事务与分布式事务的差异，并给出事务边界的精确定义。

1.1 ACID 特性

ACID 是数据库事务正确执行的四个基本特性，由 Haerder 与 Reuter 在 1983 年正式提出。下表总结了每个特性的含义与典型违反场景：

1.2 本地事务与分布式事务

根据事务参与者的范围，事务可分为本地事务与分布式事务。两者在实现复杂度、性能与一致性保证上存在本质区别。

在 Go API 实践中，本地事务适用于单体服务内的单库操作；分布式事务则出现在跨服务、跨数据库的场景，例如订单服务同时调用支付服务与库存服务。

1.3 事务边界定义

事务边界（Transaction Boundary）是指事务开始（Begin）与结束（Commit / Rollback）之间的代码范围。它决定了哪些操作属于同一个原子单元。在 Go API 中，事务边界通常对应一个 HTTP 请求处理函数或一个业务用例方法。

事务边界的三个关键要素：

• 开始点：显式调用 tx, err := db.Begin() 或通过 ORM 的 Session 开启。
• 结束点：成功时调用 tx.Commit()，失败时调用 tx.Rollback()。
• 边界内的操作集合：所有在 Begin 与 Commit/Rollback 之间执行的 SQL 语句或资源操作。

下面是一个典型的 Go 本地事务边界示例：

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 - $1 WHERE id = $2", amount, from)
    if err != nil {
        return err
    }

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

    // 事务边界结束
    return tx.Commit()
}

上述代码中，BeginTx 与 Commit 之间的两行 UPDATE 语句构成了一个原子的事务边界。如果第二个 UPDATE 失败，defer tx.Rollback() 会撤销第一个 UPDATE 的修改。

1.4 事务边界与 API 的关系

在 API 设计中，事务边界通常与 HTTP 请求的生命周期对齐。一个 POST /transfer 请求对应一个事务边界。但需要注意：

• 长事务风险：事务边界内不要包含外部 HTTP 调用、文件上传、用户等待等耗时操作，否则会长时间持有数据库连接锁，导致并发下降。
• 嵌套事务：Go 的 database/sql 不支持嵌套事务。如果需要子事务语义，应使用保存点（Savepoint）或业务层面的补偿逻辑。
• 跨服务边界：当 API 需要调用多个微服务时，单个 HTTP 请求内无法使用本地事务覆盖所有操作，必须引入分布式事务模式。

1.5 事务边界设计原则

基于上述概念，在 Go API 中设计事务边界时应遵循以下原则：

1. 最小化原则：事务边界只包含必要的写操作，读操作尽量放在事务外。
2. 无外部依赖原则：事务边界内不发起 HTTP 请求、不等待消息队列响应、不执行长时间计算。
3. 显式边界原则：始终使用 BeginTx / Commit / Rollback 显式控制，避免依赖 ORM 的隐式事务。
4. 超时控制原则：为事务设置合理的超时时间，防止死锁或长时间占用连接。
5. 补偿原则：对于分布式事务，预先设计补偿操作（Compensating Action），确保失败时可回滚到一致状态。