gorm 不能替代分布式锁，因其无跨进程互斥能力；必须用 redis/etcd 实现锁，gorm 仅在持锁后执行业务sql，select for update仅限单实例事务内有效，无法解决多副本并发冲突。
直接用 GORM 做分布式锁不可靠，它没有原子性加锁语义，也不提供跨进程互斥保障；真正可行的路径是：GORM 仅负责数据操作，分布式锁必须由 Redis 或 Etcd 等外部协调服务承担，GORM 只在拿到锁后执行业务 SQL。
为什么不能用 GORM 的事务或 SELECT FOR UPDATE 当分布式锁
PostgreSQL/MySQL 的 SELECT FOR UPDATE 只在单数据库实例、同一事务内有效；一旦服务部署多副本，每个实例连接各自的数据库连接池，彼此看不到对方的行锁。更关键的是：SELECT FOR UPDATE 会阻塞而非失败，超时策略难控制，且无法跨表、跨库协调——它本质是悲观锁的本地实现，不是分布式锁。
- 现象：两个服务实例同时执行
SELECT ... FOR UPDATE，都成功返回行，后续 UPDATE 都写入成功，产生脏写 - 原因：数据库锁作用域限于当前连接会话，不广播到其他节点
- 兼容性风险：SQLite 不支持，TiDB 在 Read Committed 隔离级别下行为不一致
GORM + Redis 实现带自动续期的锁（推荐组合）
核心思路是用 GORM 处理业务数据，用 Redis 实现锁生命周期管理。重点不在“怎么连 Redis”，而在于锁对象与 GORM 事务的绑定时机和错误传播方式。
-
TryLock()必须在 GORMBegin()之前调用，否则锁保护范围漏掉事务开启前的逻辑（如参数校验、缓存读取） - 锁 value 必须是随机字符串（如
uuid.NewString()），不能用时间戳或固定值，否则Unlock()时 Lua 脚本比对失败 - 续期 goroutine 必须绑定到锁实例，且用
sync.Once启动，避免一个请求启多个看门狗，互相覆盖过期时间 - 示例关键片段：
lock := NewDistributedLock(rdb, "order:"+orderID, 30*time.Second) ok, err := lock.TryLock(ctx) if !ok || err != nil { return errors.New("failed to acquire lock") } defer func() { if ok { // 注意：只在加锁成功后才 defer Unlock _ = lock.Unlock(ctx) } }() tx := db.Begin() // ... GORM 操作 tx.Commit()
误用 GORM 乐观锁当分布式锁的典型陷阱
GORM 的 optimisticlock 插件只解决单次 UPDATE 的并发冲突，它依赖数据库 version 字段做 CAS，但不阻止并发请求同时进入业务逻辑——10 个请求全查到 version=1，全发起 UPDATE，其中 9 个失败回滚，仍造成无效负载和日志刷屏。
- 这不是锁，是冲突后重试机制；无法防止资源争抢（如发重复短信、扣双倍库存）
- version 字段需手动维护，GORM 不自动初始化，首次 INSERT 若漏设
Version: 1，后续所有 UPDATE 都失败 - 无法与外部系统协同：比如扣库存成功了，但下游 Kafka 消息发送失败，此时乐观锁已无能为力
- 真正需要锁的场景（如定时任务去重、幂等接口入口），乐观锁完全不适用
什么时候可以考虑 MySQL 表模拟分布式锁（仅限低流量）
如果硬性不能引入 Redis/Etcd，且 QPS
- 锁表必须只有
key VARCHAR(128) PRIMARY KEY和holder_id VARCHAR(64)两列，禁止加任何额外字段或索引 - 加锁用
INSERT INTO lock_table (key, holder_id) VALUES (?, ?)，依赖唯一键冲突判断是否抢锁成功；不能用INSERT IGNORE或REPLACE，它们不返回影响行数 - 释放锁必须用
DELETE FROM lock_table WHERE key = ? AND holder_id = ?，GORM 的Delete()会生成WHERE IN或额外条件，必须手写 Raw SQL - 注意 MySQL 的 autocommit 默认开启，每次 INSERT/DELETE 都是独立事务，没锁住就结束了
这种方案没有自动续期、无法探测持有者存活状态，线上环境慎用——它只是“能跑”，不是“该用”。
