## 并发业务冲突（High）

### 触发信号

在以下代码特征出现时启动此检测：
- 读-改-写序列（先查询再修改再保存，如 `get → calculate → save`）
- "不存在则创建"模式（`if (!exists) { create }`）
- 库存/余额/配额等可耗尽资源的扣减操作
- 同一字段被多个来源更新的场景

### 判定流程

1. **识别读-改-写序列**：`Read` 提取函数中的查询操作和写操作，标记是否存在"读取值 → 基于值计算 → 写回"的模式
2. **检查并发保护**：对读-改-写序列，`Read` 检查是否有以下任一保护：
   - 悲观锁（`SELECT ... FOR UPDATE`、`LOCK TABLE`）
   - 乐观锁（`UPDATE ... WHERE version = ?`，且 version 在读取时已获取）
   - 原子操作（`INCREMENT`、`DECREMENT`、`compareAndSet`）
   - 分布式锁（仅适用于非数据库场景）
3. **检查"不存在则创建"兜底**：`Read` 确认该模式是否有：
   - 数据库唯一约束防止并发重复创建
   - 分布式锁防止竞态
4. **评估竞争风险**：`find_references` 检查相关函数的调用者是否为高并发入口（HTTP handler、消息消费者），确认竞争风险等级

### 证据构造

确认缺陷后，输出需包含：
- 读-改-写序列（查询位置、计算逻辑、写回位置，含文件:行号）
- 并发场景描述（哪些并发请求会触发竞争）
- 缺失的保护措施（应有但实际没有的锁/约束）
- 业务影响（超卖、超额分配、重复创建的具体后果）

### 排除

- 低频操作（管理员后台配置、定时任务）
- 已有数据库唯一约束完整防止重复创建
- 操作频率极低且无并发可能的数据初始化
