设计涉疑交易筛选一致性优化

docs/plans/frontend/2026-07-16-suspicious-transaction-filter-consistency-frontend-implementation.md

@@ -0,0 +1,25 @@
+# 涉疑交易明细筛选一致性前端实施计划
+
+## 目标
+
+- 防止旧请求和父页面数据更新覆盖当前筛选结果。
+- 列表直接使用后端返回的筛选后标签，不再逐条请求流水详情。
+- 详情和风险明细导出携带当前筛选条件。
+
+## 实施步骤
+
+1. 将 `sectionData` 监听改为只在项目 ID 变化时初始化筛选和首屏数据，父页面同项目更新不重置本地筛选状态。
+2. 为模型和预警类型变化统一增加筛选状态重置：清空列表、总数、详情和筛选范围缓存，并使旧请求失效。
+3. 增加涉疑交易请求序号；API 返回、异常处理和加载状态只允许最新请求修改。
+4. 删除列表 `hydrateSuspiciousRows` 的逐条详情补全，直接规范化后端返回的 `hitTags`。
+5. 流水详情请求携带当前 `modelCode` 和 `suspiciousType`，详情缓存键包含筛选范围。
+6. 风险明细导出携带当前涉疑交易筛选条件。
+
+## 测试
+
+- 静态单测：筛选参数透传、列表不再逐条详情补全、请求序号保护、父数据不覆盖。
+- 竞态测试：旧请求晚返回时保持最新结果。
+- 页面测试：员工疑似赌博、员工大额交易、外部人员大额交易、全部模型来回切换。
+- 网络检查：列表加载只发一条涉疑交易列表请求，不发当前页逐条详情请求。
+- 详情与导出检查：标签与当前筛选一致。
+