gorm默认对写操作开启事务，即自动执行begin/commit，但不处理错误回滚、不捕获panic，易引发性能与逻辑问题；应优先关闭skipdefaulttransaction，显式用transaction控制真正需原子性的场景。
GORM 默认对写操作开启事务，不是“自动帮你保证一致性”，而是“默认包一层 BEGIN/COMMIT”，这反而容易引发性能和逻辑问题。
为什么 Create/Update/Delete 默认走事务
GORM 1.20 及之后版本，在执行 Create、Save、Update、Delete 等写操作时，若未显式传入 *gorm.DB（即没用 tx.Create(...)），会自动在内部调用 db.Begin() → 操作 → Commit()。这不是可配置的“事务开关”，而是写操作的默认执行路径。
- 它不区分单条还是批量操作，哪怕只改一个字段，也触发完整事务流程
- 底层依赖数据库驱动是否支持隐式事务（MySQL 支持，SQLite 需显式 BEGIN）
- 这个默认事务**不捕获 panic**，也不处理中间错误回滚——它只是“尽力提交”，失败就直接抛错
SkipDefaultTransaction 是性能关键开关
如果你的业务场景明确不需要事务保障（比如日志写入、缓存同步、统计计数），禁用默认事务能带来显著收益：
- 实测提升约 30%~60% 的写入吞吐（取决于数据库往返延迟）
- 避免无谓的锁竞争和 WAL 日志写入
- 配置方式简单直接：
SkipDefaultTransaction: true写在gorm.Config里
示例初始化代码：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
SkipDefaultTransaction: true,
})
默认事务 ≠ 安全，反而掩盖真实问题
开发者常误以为“既然默认事务，那并发更新就天然安全”，但事实相反：
- 每条写操作是独立事务，无法跨语句保证原子性（比如先查余额再扣款，两次操作不在同一事务内）
- 高并发下易触发死锁，尤其当多 goroutine 对同一行按不同顺序更新时
- 日志中看不到 BEGIN/COMMIT，调试时难以定位“谁在悄悄开事务”
- 与手动事务混用时，可能因连接复用导致行为不可预测（例如
db.Create和tx.Update实际走不同连接）
什么时候必须保留默认事务
仅当满足以下全部条件时，才建议保持默认开启：
- 写操作极少，且每条都要求强一致性（如用户注册：插入 user + 插入 profile）
- 没有手动事务嵌套需求，也不依赖 SavePoint
- 团队对事务边界有清晰共识，且所有写操作都走 GORM 方法（不混用
db.Session(&gorm.Session{...})或原生sql.Tx）
否则，更稳妥的做法是：全局关闭默认事务，把事务控制权收归业务层，用 db.Transaction(...) 显式包裹真正需要原子性的逻辑块。
最易被忽略的一点：默认事务的隔离级别由数据库决定（通常是 REPEATABLE READ 或 READ COMMITTED），GORM 不做干预；而你手动开启的事务，可以通过 db.Session(&gorm.Session{PrepareStmt: true}) 或 db.Set("gorm:query_option", "...") 调整，这点在读已提交场景下尤为关键。
