标准答案
- 悲观锁通常使用锁定读或显式锁，能在事务内阻止其他事务修改同一资源，但会增加等待和死锁风险。
- 乐观锁常用 version、updated_at 或条件 UPDATE，只有预期版本仍成立才更新成功。
- 冲突概率低、用户编辑时间长或读多写少时，乐观锁通常吞吐更好。
- 库存扣减、余额变更等必须立即串行或严格判断的短操作，可以使用条件更新或合适的悲观控制。
- 选择锁策略时要明确冲突后的处理：自动重试、重新加载、提示用户、合并内容还是进入补偿。
题目解析
悲观与乐观不是框架 API 的名字，而是冲突处理哲学。悲观锁把冲突前置为等待，乐观锁把冲突后置为失败处理。若业务无法接受用户提交后被告知“请重试”，就需要在流程中设计更合适的预占或排队。
很多高并发扣减场景不必先 SELECT FOR UPDATE 再更新，一条带库存条件的 UPDATE 可以原子地判断和扣减，锁持有时间更短，也更容易扩展。
常见误区
- 把乐观锁版本号只在内存中比较，更新 SQL 没有携带旧版本条件。
- 在悲观锁事务中等待用户输入或调用外部服务，放大锁等待。