gorm事务需手动提交或回滚；db.transaction()仅按闭包返回值自动收尾，不处理panic；withcontext().transaction()的context超时不影响commit/rollback；嵌套事务中defer tx.commit()错误，因savepoint回滚不终止事务。
GORM 的事务不会“自动提交”——它默认不开启事务，显式开启后必须手动 Commit 或 Rollback。所谓“自动提交”，其实是没开事务时的默认行为：每条 db.Create、db.Save 等操作都走独立语句，在 database/sql 层以 auto-commit 模式执行。一旦你调用 db.Begin()，就进入了手动事务控制阶段，GORM 不会替你决定何时提交。
为什么 db.Transaction(func(tx *gorm.DB) error { ... }) 会“自动结束”？
这个函数看起来像“自动提交”，其实只是封装了错误判断和收尾逻辑：
- 它内部调用
db.Begin()获取事务对象tx - 把
tx传入你提供的闭包，执行业务逻辑 - 闭包返回
nil→ 调用tx.Commit()；返回非nilerror → 调用tx.Rollback()
这不是“自动提交”，而是“按错误值自动收尾”。如果你在闭包里 panic，或者忘了 return error，它照样 commit —— 所以别依赖它兜底。
db.WithContext(ctx).Transaction() 的超时行为怎么处理？
传入带 deadline 的 context（如 context.WithTimeout）只影响事务内 SQL 执行，不影响 commit/rollback 本身：
- SQL 查询超时会返回 error，闭包退出，触发 rollback
- 但
tx.Commit()是一次独立网络请求，它不继承原 context；如果 commit 阶段卡住（如网络抖动），会无限等待 - 正确做法是：对 commit 和 rollback 单独加短超时，或用
tx.Session(&gorm.Session{Context: timeoutCtx})尝试穿透（效果取决于驱动支持度）
嵌套事务（SavePoint）为什么不能靠 defer tx.Commit()？
当你用 tx.SavePoint("sp1") 创建保存点，后续 rollback 到该点，并不等于整个事务结束。常见误写：
tx := db.Begin()
defer tx.Commit() // ❌ 错！即使中间 rollback to savepoint，这里仍会 commit 整个事务
tx.SavePoint("sp1")
// ...
tx.RollbackTo("sp1")
// 后续还可能继续操作 tx，甚至再 Commit
真正安全的做法是：每个 savepoint 分支自己管理提交/回滚边界，不要依赖顶层 defer；或者改用 db.Transaction() 封装最外层，内部用 tx.SavePoint 做局部回滚。
事务的终点不是语法糖，而是明确的 commit 或 rollback 调用。最容易被忽略的是：GORM 不拦截 panic，也不重试失败的 commit —— 这些都得你自己在应用层兜住。
