乐观锁的版本号机制

多个用户并发更新同一条记录时，乐观锁靠一个从 0 开始、每次更新自动递增的版本号字段来判断冲突：读的时候大家都能并发读，真正提交更新时框架会检查这条记录的版本号是否和自己读到时一致——不一致说明中途被别人改过，本次更新直接拒绝并抛异常，而不是静默覆盖别人的修改。这和悲观锁的思路正相反：悲观锁假设冲突大概率发生，先锁住资源不让别人碰；乐观锁假设冲突是小概率事件，先让大家自由读写，出现真实冲突了再处理，多数时候不需要付锁的代价。发散：乐观锁本质是把”防止脏写”这件事从”事先阻止”变成了”事后检测+拒绝”，代价是调用方必须自己处理冲突异常（通常是提示用户刷新重试），这也是为什么它更适合冲突率低的场景——冲突率一高，用户体验会因为频繁的”提交失败请重试”变差。