GORM中不存在真正的“无阻塞事务”，事务的隔离性依赖数据库锁或MVCC，阻塞源于底层DB行锁等待；减少阻塞应优先优化索引、选用共享锁、乐观锁重试或AfterCommit延迟操作。
GORM 里没有“无阻塞事务”这种东西——事务天然要协调并发，阻塞是锁机制的必然表现。所谓“无阻塞”，实际是指避免显式加锁（如 FOR UPDATE）、减少锁等待、或用非锁手段达成最终一致性。
为什么不能直接去掉事务的阻塞？
事务的 ACID 特性中，隔离性（Isolation）依赖数据库锁或 MVCC 快照来实现。GORM 的 db.Transaction 本身不引入阻塞，但一旦你在事务内执行带锁查询（如 Clauses(clause.Locking{Strength: clause.LockingStrengthUpdate})），阻塞就来自 MySQL/PostgreSQL 的行锁等待。绕过锁 ≠ 绕过事务；跳过事务 ≠ 实现安全并发。
- MySQL 的
SELECT ... FOR UPDATE在行不可得时会等待，直到超时（innodb_lock_wait_timeout）或被 kill - GORM 的
Transaction函数只保证原子提交/回滚，不改变底层锁行为 - 把写操作移出事务（比如先查再异步更新）会破坏原子性，导致中间状态暴露
Shared Lock（S 锁）不是无阻塞，但能降低写冲突
当你只需要「读取 + 防止他人改」，而非「马上要改」，LockingStrengthShared 是比 LockingStrengthUpdate 更轻的选择。它允许多个事务同时持 S 锁，但会阻塞 U/X 锁请求（即其他事务的 UPDATE/DELETE/SELECT FOR UPDATE）。
- 适用场景：
优惠券核销前校验剩余张数、订单幂等检查、配置项只读快照 - 必须走索引 WHERE，否则可能升级为间隙锁甚至表锁
- 不能替代写操作：拿到 S 锁后仍需另起一次带 U 锁的查询或直接
UPDATE，否则会报错或产生竞态 - 示例：
tx.Clauses(clause.Locking{Strength: clause.LockingStrengthShared}).Where("id = ? AND status = 'unused'", cid).First(&coupon)
真正减少阻塞的替代路径：乐观锁 + 重试
放弃悲观锁（FOR UPDATE），改用版本号或条件更新，在冲突时捕获错误并重试。这在高读低写、冲突概率低的场景下，吞吐反而更高。
- 结构体加字段：
Version uint `gorm:"column:version"`，配合UpdateColumns或Updates条件写入 - 关键写操作用
WHERE id = ? AND version = ?，成功则version++，失败则 reload + retry - 捕获 MySQL 错误码 0：表示影响行数为 0（没更新到），不是异常，应主动重试
- 注意：重试逻辑必须下沉到 service 层，不能放在 HTTP handler 里裸循环；每次重试建议加
time.Sleep指数退避
事务外做“准原子”操作：AfterCommit 钩子
很多你以为必须塞进事务的操作，其实可以延迟——只要它不破坏核心数据一致性。GORM 的 tx.AfterCommit() 是唯一安全出口。
- 典型误用：
事务内调第三方 HTTP 接口、写 Redis 缓存、发 MQ 消息—— 这些 I/O 一卡，整个事务连接就被占住 - 正确做法：
tx.AfterCommit(func(tx *gorm.DB) { // 这里 tx 已提交，但上下文还可用 cache.Set("order_"+strconv.Itoa(order.ID), order, time.Minute) }) - 限制：
AfterCommit只对当前tx实例生效；若传参错用db或新建tx.WithContext()，钩子失效
最常被忽略的一点：锁粒度和执行计划永远比框架调用方式重要。哪怕你写对了 Clauses，如果 WHERE 条件没走索引，InnoDB 依然会锁一大片记录——这时“无阻塞”设计从第一步就失效了。
