Go 多表事务，到底写在哪一层？

写在「业务编排层」，不写在 model / dao / repository

无论你叫它 logic（go-zero）、service / usecase（DDD 分层），还是 biz——事务的 Begin / Commit / Rollback 都属于这一层。

如果把多表事务写进 model，会发生什么

用一个最经典的场景推演：下单 = 建订单(orders) + 扣库存(products) + 扣余额(users)。

方案 A：写在 OrderModel 里

// ❌ 反例：OrderModel 里塞了别的表
func (m *OrderModel) CreateOrder(ctx context.Context, req *Req) error {
    return m.conn.TransactCtx(ctx, func(ctx context.Context, s sqlx.Session) error {
        // 1. 建订单 —— 自己表，OK
        s.ExecCtx(ctx, "insert into orders ...")
        // 2. 扣库存 —— 咦，这是 products 表的 SQL，怎么在我这？
        s.ExecCtx(ctx, "update products set stock=stock-1 ...")
        // 3. 扣余额 —— users 表也来了
        s.ExecCtx(ctx, "update users set balance=balance-? ...")
        return nil
    })
}

方案 B：每个 model 各自开事务

// ❌ 反例：三个独立事务，根本不是原子操作
func (l *CreateOrderLogic) CreateOrder(req *types.Req) error {
    l.svcCtx.OrderModel.Insert(l.ctx, order)      // 事务1：提交 ✓
    l.svcCtx.ProductModel.DecrStock(l.ctx, pid, 1) // 事务2：提交 ✓
    l.svcCtx.UserModel.DecrBalance(l.ctx, uid, amt) // 事务3：余额不足 → 失败 ✗
    // 结果：库存扣了、钱没扣、订单却生成了 → 数据不一致
    return nil
}

方案 C：model 之间互相调用

model / dao / repository / logic 到底是啥关系

这四个词本质上只有两个层次：数据访问层（前三个，只是叫法不同）+ 业务编排层（最后一个）。

三档判定：你的事务该由谁负责

按「需要保证一致性的数据，跨越了多大的边界」来分三档。

一次多表事务的完整调用链

业务层握着事务的开关，数据层只是被"注入"了同一个连接。

纯 Go（database/sql）怎么写

最能看清本质的写法：*sql.Tx 作为参数显式往下传。

数据层：方法接收 tx

// internal/repository/order.go —— 数据层，不知道事务的存在
type OrderRepo struct{ db *sql.DB }

// tx 为 nil 时用自己的 db（非事务场景）；不为 nil 时用调用方给的事务
func (r *OrderRepo) Create(ctx context.Context, tx *sql.Tx, o *Order) (int64, error) {
    ex := r.execer(tx)
    res, err := ex.ExecContext(ctx,
        "insert into orders(user_id,amount) values(?,?)", o.UserID, o.Amount)
    if err != nil { return 0, err }
    return res.LastInsertId()
}

// 统一取「执行器」：有 tx 用 tx，没 tx 用 db
func (r *OrderRepo) execer(tx *sql.Tx) interface {
    ExecContext(context.Context, string, ...any) (sql.Result, error)
} {
    if tx != nil { return tx }
    return r.db
}

业务层：开事务、编排、提交

// internal/usecase/place_order.go —— 业务编排层，事务边界在这里
func (uc *PlaceOrderUC) PlaceOrder(ctx context.Context, req Req) error {
    tx, err := uc.db.BeginTx(ctx, nil)
    if err != nil { return err }
    defer tx.Rollback()   // 已提交后再 Rollback 会返回 ErrTxDone，无害

    // 1. 建订单
    orderID, err := uc.orderRepo.Create(ctx, tx, &Order{UserID: req.UID, Amount: req.Amount})
    if err != nil { return err }   // return 触发 defer 回滚

    // 2. 扣库存
    if err := uc.productRepo.DecrStock(ctx, tx, req.PID, req.Num); err != nil {
        return err
    }

    // 3. 扣余额（余额不足 → 直接回滚前两步）
    if err := uc.userRepo.DecrBalance(ctx, tx, req.UID, req.Amount); err != nil {
        return err
    }

    return tx.Commit()   // 全部成功才提交
}

GORM 怎么写

GORM 把「事务」收敛成了一个回调方法，但位置原则完全一样。

// 业务层：db.Transaction 定义事务边界
func (s *OrderService) PlaceOrder(ctx context.Context, req Req) error {
    return s.db.WithContext(ctx).Transaction(func(tx *gorm.DB) error {
        // 注意：下面全部用 tx，绝不能用 s.db，否则就脱离事务了！
        if err := tx.Create(&Order{UserID: req.UID, Amount: req.Amount}).Error; err != nil {
            return err   // 返回 error → 自动回滚
        }
        if err := s.productRepo.DecrStockWithTx(tx, req.PID, req.Num); err != nil {
            return err
        }
        if err := s.userRepo.DecrBalanceWithTx(tx, req.UID, req.Amount); err != nil {
            return err
        }
        return nil   // 返回 nil → 自动提交
    })
}

