157 lines
5.9 KiB
Markdown
157 lines
5.9 KiB
Markdown
|
# Council 评估报告 — FrontendDeveloper
|
|||
|
|
|
|||
|
|
> 评估时间：2026-05-26
|
|||
|
|
> 评估人：FrontendDeveloper
|
|||
|
|
> 议题：下一步主攻方向
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一、现状评估
|
|||
|
|
|
|||
|
|
### vr-shopxo-uniapp 前端状态
|
|||
|
|
|
|||
|
|
**goods-vr-ticket 组件**：任务描述称"council draft 刚完成"，但 `~/WorkSpace/vr-shopxo-uniapp/components/` 下不存在 `goods-vr-ticket/` 目录。fork 完成但票务组件**尚未建立**。
|
|||
|
|
|
|||
|
|
**ShopXO H5 票务详情页**（ticket_detail.html，819行）：
|
|||
|
|
- 核心结构存在：规格选择、座位选择、提交购票
|
|||
|
|
- `loadSoldSeats()` 函数：TODO 注释，**未实现**（Plan.md P5 级遗留问题）
|
|||
|
|
- 观演人表单存在，submission 逻辑存在
|
|||
|
|
- 可作为过渡方案独立推进
|
|||
|
|
|
|||
|
|
**UniApp 整体状态**：
|
|||
|
|
- 基础框架已搭建（manifest.json, pages/, common/）
|
|||
|
|
- 支付、购物车、用户等基础组件已有
|
|||
|
|
- 票务相关页面和组件：**空白**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 二、发现的 3 个 P0 API Gap 对前端的影响
|
|||
|
|
|
|||
|
|
### Gap 1：seatSpecMap 后端未返回（P0 - 阻塞选座功能）
|
|||
|
|
|
|||
|
|
**影响**：选座 UI 的数据源缺失。
|
|||
|
|
- 前端无法知道「场次 → 演播室 → 分区 → 座位」层级
|
|||
|
|
- 无法渲染座位地图的规格树
|
|||
|
|
- SeatMapService 已有 `buildSeatSpecMap()`，但未注入商品详情 API
|
|||
|
|
|
|||
|
|
**前端影响评级**：🔴 **致命阻塞** — 无 seatSpecMap，选座组件完全无法开发
|
|||
|
|
|
|||
|
|
**可替代方案**：ticket_detail.html（H5）通过 PHP 直接渲染，不走 API，可绕过此 Gap
|
|||
|
|
|
|||
|
|
### Gap 2：CartSave extension_data 多座位链路未确认（P0 - 阻塞下单流程）
|
|||
|
|
|
|||
|
|
**影响**：多座位下单时观演人信息存储路径未知。
|
|||
|
|
- 前端不知道每个座位的 attendee 信息应该放在 `goods_data` 的哪个字段
|
|||
|
|
- 支付成功后的票生成逻辑依赖此链路
|
|||
|
|
|
|||
|
|
**前端影响评级**：🟠 **重度阻塞** — 单座位流程勉强可猜解，多座位完全无法开发
|
|||
|
|
|
|||
|
|
**可替代方案**：目前先按单座位模式开发，多座位延后
|
|||
|
|
|
|||
|
|
### Gap 3：QR payload 缺少 code 字段（P1 - 可变通处理）
|
|||
|
|
|
|||
|
|
**影响**：前端按文档解析 QR 会缺字段。
|
|||
|
|
- 可变通：先用 `id` 和 `g` 验过期时间，`code` 字段前端忽略
|
|||
|
|
- 后端 QR 验签不依赖前端处理，前端只需展示 QR 码
|
|||
|
|
|
|||
|
|
**前端影响评级**：🟡 **中度影响** — 不阻塞开发，可快速适配
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、前端开发路径建议
|
|||
|
|
|
|||
|
|
### 路径 A：H5 优先（无阻塞，可立即启动）
|
|||
|
|
|
|||
|
|
ticket_detail.html（H5）绕过 API Gap 价值最高：
|
|||
|
|
1. PHP 直出 HTML，选座逻辑内联，不依赖 seatSpecMap API
|
|||
|
|
2. 后端已实现 `SeatSkuService::GetGoodsViewData()`，数据已注入模板
|
|||
|
|
3. 可立即推进：`loadSoldSeats()` 实现、核销码展示、观演人表单美化
|
|||
|
|
4. 作为生产兜底：uniapp 延期时 H5 可先上线
|
|||
|
|
|
|||
|
|
**执行步骤**：
|
|||
|
|
1. 实现 `loadSoldSeats()` — 调用 seatmap API 获取已售座位，填充 soldSeats 数组
|
|||
|
|
2. 优化观演人表单 UX
|
|||
|
|
3. 核销码展示（QR + 短码）
|
|||
|
|
|
|||
|
|
### 路径 B：UniApp 选座组件开发（需等 Gap 1 解决）
|
|||
|
|
|
|||
|
|
Gap 1 解决后，UniApp 可完全独立推进：
|
|||
|
|
1. goods-vr-ticket 组件框架
|
|||
|
|
2. 商品详情页 → 票务扩展信息渲染
|
|||
|
|
3. 选座页（依赖 seatSpecMap）
|
|||
|
|
4. 购票确认页（单座位先验）
|
|||
|
|
5. 票夹页（依赖 TicketWallet API）
|
|||
|
|
6. 核销页
|
|||
|
|
|
|||
|
|
**执行步骤（Gap 1 解决后）**：
|
|||
|
|
1. goods-vr-ticket 组件基础框架
|
|||
|
|
2. 商品详情页集成 seatSpecMap
|
|||
|
|
3. 选座页 + 座位地图渲染
|
|||
|
|
4. 购票确认 + 支付
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四、ticket_detail.html 价值评估
|
|||
|
|
|
|||
|
|
**过渡方案价值：高**
|
|||
|
|
|
|||
|
|
| 维度 | 评分 | 说明 |
|
|||
|
|
|------|------|------|
|
|||
|
|
| 功能完整性 | 7/10 | 核心流程已有，loadSoldSeats 缺失 |
|
|||
|
|
| 开发成本 | 低 | PHP 直出，无需前后端分离适配 |
|
|||
|
|
| 用户体验 | 5/10 | 观演人表单粗糙，无选座动画 |
|
|||
|
|
| 独立部署 | 可 | 嵌入 ShopXO H5 模板体系 |
|
|||
|
|
|
|||
|
|
**结论**：ticket_detail.html 是 **H5 端票务的唯一载体**，必须维护好。与 UniApp 是互补关系而非竞争关系。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 五、优先级建议（前端维度）
|
|||
|
|
|
|||
|
|
### P0（必须先做）
|
|||
|
|
1. **Gap 1 确认**：后端在商品详情 API 注入 seatSpecMap，解锁 uniapp 选座开发
|
|||
|
|
2. **Gap 2 确认**：CartSave extension_data 写入 order_detail 的路径文档化
|
|||
|
|
|
|||
|
|
### P1（H5 优先，可立即执行）
|
|||
|
|
1. 实现 `loadSoldSeats()` — 调用 `/seatmap` API 获取已售座位
|
|||
|
|
2. ticket_detail.html 观演人表单 UX 优化
|
|||
|
|
3. 核销码展示组件（QR 图 + 短码）
|
|||
|
|
|
|||
|
|
### P2（Gap 1 解决后启动）
|
|||
|
|
1. UniApp goods-vr-ticket 组件框架搭建
|
|||
|
|
2. UniApp 商品详情页集成 seatSpecMap
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 六、投票
|
|||
|
|
|
|||
|
|
### 议题：下一步主攻方向
|
|||
|
|
|
|||
|
|
**投票：C — 双线并行**
|
|||
|
|
|
|||
|
|
**理由**：
|
|||
|
|
- H5 ticket_detail.html 完全独立于 API Gap，可立即推进（实现 loadSoldSeats + 表单优化）
|
|||
|
|
- UniApp 的 Gap 1（seatSpecMap）和 Gap 2（extension_data）需要后端配合，但可并行确认
|
|||
|
|
- 选项 A（纯后端优先）会让前端空等，选项 B（H5 优先）忽视 Uniapp 的长期价值
|
|||
|
|
- 选项 D（Phase 4 优先）属于锦上添花，Phase 3 核心票务流程尚未完成
|
|||
|
|
|
|||
|
|
**补充 — 对其他成员提案的评估**：
|
|||
|
|
- **BackendArchitect 选 A**：合理，Gap 1 和 Gap 2 确实是阻塞点。但纯后端优先会让前端团队空转。
|
|||
|
|
- **PerformanceBenchmarker**：seatmap API 性能影响选座体验，建议在 Phase 2 开发时做基准测试。
|
|||
|
|
- **SecurityEngineer**：支付链路安全是 P0，但与前端并行不冲突。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## FrontendDeveloper 投票
|
|||
|
|
|
|||
|
|
**议题：下一步主攻方向**
|
|||
|
|
|
|||
|
|
**投票：C — 双线并行**
|
|||
|
|
|
|||
|
|
**理由**：H5 ticket_detail.html 可无阻塞立即启动（loadSoldSeats 实现、表单优化）；UniApp 开发需等 Gap 1/2 确认，但后端可并行完成这两项。双线并行最大化资源利用率，避免前端空等。
|
|||
|
|
|
|||
|
|
**补充**：
|
|||
|
|
- 选 A（后端优先）：会损失 1-2 周前端开发时间
|
|||
|
|
- 选 B（H5 优先）：忽视 UniApp 长期价值，是过渡而非目标
|
|||
|
|
- 选 D（Phase 4 优先）：Tree API 是锦上添花，核心票务流程未完成
|