GORM事务本身不支持降级，所谓“事务降级”实为业务层兜底策略：需显式判断错误类型、隔离执行fallback、确保降级逻辑脱离事务上下文且无副作用。
直接说结论：GORM 事务本身不支持“降级”，所谓“事务降级”其实是业务逻辑在数据库操作失败时的兜底策略，核心在于把错误判断、fallback 执行、状态隔离这三件事拆清楚——别指望 tx.Commit() 自动帮你 fallback。
为什么不能在 Transaction() 闭包里加 fallback？
GORM 的 Transaction() 方法内部会自动 recover() panic 并回滚，但它对 error 是完全透明的。你写成这样：
db.Transaction(func(tx *gorm.DB) error {
if err := tx.Create(&order).Error; err != nil {
return getDefaultOrder() // ❌ 这里 return 的不是 error，而是结构体，编译都过不去
}
return nil
})
根本走不通。它只认 error 类型返回值，且一旦返回非 nil error，事务就回滚，但不会触发任何兜底逻辑。
-
Transaction()是原子性保障机制，不是容错调度器 - 兜底必须由上层 service 显式控制，比如调用
createOrderWithFallback(ctx)这样的封装函数 - 所有 fallback 函数（如
getDefaultOrder()）必须无副作用、零延迟、不依赖 DB 或网络
嵌套事务失败时，如何避免降级逻辑被连带拖垮？
MySQL 没有真正嵌套事务，GORM 的 tx.Begin() 只是建 savepoint。如果子事务失败后你仍试图走降级路径，而降级逻辑又去查 Redis 或调另一个服务，那就等于把熔断器绕过去了。
- 子事务（如扣库存）失败，应立即中止后续 DB 操作，不进降级分支；降级只对外部依赖（HTTP/Redis）失效时启用
- 若库存扣减失败是因 DB 连接超时，说明数据库已不可用，此时再调
getDefaultOrder()是合理的；但如果是唯一键冲突这类业务 error，不该降级，该报错 - 降级结果必须能和主流程共用同一响应结构体，比如都返回
*Order，只是字段来源不同（DB 查 vs 内存 map 查）
怎么让降级逻辑不被事务上下文污染？
很多人把 fallback 写在事务函数内部，结果发现 fallback 里读缓存也卡住——因为整个 goroutine 被绑在了事务的 context 上，而这个 context 可能已被 cancel 或 deadline 到期。
- 降级逻辑必须脱离事务 context 执行，推荐用独立的
context.Background()或带宽松 timeout 的新 context - 别在
tx.Create().Error != nil后立刻调 fallback，先判断 error 类型：errors.Is(err, gorm.ErrRecordNotFound)不该降级，errors.Is(err, context.DeadlineExceeded)才值得兜底 - fallback 函数禁止调用任何带事务语义的方法（如
db.WithContext(...).First()），否则可能意外开启新事务或复用已关闭连接
最易被忽略的一点：降级不是补丁，是设计契约。你在写 CreateOrder 接口时，就必须明确回答——当 DB 不可用时，用户看到的订单 ID 是从哪来的？是固定字符串？是本地递增计数器？还是干脆返回空？这个决策要落在 service 层接口定义里，而不是等 panic 了再现场写 recover()。
