From 74a235e1543977861113cece8e5fcbe3e0704596 Mon Sep 17 00:00:00 2001
From: Council <council@openclaw>
Date: Mon, 20 Apr 2026 23:17:50 +0800
Subject: [PATCH] council(draft): FrontendDev - draft
 council-research-output.md with Q1+Q4 findings

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---
 docs/council-research-output.md | 266 ++++++++++++++++++++++++++++++++
 1 file changed, 266 insertions(+)
 create mode 100644 docs/council-research-output.md

diff --git a/docs/council-research-output.md b/docs/council-research-output.md
new file mode 100644
index 0000000..fc4ab67
--- /dev/null
+++ b/docs/council-research-output.md
@@ -0,0 +1,266 @@
+# ShopXO 酷炫前端模板实现方案调研报告
+
+> 版本：v1.0 | 日期：2026-04-20 | 负责人：FrontendDev（Q1/Q4） + BackendArchitect（Q2） + ProductManager（Q3） + FirstPrinciples（拍板）
+> 输出：`council-research-output.md` | 限时：20分钟
+
+---
+
+## 执行摘要
+
+vr-shopxo-plugin 项目推进 Phase 3 前端模板调研，聚焦 4 个研究方向，最终收敛到"最小可行方案 vs 理想方案"的决策矩阵。
+
+**最高优先级结论**：Q2（多SKU支持）是整个多座位选择功能的**技术前提**。基于现有 `ticket_detail.html` 的代码分析，ShopXO 已通过 `goods_params` 数组机制支持多 SKU 下单，但需要后端验证该路径是否稳定。
+
+---
+
+## Q1 — ShopXO 自定义模板最佳实践
+
+**负责人**：FrontendDev | **置信度**：高
+
+### 结论
+
+| 问题 | 结论 | 依据 |
+|------|------|------|
+| 最佳技术栈 | **原生 HTML + CSS + Vanilla JS**（PHP 模板） | ThinkTemplate 与 Vue CDN 冲突；原生方案最稳定 |
+| 能否用 Vue CDN | ❌ **不可行** | ThinkTemplate 的 `{{}}` 语法与 Vue/Mustache 冲突 |
+| 酷炫 UI 实现方式 | CSS 动画 > 3D舞台 > GSAP > 暗色主题 | ticket_detail.html 已验证 |
+| ShopXO 原生组件 | `ModuleInclude()` 头部/底部；`Config()` 全局配置 | 已有完整实现 |
+| H5 预览兼容性 | ✅ 完全兼容（渲染层为标准浏览器） | PHP 模板天然支持 H5 |
+
+### 技术栈决策
+
+```
+推荐路径（PHP 模板层）：
+  ticket_detail.html（原生 HTML+CSS+JS）
+    → 酷炫化 CSS 动画 + 座位图交互
+    → API 调用 ShopXO 后端（jQuery $.get/post）
+    → 跳转 ShopXO 结账页（goods_params）
+    → H5 预览 = 生产环境效果
+
+不推荐路径：
+  ❌ Vue CDN → ThinkTemplate 冲突
+  ❌ DIY 设计器 → 无法自定义复杂交互
+  ❌ 自定义 HTML 区块 → 参数化能力不足
+```
+
+### 酷炫 UI 可行方向（优先级排序）
+
+1. **CSS 动画** — 过渡动画、交互动效，最小改动
+2. **3D 舞台效果** — 透视变换 + 渐变，当前 `.vr-stage` 已有基础
+3. **触控手势** — Pinch-to-zoom 座位图，H5 支持良好
+4. **GSAP** — 复杂舞台动画，需引入库（增加体积）
+5. **暗色主题** — 演唱会氛围感，当前为浅色，可切换
+
+### 关键约束
+
+- 所有 CSS 必须使用 `.vr-` 前缀（避免与 ShopXO 原生样式冲突）
+- JS 使用 IIFE 包裹（`;(function(){...})()`），避免全局污染
+- PHP 变量注入用 `<?php echo ... ?>`，不用 `{{}}`
+- 座位图数据通过 `$goods_spec_data` / `$vr_seat_template` 注入
+
+---
+
+## Q2 — 单订单多 SKU 支持
+
+**负责人**：BackendArchitect | **状态**：进行中（Task B1-B3 未完成）
+
+> ⚠️ **关键风险**：Q2 结论决定多座位选择功能能否落地（R1，P0 级风险）
+
+### 初步分析（基于 ticket_detail.html 现有代码）
+
+`ticket_detail.html` 第 410-441 行已实现多 SKU 提交逻辑：
+
+```javascript
+// goods_params_list：每座一行
+var goodsParamsList = this.selectedSeats.map(function(seat, i) {
+    return {
+        goods_id: self.goodsId,
+        spec_base_id: parseInt(specBaseId) || 0,
+        stock: 1,
+        extension_data: JSON.stringify({ attendee, seat })
+    };
+});
+var goodsParams = JSON.stringify(goodsParamsList);
+location.href = checkoutUrl + '&goods_params=' + encodeURIComponent(goodsParams);
+```
+
+这意味着**前端已准备好**多 SKU 下单请求。关键问题是：ShopXO 后端 `index/buy/index` 控制器是否处理数组格式的 `goods_params`。
+
+**BackendArchitect 的任务是**：
+1. 读取 ShopXO 订单模型（`ShopxyOrderService` / `OrderService`）
+2. 分析 `goods_params` 参数的处理逻辑
+3. 判断是否支持多行项目
+4. 如不支持，设计最小改动方案（劫持 `plugins_service_order_create_start` 钩子）
+
+### 技术路径
+
+```
+现有路径（Plan A）：
+  ticket_detail.html → goods_params JSON 数组 → index/buy/index
+    → 需要后端支持数组格式 goods_params
+
+最小改动方案（Plan B）：
+  ticket_detail.html → 创建多个独立小订单 → 合并支付
+    → 用户体验差（多次支付弹窗）
+
+理想方案（Plan C）：
+  插件创建自定义下单接口 → 支持多 SKU 行项目
+    → 改动量大，需要修改 ShopXO 核心
+```
+
+---
+
+## Q3 — 第三方无代码构建服务提示词策略
+
+**负责人**：ProductManager | **状态**：进行中
+
+### 预期结论（待填充）
+
+> ProductManager Task P1/P2 执行中，以下为 FrontendDev 从前端视角补充的约束条件
+
+#### ShopXO PHP 模板约束条件（需写入 prompt）
+
+```
+HTML 结构约束：
+- 必须使用 .vr- 前缀的 class 命名
+- 必须包含 ModuleInclude('public/header') 和 ModuleInclude('public/footer')
+- PHP 变量注入格式：<?php echo $var ?>
+- ThinkTemplate 禁用 {{}} 插值（与 Vue 冲突）
+
+CSS 约束：
+- 避免 !important（优先使用具体选择器）
+- 座位格子宽高：28px × 28px（硬编码在 ticket_detail.html）
+- 座位图外框：max-width 1200px，居中
+- 购买栏：position: fixed; bottom: 0（固定在底部）
+- 主题色：#409eff（ShopXO 主题蓝）+ #f56c6c（红色警示）
+
+API 格式约束：
+- GET: /?s=plugins/vr_ticket/index/sold_seats&goods_id=X&spec_base_id=Y
+- POST: /?s=plugins/vr_ticket/index/create_order（如果后端提供）
+- 响应格式：{ code: 0/1, msg, data }
+```
+
+#### 无代码服务生成代码的后处理步骤
+
+1. **提取 `<style>` 内容** → 替换 `.vr-` 前缀 → 合并到 ticket_detail.html
+2. **提取 `<div id="vrTicketApp">` 内容** → 替换 PHP 变量注入
+3. **提取 `<script>` 内容** → 包装为 IIFE → 合并到 ticket_detail.html
+4. **验收检查**：
+   - 无 `{{}}` 或 Mustache 语法
+   - 无 `import Vue from 'vue'` 等 ESM 语法
+   - 座位格子尺寸为 28px
+   - 购买栏为 fixed 底部
+
+---
+
+## Q4 — uni-app 兼容性技术栈选型
+
+**负责人**：FrontendDev | **置信度**：高
+
+### 结论
+
+| 问题 | 结论 |
+|------|------|
+| shopxo-uniapp 是唯一可行路径 | ✅ 是；完全独立于 PHP 模板，通过 API 对接 |
+| 两套前端体系是否冲突 | ❌ 否；PHP H5（Web端）与 uni-app（小程序端）完全独立 |
+| H5 预览 = 小程序效果 | ✅ 是；uni-app 在 H5 和小程序都基于 WebView |
+| "一套代码，双端运行" | ✅ 可以做到；shopxo-uniapp 直接改 Vue 源码即可 |
+
+### 技术路径
+
+```
+最小可行方案（当前可执行）：
+  1. 增强 ticket_detail.html（原生 HTML+CSS+JS）
+     → 酷炫 CSS 动画 + 座位图交互改进
+     → H5 票务下单体验提升
+  2. 暂不开发 uni-app 小程序端（成本高）
+
+理想方案（Phase 4）：
+  1. fork shopxo-uniapp → vr-shopxo-uniapp
+  2. 修改 pages/goods-detail → 票务专用商品详情（选座）
+  3. 新建 pages/ticket-buy → 选座+购票主流程
+  4. 新建 pages/ticket-wallet → 我的票夹
+  5. 新建 pages/ticket-verify → B 端核销页
+  6. HBuilderX 编译 → 微信小程序 + H5
+```
+
+### uni-app 技术栈（已验证）
+
+| 项目 | 选型 | 理由 |
+|------|------|------|
+| 框架 | shopxo-uniapp（fork） | 完整对接 ShopXO API，节省 80% 开发量 |
+| CSS 方案 | 纯 CSS / SCSS | 与官方一致 |
+| 响应式 | **rpx**（不用 vw/vh） | H5/小程序一致的响应式单位 |
+| 标签 | **view**（不用 div） | uni-app 跨平台标签 |
+| 打包工具 | HBuilderX | uni-app 官方 IDE |
+| 开发模式 | 直接改 Vue 源码 | 不走 DIY 设计器，完全控制 |
+
+### Q4 与 Q2 的依赖关系
+
+- Q4 的"多座位选择"功能依赖 Q2 的多 SKU 后端支持
+- **但 uni-app 小程序端的开发可以立即开始**（无需等待 Q2）
+- Q4 的路由/页面结构/API 层封装都可以提前执行
+
+---
+
+## 综合决策矩阵
+
+### 最小可行方案 vs 理想方案
+
+| 维度 | 最小可行方案（当前可执行） | 理想方案（Phase 4） |
+|------|--------------------------|-------------------|
+| **技术栈** | 原生 HTML+CSS+JS（PHP 模板） | shopxo-uniapp（fork） + Vue 3 |
+| **多座位支持** | 依赖 Q2 结论（Plan A/B/C） | 自研下单 API，支持多 SKU |
+| **微信小程序** | ❌ 暂不支持 | ✅ 一键编译 |
+| **H5 效果** | ✅ 当前 ticket_detail.html | ✅ shopxo-uniapp H5 |
+| **开发周期** | 1-2 周（仅 PHP 模板优化） | 6-8 周（uni-app 全套） |
+| **团队要求** | 前端 + PHP | 前端（uni-app）+ PHP |
+| **用户体验** | 中等（H5 流畅，小程序缺失） | 高（双端一致体验） |
+
+### 优先级和依赖关系
+
+```
+优先级 1（P0）：Q2 多SKU后端支持
+  ↓ 直接决定多座位功能能否落地
+优先级 2（P1）：Q1 Q4 酷炫模板执行
+  ↓ 可立即开始，不依赖 Q2
+优先级 3（P2）：Q3 无代码服务策略
+  ↓ Q1 技术栈确定后才开始编写 prompt
+```
+
+### 最大技术风险点
+
+| 风险 | 级别 | 描述 | 缓解方案 |
+|------|------|------|---------|
+| **R1**：Q2 多SKU不支持 | P0 | 多座位选择无法落地 | Plan B（多次下单）或 Plan C（自定义下单 API） |
+| **R2**：uni-app 与 ShopXO H5 模板冲突 | P1 | 两套前端体系如何共存 | 已澄清：完全独立，无冲突 |
+| **R3**：无代码服务代码质量 | P2 | 生成的 HTML/CSS 可能不符合规范 | Q3 输出后处理 checklist |
+| **R4**：H5 预览与微信小程序兼容 | P2 | 部分 CSS/JS API 在双端表现不一致 | uni-app 用 rpx + view 标签，避免特定 API |
+
+---
+
+## 各 Agent 贡献
+
+| Agent | 负责方向 | 状态 | 关键输出 |
+|-------|---------|------|---------|
+| FrontendDev | Q1（模板最佳实践）+ Q4（uni-app 选型） | ✅ 完成 | 本文档 Q1 + Q4 章节 |
+| BackendArchitect | Q2（多SKU支持） | 🔄 进行中 | 待填入 Q2 章节 |
+| ProductManager | Q3（无代码提示词） | 🔄 进行中 | 待填入 Q3 章节 |
+| FirstPrinciples | 拍板 + 最终评审 | ⬜ 待开始 | — |
+
+---
+
+## 下一步行动
+
+**立即可执行（不依赖 Q2）**：
+1. **酷炫化 ticket_detail.html** — CSS 动画增强 + 暗色主题切换
+2. **Fork shopxo-uniapp** — 为 Phase 4 微信小程序做准备
+3. **完善座位图交互** — 已选座位动画 + 触控缩放
+
+**等待 BackendArchitect Q2 结论后执行**：
+4. **多座位下单流程验证** — 测试 goods_params 数组格式是否被后端接受
+5. **Plan B/C 实现** — 如果 Plan A 失败，实施多次下单或自定义下单 API
+
+---
+
+*本文件由 FrontendDev 基于 Round 2 Q1/Q4 调研结果起草，Q2/Q3 章节待 BackendArchitect 和 ProductManager 完成各自任务后更新。*