# 项目管理列表重新分析确认与刷新设计文档

## 背景

项目管理列表页已经接入“重新分析”真实调用链路：

- 前端通过 `POST /ccdi/project/tags/rebuild` 提交项目级重打标
- 成功后提示“已开始重新分析”
- 随后调用 `getList()` 刷新列表与状态统计

当前缺口主要有两个：

1. 用户点击“重新分析”后会立即发起请求，缺少二次确认
2. 需要明确本轮仍然沿用成功后的全列表刷新策略，不做局部行补丁更新

本次需求是在现有真实调用能力之上补齐交互确认，并保持最短路径实现。

## 目标

- 为项目列表中的“重新分析”按钮增加确认弹窗
- 用户确认后才触发 `rebuildProjectTags`
- 调用成功后继续刷新项目列表与顶部状态统计
- 保持现有失败提示、按钮提交态和状态驱动展示逻辑

## 范围

### In Scope

- `ruoyi-ui/src/views/ccdiProject/index.vue` 中“重新分析”交互链路补充确认弹窗
- 沿用现有 `reAnalyzeLoadingMap` 防重复点击
- 成功后沿用 `getList()` 刷新列表和状态统计
- 取消确认、调用成功、调用失败三类前端行为收口
- 补充对应前端验证与实施文档

### Out of Scope

- 不新增后端接口
- 不新增轮询、进度提示、消息推送
- 不做局部列表行更新或乐观更新
- 不调整“重新分析”按钮显示条件
- 不变更后端重打标、风险人数计算或状态流转逻辑

## 现状分析

### 前端现状

`ruoyi-ui/src/views/ccdiProject/index.vue` 中的 `handleReAnalyze(row)` 当前流程为：

1. 判断当前项目是否处于重新分析提交中
2. 设置按钮 loading
3. 调用 `rebuildProjectTags({ projectId })`
4. 成功提示“已开始重新分析”
5. 调用 `getList()` 刷新列表
6. 失败时弹出错误提示

当前缺少用户确认步骤，因此点击即执行。

### 后端现状

后端现有 `/ccdi/project/tags/rebuild` 能力已满足本轮需求：

- 支持按 `projectId` 提交项目级重打标
- 会按既有流程更新项目状态
- 完成后由现有链路刷新结果与风险人数

因此本轮仍然只做前端交互补充，不引入后端源码改造。

## 方案选择

### 推荐方案

在列表页现有 `handleReAnalyze(row)` 中补充确认弹窗，确认后继续执行当前请求和刷新逻辑。

执行顺序：

1. 用户点击“重新分析”
2. 前端弹出确认框
3. 用户点击“确定”后再进入接口调用
4. 调用成功后提示“已开始重新分析”
5. 继续调用 `getList()` 刷新列表与统计

采用该方案的原因：

- 改动最小，符合最短路径要求
- 保持 `ProjectTable.vue` 只负责事件透传，不下沉业务交互逻辑
- 与当前页面级操作风格一致，便于复用现有 loading 和刷新逻辑

### 不采用的方案

#### 方案一：在 `ProjectTable.vue` 内直接处理确认弹窗

不采用原因：

- 表格组件职责变重
- 确认逻辑与接口逻辑分散在父子组件之间
- 不利于后续维护同类页面级操作

#### 方案二：抽象通用确认执行器

不采用原因：

- 对当前需求属于过度设计
- 只为单个按钮增加抽象，收益低于额外复杂度

## 详细设计

## 1. 交互设计

点击“重新分析”后，前端先弹出确认框，文案为：

`确认对项目“{项目名称}”重新分析吗？重新分析将重新计算项目标签。`

交互约束：

- 点击“确定”才继续发起请求
- 点击“取消”直接结束，不提示失败，不刷新列表
- 弹窗只承担确认职责，不展示额外解释信息

## 2. 数据流与状态设计

确认后的请求链路保持现有实现：

1. 读取 `projectId`
2. 设置当前项目按钮 loading
3. 调用 `rebuildProjectTags({ projectId })`
4. 成功后提示 `已开始重新分析`
5. 调用 `getList()` 刷新列表和顶部统计
6. 在 `finally` 中清理 loading

说明：

- `getList()` 已并行请求项目列表和状态统计，继续复用即可保证界面一致性
- 不做局部行状态修改，避免列表和顶部统计出现时序不一致

## 3. 异常与边界设计

### 取消确认

- 用户主动取消时，不发请求
- 不设置 loading
- 不弹错误提示

### 接口失败

- 优先展示后端返回的 `error.message`
- 无明确业务文案时，统一提示 `重新分析失败，请稍后重试`
- 失败时不刷新列表，保持当前数据稳定

### 防重复提交

- 保持单项目维度的 `reAnalyzeLoadingMap`
- 只有在用户确认后才进入 loading
- 提交结束后恢复按钮状态

## 4. 测试设计

前端验证聚焦以下场景：

1. 点击“重新分析”先出现确认弹窗
2. 点击“取消”时不发请求、不刷新列表
3. 点击“确定”后发起接口调用
4. 请求成功时提示“已开始重新分析”并刷新列表
5. 请求失败时提示失败信息，按钮恢复可点击

回归重点：

- 重新分析按钮仍只在既有状态条件下显示
- 成功刷新后项目状态和顶部统计继续由后端返回结果驱动

## 5. 后端影响说明

本轮后端无需改造。

原因：

- 现有 `/ccdi/project/tags/rebuild` 已满足提交能力
- 现有 `getList()` 刷新结果已经满足页面回显需要
- 本次变更仅增加用户确认，不改变接口语义

## 6. 风险与约束

- 本轮仍然是“提交后刷新一次”的模式，不展示任务进度
- 如果后端异步处理时间较长，用户看到项目进入处理中状态属于预期
- 方案依赖现有后端重打标链路稳定可用，不额外建设旁路能力

## 7. 本次设计结论

本次需求采用“列表页现有重新分析链路上补确认弹窗，并在成功后继续全列表刷新”的方案。

该方案满足以下要求：

- 最短路径实现
- 不引入补丁式旁路方案
- 前后端职责边界清晰
- 列表数据与统计刷新保持一致