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

## 概述

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

## 需求分析

### 背景

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

### 目标

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

## 方案对比

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

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

缺点：
- 表格横向宽度略有增加。

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

优点：
- 不增加表格列数。

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

## 方案选择

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

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

## 数据流

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

## 错误处理

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

## 测试策略

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