ccdi/docs/plans/2026-03-11-upload-data-account-display-design.md

上传数据主体账号展示设计文档

概述

在项目详情页的“上传数据”模块中，文件列表当前仅展示“主体名称”，未展示后端已经返回的“主体账号”。本次调整在不变更后端接口和数据库结构的前提下，为列表新增“主体账号”列，帮助用户直接核对解析出的账号信息。

需求分析

背景

• 上传数据文件列表位于项目详情页“上传数据”页签。
• 后端文件上传记录实体已包含 accountNos 字段，解析成功后会写入主体账号数据。
• 前端列表当前只渲染 enterpriseNames，导致用户无法在列表中直接查看主体账号。

目标

• 在上传数据文件列表中新增“主体账号”列。
• 直接复用现有接口返回的 accountNos 字段。
• 保持现有分页、状态、刷新逻辑不变。

方案对比

方案一：新增独立“主体账号”列

优点：

• 信息结构最清晰，主体名称和主体账号各自独立。
• 改动范围最小，只需调整前端表格模板。
• 与现有“主体名称”列保持一致，用户学习成本低。

缺点：

• 表格横向宽度略有增加。

方案二：主体名称和主体账号合并在同一列内分行展示

优点：

• 不增加表格列数。

缺点：

• 可读性下降，不利于后续排序、筛选或截图核对。
• 需要额外的模板和样式调整。

方案选择

采用方案一：新增独立“主体账号”列。

选择理由：

• 用户已经明确确认采用单独新增一列的展示方式。
• 后端字段已就绪，前端读取即用。
• 改动只落在上传数据列表模板和对应回归测试，风险最低。

数据流

1. 前端继续调用 /ccdi/file-upload/list 获取分页数据。
2. 后端返回每条上传记录的 accountNos 字段。
3. 前端在文件列表中新增“主体账号”列，读取 scope.row.accountNos。
4. 当账号为空时，展示 -，与“主体名称”列的兜底方式保持一致。

错误处理

• accountNos 为空、null 或未返回时，前端展示 -。
• 不新增请求，不改变轮询与刷新逻辑，因此不引入新的接口异常处理分支。

测试策略

• 新增前端静态回归测试，断言文件列表模板中存在 prop="accountNos" 且标签为“主体账号”。
• 按 TDD 流程先运行新测试并确认失败，再补模板代码。
• 回归执行现有上传数据列表相关静态测试，确保未误伤现有布局与分页设置。
• 执行前端生产构建，确认模板修改不影响编译。