GORM默认对Create、Update、Delete启用事务，带来30%–60%性能损耗；可全局设SkipDefaultTransaction:true禁用，默认不影响Find/First等读操作，但需同步配置连接池并谨慎评估外键、软删除及钩子的事务依赖。
GORM 默认对所有写操作（Create、Update、Delete）启用事务，这会带来约 30%–60% 的性能损耗。如果你的业务场景不依赖单条写操作的原子性保障（比如日志写入、缓存同步、报表统计等），可以安全关闭它。
全局禁用 SkipDefaultTransaction:true
这是最彻底的方式，在初始化 gorm.DB 时直接关掉默认事务行为：
- 所有后续的
Create、Update、Delete调用都不再自动包裹事务 - 读操作（
Find、First等）本就不走事务，不受影响 - 必须搭配连接池复用，否则高并发下可能触发 MySQL “Too many connections” 错误（因事务未显式释放）
- 示例配置：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
SkipDefaultTransaction: true,
PrepareStmt: true, // 建议同时开启预编译
})
⚠️ 注意：SkipDefaultTransaction 是 gorm.Config 字段，不是 Session 参数；改完后需重启服务生效。
按需会话级禁用 db.Session(&gorm.Session{SkipDefaultTransaction:true})
适合混合场景：大部分写操作需要事务，但某些高频、低一致性要求的操作想跳过。
- 只影响当前会话实例，不影响全局
db - 常用于后台任务、异步写入、批量导入等非核心路径
- 错误示范：
tx := db.Session(...); tx.Create(...); db.Update(...)—— 后者仍走默认事务，逻辑割裂 - 正确用法：
tx := db.Session(&gorm.Session{SkipDefaultTransaction: true})
tx.Create(&Log{Msg: "user login"})
tx.Model(&Stat{}).Where("day = ?", today).Updates(map[string]interface{}{"count": gorm.Expr("count + 1")})
为什么不能只靠 db.Begin() 或手动 Commit 来替代？
手动事务和禁用默认事务是两回事，混用极易出错：
-
db.Begin()返回新*gorm.DB实例，若后续继续用原始db调用（如db.Create()），该操作完全绕过事务，数据已落库 -
db.Transaction是推荐方式，但它本身不解决默认事务开销——它只是在已有事务上下文中执行，而这个“已有事务”正是由默认事务机制开启的 - 禁用默认事务后，
db.Transaction依然可用，只是起点从“带事务的连接”变成“干净连接”，开销更低 - 真正要提性能，必须先关掉默认事务层，再按需开启显式事务
容易被忽略的副作用
关掉默认事务不是“一劳永逸”，有几个隐性约束必须检查：
- 外键约束失效风险：MySQL 在非事务模式下执行
INSERT时，如果关联表缺失记录，可能静默失败或报错（取决于 SQL mode） - 软删除（
DeletedAt）仍依赖事务语义来保证DELETE和UPDATE DeletedAt原子性，关掉后需自行兜底 - 钩子（
BeforeCreate等）默认在事务中执行，禁用后它们也脱离事务——若钩子里有 DB 操作，得自己加事务 - 测试环境容易漏掉：单元测试常用内存 SQLite，它对事务敏感度低，线上 MySQL 可能暴露问题
实际项目里，最稳妥的做法是：全局关掉 SkipDefaultTransaction，再对所有业务写操作统一用 db.Transaction 显式包裹——既去掉冗余开销，又保留可控的原子边界。
