## 幂等性缺失（Critical）

### 触发信号

在以下代码特征出现时启动此检测：
- 路由 handler 中的写操作（POST/PUT/DELETE）
- 消息队列消费者（`onMessage`、`subscribe`、`handle`）
- RPC/内部服务方法中的写操作
- 包含支付、领取、投票、签到、提交等业务关键词的函数

### 判定流程

1. **定位入口**：`find_references` 追踪写操作函数的所有调用者（路由、消费者、RPC 入口），确认是否为外部可重复触发的入口
2. **检查幂等机制**：`Read` 检查操作前是否有以下任一保护：
   - 唯一约束查询（`SELECT ... WHERE unique_key = ?`，存在则跳过或返回）
   - 分布式锁（`setnx`、`acquire`、`lock`）
   - 幂等 token 验证（`idempotencyKey`、`requestId`、`dedupKey`）
3. **检查数据库兜底**：`find_definition` 查看对应数据库表/模型定义，确认是否有唯一索引可防止重复记录
4. **验证幂等 key 设计**：如存在幂等检查，`Read` 确认 key 构成：
   - 使用了业务唯一标识（订单号 + 操作类型、用户 ID + 活动ID）
   - 未使用不可靠标识（时间戳、随机数、递增序列）

### 证据构造

确认缺陷后，输出需包含：
- 触发入口（路由/消费者/RPC 方法，含文件:行号）
- 写操作链路（从入口到实际写操作的调用路径）
- 缺失的保护点（应在此处有但实际没有的检查）
- 业务影响（重复触发的后果：双花、重复消费、超发、重复操作）

### 排除

- 天然幂等的操作（查询、GET 请求）
- 数据库唯一约束已完整覆盖的字段
- 有消息去重机制的消息消费（如 Kafka consumer group + offset）
