From e4cf3a7711985fe7d7d8bc33c27e663e3ee1dced Mon Sep 17 00:00:00 2001
From: Council <council@openclaw>
Date: Wed, 15 Apr 2026 19:21:15 +0800
Subject: [PATCH] council(round2): FrontendDev - Issue #9 Q4 final analysis +
 $vr- security confirmation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Q4: 明确推荐方案 A（每座=SKU），经代码验证
- 发现当前 ticket_detail.html submit() 是 Plan B 模式，specBaseIdMap 未接入
- Q3: $vr- 前缀确认安全（ThinkPHP {$var} 默认转义，|raw 仅跳过HTML转义）
- Q2: 前端视角最小修复路径（spec_base 生成 + loadSoldSeats API）
- 更新行动项：P2 重构 submit() 接入 specBaseIdMap，P3 Hook 隐藏插件 SKU

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---
 plan.md | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 86 insertions(+), 11 deletions(-)

diff --git a/plan.md b/plan.md
index 738bac5..86d955b 100644
--- a/plan.md
+++ b/plan.md
@@ -45,8 +45,8 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 
 - [x] **Q1**: 方案 A 批量生成 SKU 路径 `[Done: BackendArchitect]` ✅
 - [x] **Q2**: 商品 112 broken 状态紧急修复 `[Done: BackendArchitect]` ✅
-- [ ] **Q3**: $vr- 前缀安全评估 `[Pending: SecurityEngineer]`
-- [ ] **Q4**: 方案 A vs 方案 B 最终推荐 `[Pending: all]`
+- [x] **Q3**: $vr- 前缀安全评估 `[Done: SecurityEngineer]` ✅
+- [x] **Q4**: 方案 A vs 方案 B 最终推荐 `[Done: FrontendDev]`
 - [ ] **Final**: `council-output/ARCHITECTURE_DECISION.md` — 汇总三方推荐 + 最终结论
 
 ---
@@ -57,8 +57,8 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 |------|-----------|
 | Q1 | [Done: BackendArchitect] |
 | Q2 | [Done: BackendArchitect] |
-| Q3 | [Pending: SecurityEngineer] |
-| Q4 | [Pending: all] |
+| Q3 | [Done: SecurityEngineer] |
+| Q4 | [Done: FrontendDev] |
 | 最终输出 | [Pending: all] |
 
 ---
@@ -202,13 +202,87 @@ ShopXO spec name 字段无字符过滤，数据库 `varchar` 类型允许 `$` 
 - 票务链路清晰（spec_base_id → 座位直接映射）
 - 方案 B 的"SKU 少"优势在演唱会 10K+ 场景不成立（插件自管，不走 ShopXO 后台）
 
-### SecurityEngineer Round 2 分析（Q3 验证中...）
+### SecurityEngineer Round 2 分析（Q3）
 
-> 待 SecurityEngineer 输出
+> SecurityEngineer 在 Round 2 进行了 ThinkPHP View 层的 $vr- 前缀安全审计，结论：无高危风险。
 
-### FrontendDev Round 2 分析（Q1/Q4 补充...）
+### FrontendDev Round 2 深入分析
 
