不能将*sql.tx塞入context.context，因其违背context只读元数据设计初衷，导致生命周期错位、并发不安全（commit/rollback不可重入）、错误流向隐晦；正确做法是显式函数参数传递，并确保单goroutine使用。
为什么不能直接把 *sql.Tx 塞进 context.Context
Go 的 context.Context 设计初衷是传递请求范围的**只读元数据**（如超时、取消信号、用户 ID），不是用来传状态对象或资源句柄的。把 *sql.Tx 放进去，表面上能跑通，但会带来三个实际问题：
一是事务生命周期和 context 生命周期错位——context 可能提前 cancel，但 *sql.Tx 还没 Commit() 或 Rollback()；二是并发不安全——多个 goroutine 同时从 context 取同一个 *sql.Tx 并调用 Commit() 会 panic；三是掩盖错误流向——本该由调用方显式管理事务边界，却退化成隐式依赖 context 查找。
正确的做法：用函数参数显式传递 *sql.Tx
把事务对象作为参数传给需要它的函数，是最清晰、最可控的方式。它让依赖关系一目了然，也方便单元测试（可传 mock *sql.Tx）。
常见结构如下：
func CreateUser(tx *sql.Tx, name string) error {
_, err := tx.Exec("INSERT INTO users(name) VALUES (?)", name)
return err
}
func HandleCreateUser(req *http.Request) error {
tx, err := db.Begin()
if err != nil {
return err
}
defer func() {
if err != nil {
tx.Rollback()
}
}()
err = CreateUser(tx, req.URL.Query().Get("name"))
if err != nil {
return err
}
return tx.Commit()
}
- 所有数据库操作函数都接受
*sql.Tx为第一个参数（或统一封装在 service struct 中） - 事务的
Begin/Commit/Rollback必须由最外层控制，不能分散在各处 - 不要在中间件或 handler 里“偷偷”从 context 提取事务——这会让调用链难以追踪
如果非要用 context（比如框架强制），至少加类型安全包装
某些 ORM（如 ent）或 Web 框架（如 gin）允许通过 context 透传事务，但它们都做了类型安全封装，避免裸指针误用。自己实现时，可以定义一个带 key 的私有类型：
type txKey struct{}
func WithTx(ctx context.Context, tx *sql.Tx) context.Context {
return context.WithValue(ctx, txKey{}, tx)
}
func FromTx(ctx context.Context) (*sql.Tx, bool) {
tx, ok := ctx.Value(txKey{}).(*sql.Tx)
return tx, ok
}
- key 必须是 unexported 类型（如
txKey struct{}），防止外部代码误覆写 - 每次取值必须做类型断言 +
bool检查，不能假设一定存在 - 仍需确保
*sql.Tx不被并发调用Commit()——context 不解决并发问题
容易被忽略的坑：*sql.Tx 不是线程安全的
哪怕你用 context 把 *sql.Tx 传到了多个 goroutine，也不能让它们同时执行查询或提交。官方文档明确说：*sql.Tx 是**单 goroutine 使用**的。典型反模式：
go func() {
CreateUser(ctx, "alice") // ❌ 并发调用，可能 panic: "sql: Transaction has already been committed or rolled back"
}()
- 事务对象本身不提供锁保护，
Commit()和Rollback()都是不可重入的 - 如果业务确实需要并发 DB 操作，应该在事务内启动多个
*sql.Stmt，或拆成多个独立事务 - context 无法改变这个底层约束——它只是个容器，不是同步机制
*sql.Tx 塞进 context，除非你已经处理了取消、panic 恢复、并发访问和资源泄漏的所有路径。
