# Cleaner v1.11.1 之后更新内容改进计划

本文档基于 `v1.11.1..v1.12.3` 区间内已完成的前端审查结果整理而成，目标不是重复提交记录，而是为后续实现人员提供一份可以直接排期和落地的改进路线图。计划范围仅覆盖 Cleaner 相关前端改进，不扩展到主进程 DAO、IPC 或数据库结构重构。

## 1. 背景与范围

本计划覆盖 `v1.11.1` 之后到当前最新版本 `v1.12.3` 的 Cleaner 前端相关更新，重点关注以下变化：

- 新增 Cleaner 操作历史弹窗
- 用数据库持久化替代原有 Markdown 报告查看路径
- 为执行结果补充失败与不确定删除统计
- 引入 `React.lazy` 和 `BatchItem` 拆分来降低页面负担

本次计划的核心目标是：

- 先修复当前历史弹窗与执行结果展示中的稳定性问题
- 再优化首屏加载和复杂列表交互性能
- 最后补齐长期可维护性和可扩展性基础

默认审查区间固定为 `v1.11.1..v1.12.3`，默认文档语言为中文，默认落点为 `docs/plans/`。

## 2. 当前状态总结

这轮更新已经做对了几件重要的事情：

- Cleaner 历史记录已经完成数据库化，前端不再依赖旧的 Markdown 报告浏览流
- `CleanerOperationHistoryModal` 被独立成单独组件，并通过 `BatchItem` 局部拆分降低兄弟节点联动重渲染
- `CleanerPage` 已经开始使用 `React.lazy` 引入历史弹窗与执行报告相关组件
- `ExecutionReportDialog` 已经补充 `materialsFailed` 和 `uncertainDeletions` 的展示能力

这些改动说明整体方向是正确的，但从 React 最佳实践和后续维护成本看，当前实现仍然存在几个明确的改进空间：异步缓存策略不够稳、按需加载没有完全生效、复杂列表的扩展能力有限、前端回归保护不足。

## 3. 主要改进项

### P0 立刻修

#### 3.1 修正历史详情与物料详情的缓存时机

问题：

- 当前历史批次详情和物料详情会在请求发起前就标记为“已加载”
- 如果首次请求失败，后续再次展开不会重试，用户会长期看到空详情或误导性空状态

目标：

- 只在请求成功后写入缓存
- 失败后允许再次展开重新请求
- 在 UI 上保留现有交互风格，不做视觉重设计

建议方向：

- 将详情加载状态拆成 `idle / loading / success / error`
- `detailsLoadedRef` 和 `loadedMaterialsRef` 只在成功后更新
- 对失败场景提供自然重试路径，优先采用“再次展开即重试”的方式

预期收益：

- 避免瞬时请求失败被错误地永久缓存
- 提高历史查看功能的稳定性和用户信任感

#### 3.2 将 Cleaner 历史弹窗改成真正条件挂载

问题：

- 当前 `CleanerPage` 虽然使用了 `React.lazy`，但历史弹窗组件仍然会在页面渲染时被挂入树中
- 这会导致对应 chunk 仍在首屏阶段就被加载，未达到真正按需加载的效果

目标：

- 历史弹窗只在用户打开时才参与渲染和加载
- 避免进入 Cleaner 页面就提前下载历史功能代码

建议方向：

- 采用条件渲染而不是仅保留 `isOpen` 控制
- 延续当前交互样式和打开方式，不调整页面布局

预期收益：

- 降低 Cleaner 页面的首屏负担
- 更符合 `bundle-conditional` 类最佳实践

#### 3.3 补最小前端回归测试

问题：

- 本轮新增了历史弹窗、异步详情展开和执行结果增强，但前端侧缺少对应测试保护

目标：

- 为关键行为建立最小可行回归测试
- 优先补组件/行为测试，不新增端到端测试要求

建议方向：

- 覆盖历史弹窗未打开时不触发懒加载模块请求
- 覆盖批次详情和物料详情首次失败后再次展开可重试
- 覆盖管理员筛选切换后请求参数与结果一致

预期收益：

- 降低后续修复和优化时的回归风险
- 为后续分页、交互优化提供安全网

### P1 本周优化

#### 3.4 为历史列表增加分页能力

问题：

- 当前历史列表和明细表格按全量数据渲染，随着批次数量、订单数量和物料数量增加，性能风险会上升

目标：

- 让历史列表在数据增长后仍保持可接受的打开和滚动体验

建议方向：

- 默认优先采用分页，不先引入虚拟列表库
- 先做批次列表分页，再评估是否需要对订单或物料明细做进一步优化

预期收益：

- 控制渲染体量
- 降低复杂列表在中等数据规模下的卡顿风险

#### 3.5 管理员筛选切换使用 `startTransition`

问题：

