vr-shopxo-plugin/docs/council-research-output.md

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 提交逻辑：

// 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 完成各自任务后更新。