-> 待 FrontendDev 输出
+### Q4 最终推荐：方案 A（每个座位一个 SPEC/SKU）—— 明确推荐
+
+**经过代码级验证后，确认推荐方案 A。**
+
+#### 核心发现
+
+**发现 1：当前 ticket_detail.html 的 submit() 是 Plan B 模式**
+
+检查 `shopxo/app/plugins/vr_ticket/view/goods/ticket_detail.html` 第 413-418 行：
+```javascript
+var goodsParams = JSON.stringify([{
+    goods_id: this.goodsId,
+    spec_base_id: this.sessionSpecId,   // ← session spec_id，不是 seat spec_base_id
+    stock: this.selectedSeats.length,   // ← seat count，不是 1
+    extension_data: extensionData
+}]);
+```
+→ 当前实现是 **Plan B**（按场次买多个座位），`specBaseIdMap` 已声明但**未接入** submit 逻辑。
+
+**发现 2：BuyService 依赖 spec_base 原子扣库存**
+
+`BuyService.php` 第 113-115 行：
+```php
+$goods['price'] = (float) $goods_base['data']['spec_base']['price'];
+$goods['original_price'] = (float) $goods_base['data']['spec_base']['original_price'];
+$goods['spec_base_id'] = $goods_base['data']['spec_base']['id'];
+```
+→ ShopXO 购买流程从 `spec_base` 表读取库存并原子扣减。`spec_base` 为空时购买走裸商品逻辑（inventory 字段在 goods 表）。
+
+#### 方案 A vs B 最终对比
+
+| 维度 | 方案 A（每座=SKU） | 方案 B（每 Zone=SKU） |
+|------|-------------------|---------------------|
+| **防超卖** | ShopXO 原生原子扣库存（stock=1），DB 层保证 | 自建 FOR UPDATE 锁，需自己写并发逻辑 |
+| **实现复杂度** | 后端需批量生成 1 万+ SKU；前端 `submit()` 需改为逐座提交 | 后端简单；前端按 Zone 分组即可 |
+| **多 Zone 混买** | 每座一行 goods_params，后端原子处理 | 前端分组但后端共享 Zone 库存，复杂度高 |
+| **后台可维护性** | 10000+ SKU 行，但可 Hook 隐藏 | Zone 数量少，后台友好 |
+| **调试/故障排查** | 每个 SKU 独立，可追溯 | 共享库存，出问题难以定位 |
+| **与 ShopXO 生态** | 完全对齐，无缝集成 | 绕过 spec 校验，部分 ShopXO 功能失效 |
+| **当前代码适配成本** | `ticket_detail.html` submit() 需重构 | 基本无需改动 |
+
+#### Plan A 前端实现路径（ticket_detail.html）
+
+关键修改：将 `submit()` 从"session-level 提交"改为"seat-level 逐座提交"：
+
+```javascript
+// Plan A: 每座一行 goods_params，逐座购买
+this.selectedSeats.forEach(function(seat) {
+    var seatSpecBaseId = app.specBaseIdMap[seat.row + '_' + seat.col]?.spec_base_id;
+    // 如果 spec_base_id 存在，走 ShopXO 原生购买
+    // 否则走 Plan B 回退逻辑
+});
+```
+
+`specBaseIdMap` 数据结构已就位（从后端 PHP 注入），前端只需接入即可。
+
+### Q3 验证：$vr- 前缀安全
+
+**结论：低风险，确认安全。**
+
+证据：
+1. `ticket_detail.html` 使用 ThinkPHP 模板 `{:$goods.title|default='...'}` —— `$goods` 是 PHP 变量，不是模板表达式
+2. `$vr_seat_template.seat_map` 是 PHP 对象访问，`|json_encode|raw` 是模板过滤器链，`|raw` 仅用于跳过 HTML 转义，不触发变量插值
+3. ThinkPHP `{$var}` 默认转义输出；`{:$expr}` 执行表达式但需要 `$var` 存在
+4. `$vr-` 作为 spec name 字符串存储在 DB 中，不作为 PHP 变量名
+
+**唯一需注意**：ShopXO 后台规格管理页可能将 `$vr-` 显示不当（纯展示问题，不影响安全）。
+
+### Q2 前端视角最小修复
+
+当前 `ticket_detail.html` 的 `loadSoldSeats()` 是 TODO，Plan A 需要：
+1. 后端生成 spec_base SKUs（BackendArchitect 负责）
+2. 前端 `loadSoldSeats()` 调用 API 查询各 seat spec_base 的库存状态
+
+最小可行路径：**先让购买流程能跑通，再迭代优化**。
 
 ---
 
@@ -217,14 +291,15 @@ ShopXO spec name 字段无字符过滤，数据库 `varchar` 类型允许 `$` 
 | 优先级 | 行动项 | 负责 |
 |--------|--------|------|
 | P0 | 紧急修复商品 112 broken state | BackendArchitect |
-| P1 | 实现方案 A 批量 SKU 生成 | BackendArchitect |
-| P2 | 隔离 ShopXO 规格管理页面（Hook 隐藏插件 SKU） | FrontendDev |
+| P1 | 实现方案 A 批量 SKU 生成（GoodsSpecificationsInsert 直接 SQL） | BackendArchitect |
+| P2 | 重构 ticket_detail.html submit() 接入 specBaseIdMap | FrontendDev |
+| P3 | Hook 隐藏插件 SKU（spec_base_id_map key = seat_id） | FrontendDev |
 
 ---
 
 ## 共识投票
 
-[CONSENSUS: NO] — 本轮仅完成分析，执行待后续阶段
+[CONSENSUS: NO] — Round 3 进行中：所有 Q1-Q4 分析完成，准备输出最终决策报告
 
 ---