- 管理员切换用户筛选时会立即触发批次列表刷新，后续数据量增长后可能影响点击反馈

目标：

- 保持筛选按钮点击响应流畅
- 将非紧急更新降级处理

建议方向：

- 将筛选触发的列表刷新包装到 `startTransition`
- 保持现有筛选交互模型不变

预期收益：

- 降低筛选切换时的阻塞感
- 更符合 React 对非紧急更新的建议用法

#### 3.6 收敛重复派生计算

问题：

- 当前实现中存在多处基于 `orders` 和 `currentAttempt` 的重复 `filter/map`
- 数据规模扩大后，这些重复遍历会逐步放大渲染成本

目标：

- 让渲染中的数据派生更集中、更可读

建议方向：

- 将当前 attempt 对应订单集合收敛成单一派生结果
- 复制列内容等行为复用同一份派生数据

预期收益：

- 降低不必要的重复计算
- 让 `BatchItem` 的渲染路径更容易维护

#### 3.7 优化执行报告的结果语义

问题：

- 当前执行报告的标题和成功态仍主要依赖 `errors`
- 当存在 `materialsFailed` 或 `uncertainDeletions` 时，结果表达仍可能显得过于乐观

目标：

- 让执行结果清楚区分成功、部分成功、失败、需人工确认

建议方向：

- 重新定义结果态判定优先级
- 在不重做 UI 视觉设计的前提下，优化标题、说明文案和结果提示条

预期收益：

- 降低误判执行结果的风险
- 让失败和不确定删除场景更容易被用户注意到

### P2 后续演进

#### 3.8 统一状态映射定义

问题：

- 当前状态的 label、icon、style 已有集中趋势，但仍是组件内局部定义
- 后续新增状态时容易出现展示不一致

目标：

- 用统一的受类型约束的映射管理状态展示

建议方向：

- 抽离共享状态映射
- 覆盖 batch、execution、order、material 这几类状态展示

预期收益：

- 降低重复定义
- 提高新增状态时的一致性和可维护性

#### 3.9 补无障碍语义

问题：

- 当前批次展开和订单展开更多依赖点击容器，语义和键盘可达性还有提升空间

目标：

- 让复杂历史弹窗具备更清晰的交互语义

建议方向：

- 使用真实按钮作为展开触发器
- 增加 `aria-expanded`、`aria-controls` 等属性

预期收益：

- 提升键盘交互和屏幕阅读器兼容性
- 为后续复杂交互维护提供更稳定语义基础

#### 3.10 规划历史查询的扩展能力

问题：

- 当前查询能力主要围绕固定数量批次列表和基础筛选
- 如果历史功能继续增强，前端会越来越依赖更丰富的查询条件

目标：

- 为后续历史功能演进预留明确方向

建议方向：

- 预留时间范围筛选
- 预留状态筛选
- 延续服务端分页方向，而不是继续扩大前端一次性加载量

预期收益：

- 让后续功能迭代有稳定扩展路径
- 避免复杂度持续堆积在当前单一弹窗实现中

## 4. 推荐执行顺序

建议按以下顺序推进：

1. 先修 `P0`，优先处理缓存时机错误和按需加载未完全生效的问题
2. 在 `P0` 修复完成后补最小前端回归测试，锁住关键行为
3. 再做 `P1`，先分页，再处理 `startTransition` 和重复派生计算
4. 最后进入 `P2`，统一状态映射、补无障碍语义，并规划历史查询扩展能力

这个顺序的原则是：先修稳定性，再做性能，再做长期演进。

## 5. 完成标准

本计划相关改进完成后，至少应满足以下验收标准：

- 历史弹窗未打开时，不触发对应懒加载模块请求
- 批次详情或物料详情首次请求失败后，用户再次展开可重新请求
- 用户筛选切换后，列表数据与筛选条件一致
- 执行报告在存在 `materialsFailed` 或 `uncertainDeletions` 时，不再展示为完全成功
- `npm run typecheck` 通过
- 相关前端测试通过
- Cleaner 页面关键路径手工验证通过，包括：
  - 打开历史弹窗
  - 展开批次详情
  - 展开订单物料详情
  - 切换管理员筛选
  - 查看执行结果提示

## 6. 默认方案与实施约束

为避免后续实现阶段再次做不必要决策，本计划固定以下默认方案：

- 历史列表优先采用分页，不先引入虚拟列表库
- 历史弹窗继续保留现有交互样式，不做视觉重设计
- 测试优先补组件/行为测试，不新增端到端测试要求
- 本计划只覆盖 Cleaner 相关前端改进，不扩展到主进程 DAO、IPC、数据库结构重构

如果后续版本继续围绕 Cleaner 历史功能扩展，可以在本计划基础上继续追加更细的实施文档，但不应改变本计划中 `P0 / P1 / P2` 的优先级顺序。
