## 数据一致性缺陷（Medium）

### 触发信号

在以下代码特征出现时启动此检测：
- 缓存操作（`cache.set`、`cache.del`、`redis.set`）与数据库写操作同时存在
- 聚合数据（计数器、汇总值、统计字段）与明细数据同时存在
- 主从数据库架构下的写后读操作
- 配置/规则文件加载与运行时使用同时存在

### 判定流程

1. **识别数据同步关系**：`Read` 提取数据源（主库/明细）与数据副本（缓存/聚合/从库）的对应关系
2. **检查缓存同步**：对缓存 + 数据库写操作，`Read` 检查：
   - 写库后是否同步更新/删除缓存
   - 更新顺序是否合理（先写库后删缓存 vs 先删缓存后写库）
   - 是否存在并发窗口导致读到旧缓存
3. **检查聚合数据更新**：对聚合字段（totalCount、amount、summary），`Read` 确认：
   - 明细变更后是否同步更新聚合值
   - 聚合值是否可通过重新计算修复（对账机制）
4. **检查读写分离**：对写后立即读的场景，`Read` 确认是否有强制读主库逻辑（避免主从延迟读到旧数据）
5. **检查配置热加载**：对运行时配置，`Read` 确认变更后是否有重新加载机制

### 证据构造

确认缺陷后，输出需包含：
- 数据源与副本关系（主库↔缓存、明细↔聚合、主↔从）
- 不一致窗口（哪个操作导致不一致，何时发生）
- 业务影响（读到旧数据的后果：余额判断错误、显示过期信息、规则未生效）

### 排除

- 接受最终一致性的场景（有明确的重试/对账机制）
- 只读缓存（不会因写操作产生不一致）
- 已有 Canal/Debezium 等数据同步中间件保证一致性
