结论：在Gin+GORM中，SelectForUpdate仅在显式事务内、查询命中索引、且后续更新同一行时才有效；漏掉事务包裹、索引缺失或读写行不一致，锁即失效。
直接说结论：在 Gin + GORM 场景下，SelectForUpdate（即 Clauses(clause.Locking{Strength: "UPDATE"})）只有在显式事务内、查询条件命中索引、且后续操作更新的是同一行时，才能真正防止并发冲突。漏掉任意一环，锁就形同虚设。
事务必须手动开启，autocommit=1 时锁立刻失效
MySQL 默认 autocommit=1，单独执行带 FOR UPDATE 的查询（哪怕用了 Clauses），事务一结束锁就释放——后续 Save() 或 Updates() 是全新事务，完全不感知之前那把锁。
- 必须用
db.Transaction(func(tx *gorm.DB) error { ... })包裹整个读-改-写流程 - 不能在 handler 里先
db.Clauses(...).First()拿数据，再另起一个db.Save()—— 这是两个事务，锁无效 - Gin 中不要在中间件或 service 层外提前调用
db.Begin()后忘记Commit()或Rollback()，会导致连接泄漏
查询条件必须走索引，否则升级为表锁
没索引的 WHERE 条件（比如 status = 'pending'）会让 InnoDB 无法精确定位行，被迫加表级锁。2000 QPS 下可能直接拖垮数据库。
- 检查执行计划：
EXPLAIN SELECT * FROM orders WHERE status = 'pending' FOR UPDATE，确认type是const或ref，不是ALL - 主键或唯一索引字段（如
id、order_no）是最安全的锁目标；复合索引需确保最左前缀匹配 - 避免隐式类型转换：
WHERE id = '123'（字符串）可能使索引失效，应统一用int类型传参
锁住的行和更新的行必须严格一致
常见错误：SELECT id, status FROM orders WHERE status = 'pending' FOR UPDATE 锁了一批记录，但 UPDATE orders SET status = 'done' WHERE id = ? 只更新其中一条——其余被锁的行仍被阻塞，浪费锁资源，还可能引发死锁。
- 锁定范围要最小化：优先用主键精确查单条，如
tx.Clauses(...).First(&order, 123) - 批量操作时，
IN查询必须非空，且ORDER BY id保证加锁顺序一致（防 AB/BA 死锁） - 更新语句的
WHERE必须和锁查询的WHERE定位到同一组行，推荐直接用查出的order.ID做条件
锁等待必须设超时，不能无限阻塞
默认 innodb_lock_wait_timeout = 50 秒，HTTP 请求早超时了，连接池却还在等锁，最终雪崩。
- 应用层设置更短的上下文超时：
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second) - 捕获锁等待超时错误：
strings.Contains(err.Error(), "Lock wait timeout")或 MySQL 错误码1205（死锁）、1213（锁超时） - 重试逻辑必须下沉到 service 层，且重试次数 ≤ 3，间隔用指数退避（
10ms → 30ms → 100ms）
最容易被忽略的点是：锁只对「当前事务内后续的写操作」生效，它不保证业务逻辑正确。比如锁了用户 A，却误更新了用户 B 的余额，锁再严也没用。真正可靠的并发控制，永远是「锁什么、改什么、怎么改」三者闭环验证，而不是加个 Clauses 就以为万事大吉。
