GORM默认Update不带版本校验，导致并发时后写入覆盖前写入；必须显式用WHERE加version条件、SET递增version、执行后检查RowsAffected是否为0，三者缺一不可。
为什么直接用 GORM 的 Update 会丢更新？
多个请求同时读取同一条记录、各自修改后调用 Save 或 Update，后写入的会覆盖前写入的——GORM 默认不带版本校验，本质是“最后提交者胜出”，不是并发安全的。这不是 Gin 的问题，而是没启用乐观锁机制。
乐观锁的核心是：更新时检查数据是否被别人改过。GORM 支持通过 UpdatedAt 字段或自定义 Version 字段实现，但必须显式参与 WHERE 条件，否则无效。
-
UpdatedAt字段默认由 GORM 自动维护，但仅用于记录时间，不会自动加入 UPDATE 的 WHERE 条件 - 必须手动在
Where中带上旧的UpdatedAt值，或使用Version字段配合OptimisticLock插件 - Gin 路由里不做额外同步控制，所有并发压力都落到数据库层，靠 SQL 条件拦截失败
怎么让 GORM 在 Update 时带上版本检查？
推荐用 Version 字段 + gorm.Model 组合，比依赖 UpdatedAt 更可靠：时间精度有限、时钟不同步、人为修改都可能破坏一致性。
结构体定义示例：
立即学习“go语言免费学习笔记（深入）”；
type Order struct {
gorm.Model
UserID uint `gorm:"index"`
Amount int64
Status string
Version int64 `gorm:"column:version;default:1"` // 必须显式声明字段
}
更新时写法关键点：
- 先查出当前
Version值（比如v := order.Version） - 用
Where("id = ? AND version = ?", order.ID, v).Save(&order) - 检查
result.RowsAffected == 0，为真说明已被别人抢先更新，当前操作失效
注意：Save 不会自动递增 Version，要自己加一；Update 同理，需显式设置 Version 新值。
Gin 路由里怎么返回合理的并发冲突响应？
不能让前端反复重试却得不到明确反馈。GORM 执行失败时不会 panic，只是 RowsAffected 为 0，需要主动判断。
典型 Gin handler 片段：
func updateOrder(c *gin.Context) {
var order Order
if err := c.ShouldBindJSON(&order); err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": err.Error()})
return
}
// 先查旧值（含 version）
var old Order
if err := db.Where("id = ?", order.ID).First(&old).Error; err != nil {
c.AbortWithStatusJSON(404, gin.H{"error": "not found"})
return
}
// 设置新 version
order.Version = old.Version + 1
// 带 version 条件更新
result := db.Where("id = ? AND version = ?", order.ID, old.Version).Save(&order)
if result.Error != nil {
c.AbortWithStatusJSON(500, gin.H{"error": result.Error.Error()})
return
}
if result.RowsAffected == 0 {
c.AbortWithStatusJSON(409, gin.H{"error": "concurrent update conflict", "current_version": old.Version})
return
}
c.JSON(200, order)
}
关键细节：
-
409 Conflict是语义最准确的状态码，比400或500更利于前端识别重试场景 - 返回
current_version让前端决定是否拉取最新状态再重试 - 不要在事务里做多次 SELECT + UPDATE，除非必要——GORM 的
Where(...).Save()本身是原子的
为什么不用数据库原生 SELECT FOR UPDATE？
悲观锁（SELECT FOR UPDATE）在高并发写场景下容易引发锁等待、死锁、连接池耗尽。Gin + GORM 架构下，它要求整个 HTTP 请求生命周期持有 DB 连接，不可控因素太多。
乐观锁更适合 Web API 场景，但要注意两个现实约束：
- 业务逻辑不能依赖“连续多次读-改-写”中间状态，比如先查余额、再扣减、再查余额是否够——这必须用数据库事务+行锁，乐观锁无法保证中间态一致性
- 前端重试策略要合理，避免雪崩。建议加退避（如指数退避），并限制最大重试次数
-
Version字段类型必须是整型（int/int64），不能是string或time.Time，否则 GORM 不识别为乐观锁字段
真正难的不是加一行 Version，而是把业务里隐含的“读-改-写”原子性需求，拆解成可被乐观锁保护的单次更新动作。
