Dapper本身不内置乐观锁机制，但能完美配合乐观锁逻辑实现并发安全——关键在于你如何设计SQL、管理版本字段，以及控制更新条件。
加一个版本号字段是前提
数据库表里必须有类似 Version 或 RowVersion 的整数或时间戳字段，每次更新时递增。比如：
- ALTER TABLE Products ADD Version INT NOT NULL DEFAULT 1;
- 实体类中对应属性要映射上，Dapper会自动绑定参数（字段名匹配即可）
- 查询时务必把版本号一起查出来：SELECT Id, Name, Stock, Version FROM Products WHERE Id = @Id
UPDATE语句必须带版本校验
不能直接 UPDATE ... SET Stock = @NewStock，而要加上 WHERE Version = @OldVersion 条件：
- UPDATE Products SET Stock = @Stock, Version = Version + 1 WHERE Id = @Id AND Version = @Version
- 执行后检查 影响行数：如果返回 0，说明版本已变，发生并发冲突
- Dapper的
Execute()方法直接返回受影响行数，无需额外解析
冲突后重试要可控
检测到更新失败（行数为0）时，不能无限重试。建议用简单策略兜底：
- 最多重试 2～3 次，避免雪崩
- 每次重试前重新
SELECT最新数据和版本号 - 可加入短延迟（如
Task.Delay(10)），缓解瞬时竞争 - 若仍失败，抛出业务异常（如
OptimisticConcurrencyException），交由上层提示用户“数据已被他人修改”
不依赖框架也能写得干净
Dapper轻量的特点反而利于手动控制乐观锁流程。例如一个库存扣减方法可以这样组织：
- 先查：获取当前
Stock和Version - 判断是否足够：不够就直接返回失败
- 再更新：带版本条件的 UPDATE，检查返回值
- 失败则重查+重算+重试，而不是交给ORM自动处理
基本上就这些。没有魔法，靠的是SQL严谨性和逻辑闭环。
