Go sql.Tx 里调用 DB.Query 为什么可能绕开当前事务

事务代码里最容易被忽略的一处边界，是把已经拿到的 *sql.Tx 放在一边，又继续调用全局 *sql.DB。这样写不一定立刻报错，但 DB.Query 面向的是连接池，可能取得另一条连接；它就不属于当前事务，也看不到当前事务尚未提交的修改。

只要查询要参与这次事务，就用 tx.QueryContext 或 tx.QueryRowContext；写入也统一使用 tx.ExecContext。db 负责开启事务，tx 负责事务期间的全部读写。

先分清 DB 与 Tx 的连接边界

sql.DB 代表一个可并发使用的数据库句柄，底层由连接池管理。每次调用 db.Query 或 db.Exec，驱动都可能从池里选择可用连接。这个设计适合普通的独立读写，却不保证连续两次调用落在同一条连接上。

调用 db.BeginTx 后，返回的 *sql.Tx 会绑定一条事务连接。事务里的语句、会话状态和未提交修改都属于这条连接。此时若又调用 db.Query，查询入口回到了连接池，得到的连接可能不同，所以“刚刚写入，随后查询却查不到”并不矛盾。

把事务内查询改成 Tx.QueryContext

修复思路不是给 DB.Query 加更多等待，而是把事务期间的入口统一成 tx。多行结果使用 QueryContext，单行结果使用 QueryRowContext，并沿用开启事务时的上下文：

func createOrder(ctx context.Context, db *sql.DB, userID int64) error {
	// db 只负责开始事务，后续读写都从 tx 发出。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer tx.Rollback() // 提交成功后这里会返回 sql.ErrTxDone，可安全忽略。

	if _, err = tx.ExecContext(ctx,
		"UPDATE users SET order_count = order_count + 1 WHERE id = ?", userID); err != nil {
		return err
	}

	rows, err := tx.QueryContext(ctx,
		"SELECT id, order_count FROM users WHERE id = ?", userID)
	if err != nil {
		return err
	}
	defer rows.Close() // 及时归还结果集占用的连接资源。

	for rows.Next() {
		var id, count int64
		if err := rows.Scan(&id, &count); err != nil {
			return err
		}
		// 在这里处理事务连接上的查询结果。
	}
	if err := rows.Err(); err != nil {
		return err
	}

	return tx.Commit()
}

这里的关键不是方法名中有没有 Context，而是接收者必须是 tx。Context 负责取消和超时，不能把一个由 db 发出的查询“变成”事务查询。

让业务函数拿到正确的数据访问入口

如果每个函数都同时接收 db *sql.DB 和 tx *sql.Tx，调用方很容易选错。可以在事务边界内调用只依赖小接口的函数，让普通连接和事务连接都能提供相同的方法：

type queryer interface {
	// 只声明业务需要的查询能力，避免函数偷偷拿回全局 db。
	QueryContext(context.Context, string, ...any) (*sql.Rows, error)
	QueryRowContext(context.Context, string, ...any) *sql.Row
}

func loadUser(ctx context.Context, q queryer, id int64) (int64, error) {
	var count int64
	// 调用方传 tx 时，这条查询自然留在当前事务连接。
	err := q.QueryRowContext(ctx,
		"SELECT order_count FROM users WHERE id = ?", id).Scan(&count)
	return count, err
}

事务外传 db，事务内传 tx，函数本身不需要知道连接池细节。若函数还要执行写入，可以把接口扩展为包含 ExecContext，但不要为了省参数，把全局 db 藏在包级变量里。

Rows、回滚和提交要一起收口

事务查询的另一个坑是只检查 QueryContext 的返回值，却不检查遍历结束后的 rows.Err。网络中断、驱动读取失败等错误可能在迭代过程中才出现。无论查询还是写入失败，都应让函数返回并触发回滚；defer tx.Rollback() 是常见的兜底写法，成功提交后它只会得到已结束事务的错误。

还要记住三条边界：事务结束后不要继续使用 tx；不要把 DB.Query 当作事务内补充查询；不要把业务结果的“读取成功”误认为事务已经提交。真正的提交点只有 tx.Commit()，它返回错误时也要按调用方约定处理。

常见问题

DB.Query 一定会绕开事务吗？

不能把它理解成每次都必然绕开；准确说法是它不受当前 Tx 的连接绑定约束，可能使用池中的其他连接，因此不应依赖它读取事务内状态。

事务里只读数据也必须使用 Tx 吗？

如果这次读取需要看到同一事务的未提交修改、隔离级别或锁定语义，就必须使用 Tx 提供的查询方法。完全独立于事务的只读查询，才适合直接使用 DB。

排查这类问题时，先沿调用链搜索 db.Query、db.QueryRow 和 db.Exec，再确认它们是否发生在 BeginTx 与 Commit/Rollback 之间。只要事务内的读写都从同一个 tx 发出，连接边界和代码意图就重新对齐了。