## 事务一致性（High）

### 触发信号

在以下代码特征出现时启动此检测：
- 同一函数中存在多个数据库写操作（insert/update/delete）但无事务包裹
- 跨服务调用（HTTP/RPC/消息队列）与数据库写操作混合出现
- 缓存操作（set/del/invalidate）与数据库写操作混合出现
- 嵌套函数调用中存在多层写操作

### 判定流程

1. **识别写操作集合**：`Read` 提取函数内所有写操作（直接写操作 + 通过函数调用间接触发的写操作），标记操作目标（数据库/缓存/外部服务）
2. **检查事务覆盖**：`Read` 确认写操作是否被事务包裹：
   - 是否有事务开始（`beginTransaction`、`@Transactional`、`session.startTransaction`）
   - 事务范围是否覆盖了所有写操作
   - 事务范围是否过大（包含了不必要的读操作，延长锁持有时间）
3. **检查跨服务一致性**：对包含外部调用的流程，`Read` 检查是否有补偿机制：
   - Saga/编排模式（本地消息表、outbox pattern）
   - 失败重试 + 回滚（cancel/compensate 函数）
4. **检查缓存一致性策略**：`Read` 确认缓存与数据库的更新顺序：
   - 是否存在"先删缓存再写库"导致并发读旧值的风险
   - 是否存在"写库后未删缓存"导致数据不一致

### 证据构造

确认缺陷后，输出需包含：
- 写操作集合（所有写操作及其目标，含文件:行号）
- 事务覆盖缺口（哪些写操作未被事务保护）
- 跨服务/缓存一致性风险（补偿机制缺失或策略不当）
- 业务影响（部分提交、脏数据、缓存与DB不一致的后果）

### 排除

- 单步写操作（无需事务）
- 已使用 saga/orchestration 框架且有明确补偿逻辑
- 最终一致性场景且有对账/重试机制兜底
