2026-03-25 17:32:28 +08:00
|
|
|
|
# 开户信息页面改造方案对比（A / B）
|
|
|
|
|
|
|
|
|
|
|
|
## 当前决策
|
|
|
|
|
|
|
2026-03-26 11:05:38 +08:00
|
|
|
|
当前已从“优先实施方案 A”切换为：**直接按新页面重做方向落地**。
|
2026-03-25 17:32:28 +08:00
|
|
|
|
|
|
|
|
|
|
原因：
|
|
|
|
|
|
|
2026-03-26 11:05:38 +08:00
|
|
|
|
- 方案 A 的视觉结果未满足最新评审预期
|
|
|
|
|
|
- 用户已明确要求不要继续考虑原来的样式与逻辑
|
|
|
|
|
|
- 新需求强调顶部操作栏、新建/更新全新弹窗、以及更独立的用户资料展示
|
|
|
|
|
|
- 因此当前实现不再继续沿 `adapayMember.vue` 做修补，而是重写 `financial/accountUserInfo.vue`
|
|
|
|
|
|
|
|
|
|
|
|
历史上，方案 A 与方案 B 仍保留为前一轮讨论记录，供后续回看。
|
|
|
|
|
|
|
|
|
|
|
|
当前落地文档见：`docs/financial-account-user-info-rebuild.md`
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 历史决策（已废弃）
|
|
|
|
|
|
|
|
|
|
|
|
历史上曾优先考虑 **方案 A：实体卡片式重构**。
|
|
|
|
|
|
|
|
|
|
|
|
当时原因：
|
|
|
|
|
|
|
2026-03-25 17:32:28 +08:00
|
|
|
|
- 改动集中在模板结构与样式层
|
|
|
|
|
|
- 不需要改业务逻辑
|
|
|
|
|
|
- 不需要重构数据流
|
|
|
|
|
|
- 更适合当前已有组件 `adapayMember.vue`
|
|
|
|
|
|
- 回滚成本低
|
|
|
|
|
|
|
|
|
|
|
|
如果方案 A 实施后仍无法满足视觉与使用体验要求，再按 **方案 B** 重做。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 方案 A：实体卡片式重构
|
|
|
|
|
|
|
|
|
|
|
|
### 核心思路
|
|
|
|
|
|
|
|
|
|
|
|
围绕两个业务实体组织页面：
|
|
|
|
|
|
|
|
|
|
|
|
- 汇付用户
|
|
|
|
|
|
- 结算账户
|
|
|
|
|
|
|
|
|
|
|
|
并把操作动作拆到独立操作卡中。
|
|
|
|
|
|
|
|
|
|
|
|
### 页面结构
|
|
|
|
|
|
|
|
|
|
|
|
- 顶部说明区
|
|
|
|
|
|
- 汇付用户信息卡
|
|
|
|
|
|
- 用户操作卡
|
|
|
|
|
|
- 结算账户信息卡
|
|
|
|
|
|
- 结算账户操作卡
|
|
|
|
|
|
|
|
|
|
|
|
### 优点
|
|
|
|
|
|
|
|
|
|
|
|
- 改造风险低
|
|
|
|
|
|
- 适合当前组件结构
|
|
|
|
|
|
- 字段迁移成本低
|
|
|
|
|
|
- 操作区分离明确
|
|
|
|
|
|
- 易于在现有样式基础上快速落地
|
|
|
|
|
|
|
|
|
|
|
|
### 缺点
|
|
|
|
|
|
|
|
|
|
|
|
- 仍属于传统后台卡片布局
|
|
|
|
|
|
- 如果后续字段继续增加，页面长度可能上升
|
|
|
|
|
|
- 状态导向能力有限，不如更激进的重构方案强
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 方案 B：顶部摘要 + 双栏详情重做
|
|
|
|
|
|
|
|
|
|
|
|
### 核心思路
|
|
|
|
|
|
|
|
|
|
|
|
将页面重构为更强的现代后台详情页：
|
|
|
|
|
|
|
|
|
|
|
|
- 顶部摘要头部展示关键身份与状态
|
|
|
|
|
|
- 中部左右双栏分别展示汇付用户与结算账户详情
|
|
|
|
|
|
- 右侧或底部放独立操作面板
|
|
|
|
|
|
|
|
|
|
|
|
### 页面结构
|
|
|
|
|
|
|
|
|
|
|
|
- 顶部主信息区
|
|
|
|
|
|
- 页面标题
|
|
|
|
|
|
- 汇付会员ID
|
|
|
|
|
|
- 用户类型
|
|
|
|
|
|
- 审核状态
|
|
|
|
|
|
- 结算账户状态
|
|
|
|
|
|
- 主操作入口
|
|
|
|
|
|
|
|
|
|
|
|
- 左栏
|
|
|
|
|
|
- 汇付用户详情
|
|
|
|
|
|
|
|
|
|
|
|
- 右栏
|
|
|
|
|
|
- 结算账户详情
|
|
|
|
|
|
|
|
|
|
|
|
- 底部/侧栏
|
|
|
|
|
|
- 全部操作按钮区
|
|
|
|
|
|
|
|
|
|
|
|
### 优点
|
|
|
|
|
|
|
|
|
|
|
|
- 首屏状态感更强
|
|
|
|
|
|
- 信息结构更现代
|
|
|
|
|
|
- 更适合扩展更多模块信息
|
|
|
|
|
|
- 用户一眼就能看到关键状态与主操作
|
|
|
|
|
|
|
|
|
|
|
|
### 缺点
|
|
|
|
|
|
|
|
|
|
|
|
- 模板重排幅度更大
|
|
|
|
|
|
- 字段映射更复杂
|
|
|
|
|
|
- 联动验证成本更高
|
|
|
|
|
|
- 对当前组件结构侵入更深
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## A / B 对比
|
|
|
|
|
|
|
|
|
|
|
|
| 维度 | 方案 A | 方案 B |
|
|
|
|
|
|
|---|---|---|
|
|
|
|
|
|
| 改造成本 | 低 | 中高 |
|
|
|
|
|
|
| 对现有逻辑侵入度 | 低 | 中 |
|
|
|
|
|
|
| 实施速度 | 快 | 较慢 |
|
|
|
|
|
|
| 风险 | 低 | 中 |
|
|
|
|
|
|
| 视觉提升幅度 | 中高 | 高 |
|
|
|
|
|
|
| 首屏状态表达 | 中 | 高 |
|
|
|
|
|
|
| 适配当前组件 | 高 | 中 |
|
|
|
|
|
|
| 后续扩展性 | 中 | 高 |
|
|
|
|
|
|
| 回滚成本 | 低 | 中 |
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 何时从 A 切换到 B
|
|
|
|
|
|
|
|
|
|
|
|
如果方案 A 上线评审或联调后，出现以下任一情况，则启动方案 B 评估：
|
|
|
|
|
|
|
|
|
|
|
|
1. 首屏仍然不能快速识别当前开户状态
|
|
|
|
|
|
2. 主要操作按钮仍然不够聚焦，用户需要反复寻找
|
|
|
|
|
|
3. 汇付用户信息与结算账户信息虽然分卡，但仍缺少清晰主次
|
|
|
|
|
|
4. 业务方反馈页面“只是换皮”，信息查找效率没有明显改善
|
|
|
|
|
|
5. 新增字段后，方案 A 的卡片分组持续失衡
|
|
|
|
|
|
6. 页面长度明显增加，影响查看效率
|
|
|
|
|
|
|
|
|
|
|
|
## 切换建议
|
|
|
|
|
|
|
|
|
|
|
|
- 如果只是配色、间距、卡片层级不满意，继续微调方案 A
|
|
|
|
|
|
- 如果是信息架构本身无法满足需求，不再继续修补 A，直接按方案 B 重做
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 本次边界
|
|
|
|
|
|
|
|
|
|
|
|
当前版本只落地方案 A，不直接实现方案 B。
|
|
|
|
|
|
|
|
|
|
|
|
方案 B 仅作为备用重做方向保留，便于后续快速切换。
|
