# 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 是锦上添花，核心票务流程未完成