400 lines
10 KiB
Markdown
400 lines
10 KiB
Markdown
# 结果总览项目分析弹窗真实详情设计
|
||
|
||
**日期**: 2026-03-25
|
||
**模块**: 初核项目详情 - 结果总览
|
||
**作者**: Codex
|
||
**状态**: 已确认
|
||
|
||
## 1. 概述
|
||
|
||
现有 `结果总览` 页的“项目分析”弹窗已完成前端壳子，但弹窗内容仍依赖本地静态拼装：
|
||
|
||
- 弹窗宽度偏窄，流水类信息阅读空间不足
|
||
- `异常明细` 仍使用本地 mock 数据
|
||
- 左侧 `人员基础信息` 未读取员工信息表真实数据
|
||
- `命中模型摘要` 当前由弹窗内部拼装，和入口上下文绑定不清晰
|
||
|
||
本次设计只解决上述真实详情接入问题，目标是在保留现有弹窗结构的前提下，把“查看详情”改造成可查询真实人员详情和真实异常明细的工作台弹窗。
|
||
|
||
## 2. 设计目标
|
||
|
||
### 2.1 包含内容
|
||
|
||
- 调整 `项目分析` 弹窗宽度
|
||
- 新增结果总览详情专用后端接口
|
||
- `人员基础信息` 改为读取员工信息表真实数据
|
||
- `异常明细` 改为调用真实接口返回
|
||
- `命中模型摘要` 改为由外部列表透传进入弹窗
|
||
- `异常明细` 中：
|
||
- 流水维度异常按表格展示
|
||
- `object` 类型异常标签按摘要卡展示
|
||
|
||
### 2.2 不包含内容
|
||
|
||
- 不改造项目详情页路由和导航
|
||
- 不扩展弹窗内 `资产分析 / 征信摘要 / 关系图谱 / 资金流向` 的真实接口
|
||
- 不把弹窗拆成新页面
|
||
- 不向现有列表接口塞入详情字段
|
||
- 不增加兼容分支、降级分支或补丁式旁路方案
|
||
|
||
## 3. 当前上下文
|
||
|
||
当前相关前端文件：
|
||
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisDialog.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisSidebar.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisAbnormalTab.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/preliminaryCheck.mock.js`
|
||
|
||
当前相关后端文件：
|
||
|
||
- `ccdi-project/src/main/java/com/ruoyi/ccdi/project/controller/CcdiProjectOverviewController.java`
|
||
- `ccdi-project/src/main/java/com/ruoyi/ccdi/project/service/impl/CcdiProjectOverviewServiceImpl.java`
|
||
- `ccdi-project/src/main/java/com/ruoyi/ccdi/project/controller/CcdiBankStatementController.java`
|
||
- `ccdi-project/src/main/java/com/ruoyi/ccdi/project/service/impl/CcdiBankStatementServiceImpl.java`
|
||
- `ccdi-info-collection/src/main/java/com/ruoyi/info/collection/domain/CcdiBaseStaff.java`
|
||
|
||
当前问题：
|
||
|
||
1. 弹窗宽度固定为 `1280px`，流水类表格列空间不足
|
||
2. 异常明细页仍是“当前行数据 + 静态模板”拼装
|
||
3. 左侧基础信息没有使用员工主数据
|
||
4. 结果总览后端尚无详情接口，只有列表类接口
|
||
|
||
## 4. 方案比较
|
||
|
||
### 4.1 方案 A：新增结果总览详情专用接口
|
||
|
||
做法：
|
||
|
||
- 在结果总览控制器下新增详情接口
|
||
- 一次返回人员基础信息和异常明细
|
||
- 前端弹窗只负责展示和状态管理
|
||
|
||
优点：
|
||
|
||
- 接口职责清晰，列表与详情边界明确
|
||
- 前端不需要并发拼多个真实接口
|
||
- 后续继续扩展其他页签时可以沿用同一详情链路
|
||
|
||
缺点：
|
||
|
||
- 需要补一条新的后端查询链路
|
||
|
||
### 4.2 方案 B：前端并发查询员工信息和异常明细
|
||
|
||
做法：
|
||
|
||
- 员工信息单独查员工模块
|
||
- 异常明细单独查结果总览模块
|
||
- 前端弹窗自行合并两份结果
|
||
|
||
优点：
|
||
|
||
- 单个接口改动较小
|
||
|
||
缺点：
|
||
|
||
- 前端状态更散
|
||
- 打开弹窗时更容易出现半成功半失败
|
||
- 员工信息与详情上下文容易失去统一入口
|
||
|
||
### 4.3 方案 C：把详情字段塞回现有列表接口
|
||
|
||
做法：
|
||
|
||
- 在风险人员总览和模型人员列表接口中直接追加详情字段
|
||
- 弹窗尽量少请求或不请求
|
||
|
||
优点：
|
||
|
||
- 表面改动快
|
||
|
||
缺点：
|
||
|
||
- 列表接口职责被拉坏
|
||
- 数据量被放大
|
||
- 不符合“查看详情单独获取真实信息”的语义
|
||
|
||
### 4.4 结论
|
||
|
||
采用 **方案 A**。
|
||
|
||
原因：
|
||
|
||
1. 最符合“详情数据独立获取”的业务语义
|
||
2. 不破坏现有结果总览列表接口职责
|
||
3. 前后端边界最稳定，后续扩展成本最低
|
||
|
||
## 5. 总体设计
|
||
|
||
### 5.1 打开入口
|
||
|
||
以下两个入口继续共用同一个 `项目分析` 弹窗：
|
||
|
||
1. `风险人员总览`
|
||
2. `命中模型涉及人员列表`
|
||
|
||
### 5.2 打开流程
|
||
|
||
1. 用户点击列表中的 `查看详情`
|
||
2. 前端立即打开弹窗，默认进入 `异常明细`
|
||
3. 前端将入口行中的 `命中模型摘要` 直接透传给弹窗
|
||
4. 前端发起结果总览详情接口请求
|
||
5. 接口返回后刷新左侧真实人员基础信息和右侧真实异常明细
|
||
|
||
### 5.3 数据来源边界
|
||
|
||
- `人员基础信息`：后端详情接口内部查询员工信息表 `ccdi_base_staff`
|
||
- `命中模型摘要`：由外部列表透传，不由详情接口负责
|
||
- `异常明细`：由详情接口统一返回真实信息
|
||
|
||
## 6. 后端设计
|
||
|
||
### 6.1 接口设计
|
||
|
||
建议在结果总览控制器下新增接口：
|
||
|
||
- `GET /ccdi/project/overview/person-analysis/detail`
|
||
|
||
入参：
|
||
|
||
- `projectId`
|
||
- `staffIdCard`
|
||
|
||
只保留这两个字段，避免把外层上下文和真实详情查询混在一起。
|
||
|
||
### 6.2 返回结构
|
||
|
||
返回对象建议收口为：
|
||
|
||
```json
|
||
{
|
||
"basicInfo": {
|
||
"name": "张三",
|
||
"idNo": "3301********1234",
|
||
"staffCode": "A1023",
|
||
"department": "信息二部",
|
||
"phone": "138****0000",
|
||
"riskLevel": "高风险",
|
||
"projectName": "项目A"
|
||
},
|
||
"abnormalDetail": {
|
||
"groups": [
|
||
{
|
||
"groupCode": "BANK_STATEMENT",
|
||
"groupName": "流水异常明细",
|
||
"groupType": "BANK_STATEMENT",
|
||
"records": []
|
||
},
|
||
{
|
||
"groupCode": "RELATED_OBJECT",
|
||
"groupName": "异常对象摘要",
|
||
"groupType": "OBJECT",
|
||
"records": []
|
||
}
|
||
]
|
||
}
|
||
}
|
||
```
|
||
|
||
### 6.3 人员基础信息查询
|
||
|
||
人员基础信息统一从员工信息表读取：
|
||
|
||
- 主表：`ccdi_base_staff`
|
||
- 关联补充：
|
||
- 部门名称
|
||
- 当前项目名称
|
||
- 结果总览员工结果表中的风险等级
|
||
|
||
查询口径：
|
||
|
||
1. `staffIdCard` 作为员工识别主键
|
||
2. 员工表查不到时，仍允许返回异常明细，但 `basicInfo` 中对应字段为空
|
||
3. 不新增前端二次查员工接口
|
||
|
||
### 6.4 异常明细查询
|
||
|
||
异常明细统一组织为 `groups` 列表，每组包含：
|
||
|
||
- `groupCode`
|
||
- `groupName`
|
||
- `groupType`
|
||
- `records`
|
||
|
||
本轮只支持两种 `groupType`：
|
||
|
||
- `BANK_STATEMENT`
|
||
- `OBJECT`
|
||
|
||
### 6.5 流水维度异常
|
||
|
||
`BANK_STATEMENT` 类型的 `records` 直接按流水明细展示口径返回，字段尽量贴近现有流水查询 VO：
|
||
|
||
- `bankStatementId`
|
||
- `trxDate`
|
||
- `leAccountNo`
|
||
- `leAccountName`
|
||
- `customerAccountName`
|
||
- `customerAccountNo`
|
||
- `userMemo`
|
||
- `cashType`
|
||
- `displayAmount`
|
||
- `hitTags`
|
||
|
||
要求：
|
||
|
||
1. 展示口径与现有“流水明细查询”页面保持一致
|
||
2. 命中标签继续沿用当前流水标签结果表查询方式
|
||
3. 不再为弹窗单独造一套与流水查询不一致的字段命名
|
||
|
||
### 6.6 `OBJECT` 类型异常
|
||
|
||
`OBJECT` 类型记录用于卡片展示，返回摘要结构，不返回整对象平铺结构。
|
||
|
||
每条记录建议包含：
|
||
|
||
- `title`
|
||
- `subtitle`
|
||
- `riskTags`
|
||
- `summary`
|
||
- `extraFields`
|
||
|
||
其中：
|
||
|
||
- `title`：对象主识别名称
|
||
- `subtitle`：对象类型、关系或补充说明
|
||
- `riskTags`：异常标签数组
|
||
- `summary`：一句话摘要
|
||
- `extraFields`：最多 2 到 4 个补充字段
|
||
|
||
这样可满足“卡片展示核心信息”的要求，避免对象型数据在弹窗内变成字段堆叠。
|
||
|
||
### 6.7 查询范围
|
||
|
||
无论从哪个入口进入，详情接口都返回“该人员在当前项目下的全部异常明细”。
|
||
|
||
即使入口来自 `命中模型涉及人员列表`，也：
|
||
|
||
- 顶部继续显示当前命中模型上下文
|
||
- 但异常明细不按当前模型过滤
|
||
|
||
## 7. 前端设计
|
||
|
||
### 7.1 弹窗尺寸
|
||
|
||
`ProjectAnalysisDialog.vue` 中弹窗宽度从 `1280px` 调整为 `1440px`。
|
||
|
||
布局建议：
|
||
|
||
- 左侧侧栏宽度从 `320px` 微调到 `340px`
|
||
- 右侧主工作区尽量为流水表格腾出空间
|
||
|
||
### 7.2 侧栏展示
|
||
|
||
左侧侧栏拆成两类来源：
|
||
|
||
1. 真实详情接口返回：
|
||
- 姓名
|
||
- 身份证号
|
||
- 工号
|
||
- 部门
|
||
- 联系方式
|
||
- 风险等级
|
||
- 所属项目
|
||
2. 外层透传：
|
||
- 命中模型数
|
||
- 当前命中模型
|
||
- 核心异常标签
|
||
|
||
`排查记录摘要` 本轮没有真实口径，继续保留占位文案，不新增接口。
|
||
|
||
### 7.3 异常明细渲染
|
||
|
||
`ProjectAnalysisAbnormalTab.vue` 改为分组渲染：
|
||
|
||
1. `BANK_STATEMENT`
|
||
- 渲染表格
|
||
- 表头风格参考 `DetailQuery.vue`
|
||
2. `OBJECT`
|
||
- 渲染摘要卡列表
|
||
- 每张卡只展示核心字段
|
||
|
||
空数据处理：
|
||
|
||
- 空分组不展示
|
||
- 全部为空时展示统一空态
|
||
|
||
### 7.4 Mock 替换策略
|
||
|
||
`preliminaryCheck.mock.js` 中的弹窗数据构造逻辑不再承担真实详情拼装职责。
|
||
|
||
保留内容：
|
||
|
||
- 占位页签文案
|
||
- 少量默认结构常量
|
||
|
||
移出内容：
|
||
|
||
- `basicInfo`
|
||
- `abnormalDetail`
|
||
|
||
这两部分改为完全由真实接口驱动。
|
||
|
||
## 8. 状态与交互设计
|
||
|
||
### 8.1 打开时机
|
||
|
||
点击后立即打开弹窗，不等待接口先返回。
|
||
|
||
### 8.2 加载态
|
||
|
||
- 左侧真实基础信息未返回前显示骨架或 `-`
|
||
- 右侧 `异常明细` 区域显示 `v-loading` 或骨架态
|
||
- 外层透传的命中模型摘要可先展示
|
||
|
||
### 8.3 错误态
|
||
|
||
如果详情接口失败：
|
||
|
||
- 弹窗保持打开
|
||
- 右侧异常明细区域展示错误提示和重试入口
|
||
- 左侧命中模型摘要继续保留
|
||
- 未获取到的基础信息字段显示为空
|
||
|
||
### 8.4 页签行为
|
||
|
||
- 默认页签始终为 `异常明细`
|
||
- 关闭弹窗后再次打开，仍回到 `异常明细`
|
||
- 其余 4 个页签继续展示占位内容，不在本次扩展真实数据
|
||
|
||
## 9. 测试与验收要点
|
||
|
||
### 9.1 后端验收
|
||
|
||
1. 详情接口可根据 `projectId + staffIdCard` 返回真实详情
|
||
2. 人员基础信息来源于员工信息表
|
||
3. 流水型异常可返回真实流水记录和命中标签
|
||
4. `OBJECT` 类型异常可返回摘要卡结构
|
||
5. 从模型人员列表进入时，异常明细仍返回该人的全部异常
|
||
|
||
### 9.2 前端验收
|
||
|
||
1. 弹窗宽度明显加宽，流水表格可读性提升
|
||
2. 点击 `查看详情` 后弹窗立即打开
|
||
3. 左侧命中模型摘要由外层透传
|
||
4. 左侧人员基础信息展示真实数据
|
||
5. 流水型异常按表格展示
|
||
6. `OBJECT` 类型异常按摘要卡展示
|
||
7. 详情请求失败时弹窗不关闭，可重试
|
||
|
||
## 10. 结论
|
||
|
||
本方案采用“**结果总览新增专用详情接口 + 前端弹窗按类型渲染真实数据**”的最短路径实现：
|
||
|
||
1. 不污染现有列表接口
|
||
2. 不让前端并发拼多条真实接口
|
||
3. 人员基础信息、异常明细、入口模型摘要三类职责边界清晰
|
||
4. 既满足本轮真实详情接入，也为后续逐步接通更多页签留出稳定扩展位
|