Go事务生效关键在于所有操作必须绑定同一*sql.Tx实例，混用db.Exec()会脱离事务立即提交；GORM中需用tx.Create()而非db.Create()；Savepoint需手写SQL；推荐使用db.Transaction()自动管理。
Go 语言事务不是“开了就自动生效”，关键在操作是否绑定到同一个 *sql.Tx 实例上。用 db.Begin() 或 db.BeginTx() 启动事务后，所有 SQL 执行必须调用 tx.Query()、tx.Exec() 等方法；一旦混用 db.Exec()，语句就脱离事务、立即提交。
为什么 db.Exec() 在事务里不生效
事务对象 *sql.Tx 和数据库句柄 *sql.DB 是两个独立实例。*sql.Tx 内部持有一个独占的底层连接，而 *sql.DB 操作走连接池，每次调用都可能分配新连接。
-
db.Exec()绕过事务连接，直接从连接池取空闲连接执行，语句自动提交，无法回滚 - 哪怕你刚调完
tx.Exec()，下一行写db.QueryRow()，这条查询也不在事务中 - GORM 中同理：
db.Create()≠tx.Create()，后者才是事务内操作
BeginTx 传 context 超时但 SQL 还在跑
context.WithTimeout 只控制 BeginTx 阻塞等待连接的时长，不影响已发出的 tx.Exec()。事务开启成功后，SQL 执行是否中断，完全由数据库侧决定。
- PostgreSQL：需在 DSN 或会话级设置
statement_timeout（单位 ms） - MySQL：用
SET SESSION max_execution_time = 5000，或在 DSN 加timeout=5s（驱动支持） -
tx.Rollback()不会中止正在运行的 SQL，只标记后续操作无效；真正释放连接要等语句自然结束 + 连接池回收
Savepoint 必须手写 SQL
database/sql 标准库不提供 Savepoint 接口，所有保存点操作都得用原生 SQL 字符串手动执行。
立即学习“go语言免费学习笔记（深入）”；
- 创建：
tx.Exec("SAVEPOINT sp_123") - 回滚到：
tx.Exec("ROLLBACK TO SAVEPOINT sp_123") - 释放：
tx.Exec("RELEASE SAVEPOINT sp_123") - 名字别重复——建议用
uuid.NewString()或带业务前缀的字符串（如"order_create_sp"） - 注意 MySQL 5.7 不支持命名 savepoint，只认
SAVEPOINT a这种单字母名
GORM 中 Transaction 闭包 vs Begin 的选择
95% 的业务场景该用 db.Transaction()，而不是裸调 db.Begin()。前者是 panic 安全、自动 commit/rollback 的封装；后者是底层原语，容易漏处理。
-
db.Transaction(func(tx *gorm.DB) error { ... })：闭包返回非 nil error 自动 rollback，panic 也会被捕获并 rollback -
tx := db.Begin()：必须自己写defer tx.Rollback()+ 显式tx.Commit()，漏写就卡死连接 - 嵌套“事务”本质是 savepoint：用
tx.Session(&gorm.Session{AllowGlobalUpdate: true}).Begin()，不是新开事务 - 别在
Transaction闭包里再调一次db.Transaction()——它会新建事务，破坏外层一致性
事务真正的复杂点不在语法，而在执行路径是否全程受控：任何一次误用 db.Xxx()、跨 goroutine 复用 tx、忘记释放 savepoint 名字，都会让事务语义失效。边界清晰比写对第一行 Begin() 更难也更重要。
