context.withtimeout()对gorm事务无效，因其不传入transaction()回调函数，无法穿透至内部sql执行；超时仅作用于事务开启阶段，事务内各操作须显式调用withcontext()绑定上下文。
context.WithTimeout() 在 GORM 中能控制单条 SQL 执行时间，但不能控制整个事务生命周期；超时触发后 ctx.Err() 会是 context.DeadlineExceeded，而 GORM 内部会在每次数据库操作前检查 ctx.Done() 并提前退出。
为什么 WithTimeout 对 GORM 事务没用？
GORM 的 Transaction() 方法本身不接收 context.Context 参数（v2 默认不透传），它内部启动新 goroutine 或复用连接池时，若未显式将外部 ctx 传入子操作，超时信号就无法穿透到实际的 SQL 执行层。
- 事务函数签名是
func(tx *gorm.DB) error，没有ctx入参，所以你传给db.Transaction()的ctx不会被自动用于其内部的Create/Update等调用 - 即使你在事务里手动调用
tx.WithContext(ctx).Create(...)，也只对那一条语句生效；下一条语句若忘了加WithContext，就彻底脱离超时控制 - 事务回滚由 DB 驱动自身决定，GORM 不会因为
ctx超时就主动发ROLLBACK—— 它只是停止后续操作，连接可能还卡在未提交状态
如何让超时真正作用于每条 SQL？
必须在每个具体的数据操作前显式绑定上下文，且推荐封装成统一入口，避免遗漏。
- 不要写
db.Create(&u)，改用db.WithContext(ctx).Create(&u) - 对事务内每一步都重复该模式：
tx.WithContext(ctx).Model(...).Where(...).Update(...) - 更稳妥的做法是封装一个带 ctx 的 DAO 层方法，例如
userRepo.Create(ctx, &u)，内部统一处理WithContext - 注意：MySQL 驱动（如
go-sql-driver/mysql）支持context，但 SQLite 驱动默认不支持，需确认驱动版本和配置
常见错误现象与排查点
你以为超时了，SQL 却还在跑 —— 这通常不是 GORM 的 bug，而是上下文没传到位或被覆盖。
- 错误写法：
ctx, cancel := context.WithTimeout(context.Background(), time.Second); defer cancel(); db.Transaction(func(tx *gorm.DB) error { return tx.Create(&u).Error })→ 事务内完全没用ctx - 错误写法：
db.WithContext(ctx).Transaction(...)→ 这个WithContext只影响事务开启本身（比如获取连接），不影响内部回调里的操作 - 漏掉
defer cancel()会导致 goroutine 泄漏，尤其在高频接口中容易堆积 timerCtx - 用
context.WithValue()传参数没问题，但别把它和超时混用：超时必须靠WithTimeout或WithDeadline创建新 ctx，WithValue不带取消能力
事务级超时的务实替代方案
真要控制整个事务耗时，GORM 本身不提供原生支持，得靠外围机制兜底。
- 在事务外层加一个独立的
context.WithTimeout，并在事务回调中定期检查ctx.Err() == context.DeadlineExceeded，手动返回错误触发回滚 - 数据库侧设
wait_timeout/max_execution_time（MySQL 5.7+ 支持SET SESSION max_execution_time=2000），作为最后防线 - 使用连接池中间件（如
sqlx+ 自定义 wrapper）拦截所有ExecContext/QueryContext调用，强制注入统一超时 ctx
最易忽略的一点：GORM 的 WithContext 是链式调用，它返回新实例，原 db 或 tx 不变。写错顺序或忘记赋值，等于白加。
