微服务数据版本控制必须用整型version字段配合update ... set version = version + 1 where id = ? and version = ?，且rowsaffected() == 0才是冲突唯一信号；gorm的version字段仅在字段名严格为version、类型为int/int64/uint、迁移使用int/integer、且仅save()/updates()调用时生效，其他方式均绕过校验。
直接说结论：微服务里做数据版本控制，别用 updated_at 或自定义 version_num 字段，必须用整型 Version 字段配合 UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?，且每次更新后必须检查 RowsAffected() 是否为 0 —— 这是唯一能确认冲突的方式，err == nil 完全不可靠。
为什么 GORM 的 Version 字段经常静默失效
GORM 不会自动给你加乐观锁，它只在极窄条件下响应 Version 字段：
- 字段名必须严格叫
Version（首字母大写），类型必须是int、int64或uint；string、version_num、嵌套在BaseModel里的字段全都不生效 - 数据库迁移时，MySQL 必须用
INT，PostgreSQL 必须用INTEGER；BIGINT在 GORM v1.25+ 中可能不递增，导致版本卡住 - 仅对
Save()、Updates()生效；UpdateColumns()、Exec()、map[string]interface{}写法会绕过校验 - 你不能先
Find出来、手动改Version值再Save—— GORM 只在未修改Version字段的前提下，才把它塞进WHERE条件
RowsAffected() == 0 才是冲突的唯一信号
MySQL 和 PostgreSQL 都不会因 WHERE version = ? 不匹配而报错，err 永远是 nil。只靠 if err != nil 判断，等于放弃所有并发保护。
- 正确姿势：
res := db.Model(&u).Where("id = ? AND version = ?", u.ID, u.Version).Updates(...); if res.RowsAffected() == 0 { return ErrOptimisticLock } - 错误写法：
if err == nil { /* 就当成功了 */ }—— 此时可能已被覆盖，业务逻辑继续跑偏 - 想区分“记录不存在”和“版本冲突”，得在
WHERE里同时带上id和version，或前置一次SELECT查主键是否存在 - PostgreSQL 可用
RETURNING version简化判断，MySQL 不支持，别依赖
重试逻辑必须带边界，且不能包在事务里
乐观锁不是“重试万能膏药”，无限制循环或套事务反而放大风险：
- 重试前必须重新
SELECT当前行（含最新Version），不能复用旧结构体里的值 - 推荐最多重试 3 次，间隔用指数退避（如
10ms → 30ms → 100ms），避免雪崩 - 别把重试包在
db.Transaction()里 —— 乐观锁本意就是轻量、无长锁，加事务反而拖慢吞吐、增加死锁概率 - 高频小字段更新（如点赞数）直接用
UPDATE SET count = count + 1，没必要引入Version字段
最容易被忽略的一点：GORM 自动乐观锁只保单行一致性。跨表更新、多资源协同变更时，Version 字段无法保证原子性，该上分布式事务或消息最终一致就得上，别硬扛。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
