乐观锁能防丢失更新，但必须同时满足三条件：where中校验version=?、set中更新version=version+1、执行后检查row_count()是否为0；漏任一环节即失效。
直接说结论：乐观锁能防丢失更新，但UPDATE语句漏掉WHERE version = ?、没在SET里写version = version + 1、或执行后不检查影响行数，三者任一缺失，就等于没锁。
UPDATE语句必须同时满足三个条件才算启用乐观锁
乐观锁不是数据库自动开启的功能，而是靠应用层严格构造 SQL 实现的。它本质是“带条件的原子更新”，缺一不可：
-
WHERE子句中必须显式包含id = ? AND version = ?，不能只写id = ? -
SET子句中必须更新version = version + 1，否则下次WHERE version = ?永远匹配不上 - 执行后必须立刻检查 JDBC 的
executeUpdate()返回值，或 MySQL 的ROW_COUNT()；等于0说明冲突，必须中断流程并报错或重试
常见错误：MyBatis 写了@Update("UPDATE t SET stock = ? WHERE id = ?")，但没拼AND version = #{version}；或者 JPA 实体加了@Version，但字段类型是short，高并发下溢出变负数，导致WHERE version = -1意外命中旧记录。
SELECT时必须把version字段读出来
所有后续要更新的查询，都不能用SELECT *或忽略version映射——否则应用拿不到原始版本值，WHERE version = ?只能填null或0，一执行就失败。
- MyBatis 的
resultMap里必须声明：<result column="version" property="version"></result> - JPA 实体中
@Version字段不能加@Transient，也不能被 JSON 序列化忽略（前端回传时丢掉version，服务端就无法校验） - 列表页带“编辑”按钮的场景，点进去前就得查出
version，不能等点保存时才去SELECT
影响行数为 0 不报错，是绝大多数人踩坑的第二步
MySQL 和 PostgreSQL 都不会因为WHERE不匹配而抛异常，只会安静返回0行影响。很多框架默认把它当“更新成功”处理，结果下游逻辑照常走，比如库存扣减没发生，却返回“扣减成功”。
- 每次
UPDATE后必须手动判断：if (rowsAffected == 0) { throw new OptimisticLockException(); } - 不要依赖 ORM 自动重试机制——MyBatis-Plus 的
@Version只负责拼 SQL，不负责检查返回值；Spring Retry 要自己配，且得确保事务边界合理 - 批量更新慎用乐观锁：逐条执行并校验比一条 SQL 更新多行更安全，避免某一行冲突导致整批失败或掩盖问题
version字段类型和索引容易被忽略
version字段类型选INT或BIGINT，禁用TIMESTAMP和short。前者精度不够、易被绕过校验；后者最大值32767，高并发下刷满就回绕成负数，锁机制彻底失效。
- 给
(id, version)建联合索引，避免WHERE id = ? AND version = ?走全表扫描 - 别和
SELECT FOR UPDATE混用：悲观锁会阻塞，乐观锁靠失败重试，逻辑上冲突，调试时还容易掩盖真实问题 - 重试时必须重新
SELECT最新数据（含最新version），不能拿第一次读的version反复试
真正难的不是写对那一行 SQL，而是让整个链路——从查询、传输、缓存、到更新——都始终带着正确的version值，并在每一处可能出错的地方做显式防御。