// 数据层：方法接收 *gorm.DB（本质是 tx 或 db）
func (r *ProductRepo) DecrStockWithTx(tx *gorm.DB, pid int64, num int) error {
    return tx.Exec("update products set stock=stock-? where id=? and stock>=?", num, pid, num).Error
}

go-zero 怎么写（官方推荐做法）

go-zero 里没有 repository、没有 dao——model 就是数据访问层，logic 就是业务编排层。事务边界在 logic。

先看目录：go-zero 的分层

做法 A（推荐）：logic 开事务 + model 用 WithSession

缓存版 model 的标准写法：把同一个 session"注入"给每个 model。

// internal/logic/createorderlogic.go —— 事务边界在 logic
func (l *CreateOrderLogic) CreateOrder(req *types.CreateOrderReq) (*types.CreateOrderResp, error) {
    var orderID int64

    // 开启事务：任意 model 都能当"事务发起方"，因为它们连的是同一个库
    err := l.svcCtx.OrderModel.TransactCtx(l.ctx, func(ctx context.Context, session sqlx.Session) error {

        // 1. 建订单：把 session 注入 OrderModel
        orderModel := l.svcCtx.OrderModel.WithSession(session)
        res, err := orderModel.Insert(ctx, &model.Order{
            Userid: req.UserId, Amount: req.Amount, Status: 0,
        })
        if err != nil { return err }
        orderID, err = res.LastInsertId()
        if err != nil { return err }

        // 2. 扣库存：同一个 session 注入 ProductModel
        productModel := l.svcCtx.ProductModel.WithSession(session)
        if err := productModel.DecrStock(ctx, req.ProductId, req.Num); err != nil {
            return err   // 返回 err → 整体回滚
        }

        // 3. 扣余额
        userModel := l.svcCtx.UserModel.WithSession(session)
        if err := userModel.DecrBalance(ctx, req.UserId, req.Amount); err != nil {
            return err
        }

        return nil   // 返回 nil → 提交
    })
    if err != nil {
        return nil, err
    }
    return &types.CreateOrderResp{Id: orderID}, nil
}

做法 B：logic 开事务 + session 直接写 SQL

适合「跨表的复杂 SQL」或「临时逻辑」，不走 model 封装。

func (l *CreateOrderLogic) CreateOrder(req *types.CreateOrderReq) error {
    return l.svcCtx.OrderModel.TransactCtx(l.ctx,
        func(ctx context.Context, session sqlx.Session) error {
            // 建订单
            res, err := session.ExecCtx(ctx,
                "insert into orders(userid,amount) values(?,?)", req.UserId, req.Amount)
            if err != nil { return err }

            // 扣库存（带条件更新，防超卖）
            ret, err := session.ExecCtx(ctx,
                "update products set stock=stock-? where id=? and stock>=?",
                req.Num, req.ProductId, req.Num)
            if err != nil { return err }
            affected, err := ret.RowsAffected()
            if err != nil { return err }
            if affected == 0 {
                return errorx.New("库存不足")   // 主动返回错误 → 回滚订单
            }
            return nil
        })
}

做法 C：model 里补上事务能力（非缓存版必做）

goctl 生成的默认接口里没有 TransactCtx，需要你在可定制文件里补。

// internal/model/ordermodel.go —— 这是「可定制」文件，不是 _gen.go，可以改

// 1. 把事务方法加进接口（否则 logic 通过接口类型调不到）
type OrderModel interface {
    orderModel   // goctl 生成的 CRUD 方法
    TransactCtx(ctx context.Context, fn func(context.Context, sqlx.Session) error) error
    WithSession(session sqlx.Session) OrderModel
}

// 2. 在 custom 结构里实现
func (m *customOrderModel) TransactCtx(
    ctx context.Context, fn func(context.Context, sqlx.Session) error) error {
    // 缓存版：m.CachedConn 直接就有 TransactCtx
    // 非缓存版：m.conn 是私有字段，需在同一包内访问（本文件就在 model 包内，OK）
    return m.conn.TransactCtx(ctx, fn)
}

func (m *customOrderModel) WithSession(session sqlx.Session) OrderModel {
    return NewOrderModel(sqlx.NewSqlConnFromSession(session))
}

// 3. 自定义业务方法：接收 session，用于事务内
func (m *customOrderModel) DecrStockWithSession(
    ctx context.Context, session sqlx.Session, pid, num int64) error {
    query := fmt.Sprintf("update %s set stock=stock-? where id=? and stock>=?", m.table)
    _, err := session.ExecCtx(ctx, query, num, pid, num)
    return err
}

go-zero 为什么把事务放在 logic

这不是"约定俗成"，而是被 go-zero 的依赖结构逼出来的必然结果。

核心 API 一览（已核对 go-zero 源码）

tx / session 怎么往下传给数据层

两种流派，Go 社区有明确倾向。

跨库 / 跨服务：本地事务不管用了

go-zero 是微服务框架，订单、库存、用户往往在不同的服务、不同的库里。此时 TransactCtx 无能为力。

一页速查：到底写哪

常见踩坑清单