4.8 KiB
4.8 KiB
Plan — 调研「场馆删除后编辑商品出现规格重复错误」问题
版本:v1.2 | 日期:2026-04-20 | Agent:council/FrontendDev + council/SecurityEngineer + council/BackendArchitect
任务概述
当票务商品关联的场馆模板被硬删除后,编辑商品时出现「规格不允许重复」错误。
根因调查分工:
- FrontendDev:前端规格项构建与 fallback 行为
- BackendArchitect:后端规格去重逻辑、
spec_base_id_map解析 - SecurityEngineer:安全风险评估(P1 vs P2)
FrontendDev 任务清单
- [Claimed: council/FrontendDev] Task 1: 读取
ticket_detail.html,分析前端构建规格项的过程 - [Claimed: council/FrontendDev] Task 2: 当模板不存在时,前端如何处理
template_snapshot和spec_base_id_map? - [Claimed: council/FrontendDev] Task 3:
loadSoldSeats()函数实际实现了吗?soldSeats 数据如何填充? - [Claimed: council/FrontendDev] Task 4: 编辑模式下(已有 vr_goods_config),前端是否正确处理已删除场馆的旧规格?
- [Claimed: council/FrontendDev] Task 5: 给出前端根因分析(含具体文件路径和行号)
- [Claimed: council/FrontendDev] Task 6: 给出修复方案
- [Claimed: council/FrontendDev] Task 7: 将调研报告写入
reviews/council-ghost-spec-FrontendDev.md
SecurityEngineer 任务清单
- [Claimed: council/SecurityEngineer] Task S1: 读取 AdminGoodsSaveHandle.php — 安全审计:保存时是否拒绝脏数据
- [Claimed: council/SecurityEngineer] Task S2: 读取 SeatSkuService.php — 幽灵 spec 注入路径分析
- [Claimed: council/SecurityEngineer] Task S3: 读取 AdminGoodsSave.php — ShopXO 入口安全检查
- [Claimed: council/SecurityEngineer] Task S4: 输出安全审计报告 →
reviews/SecurityEngineer-GHOST_SPEC_SECURITY.md - [Claimed: council/SecurityEngineer] Task S5: 更新
reviews/council-ghost-spec-summary.md
审计问题清单
- S1-Q1: 当
template_id指向不存在的场馆时,AdminGoodsSaveHandle是否拒绝保存(返回 code -401)? - S1-Q2: 幽灵 spec(来自已删除场馆的
spec_base_id_map)是否可在保存时被注入到vr_goods_config? - S1-Q3:
vr_goods_config中若有多个规格项的spec_base_id相同,是否会触发去重逻辑或安全阻断? - S2-Q1:
SeatSkuService::GetGoodsViewData在模板不存在时如何 fallback?fallback 数据是否可信? - S2-Q2:
template_snapshot字段是否可以携带恶意 payload? - S3-Q1: ShopXO
AdminGoodsSave.php入口是否有参数校验? - 评估: 根因属于 P1(拒绝脏数据/安全漏洞)还是 P2(功能降级)?
优先级定义
| 级别 | 含义 |
|---|---|
| P1 | 安全漏洞:脏数据注入、XSS、权限绕过、数据覆盖 |
| P2 | 功能缺陷:用户体验问题、错误提示不友好 |
| P3 | 改进建议:代码健壮性优化 |
BackendArchitect 任务清单
- Task B1: 读取 AdminGoodsSaveHandle.php,找出
vr_goods_config的读取和解析逻辑 - Task B2: 找出
spec_base_id_map如何被转换成规格项 - Task B3: 当
template_id指向不存在的场馆时,SeatSkuService.php 的 GetGoodsViewData 如何 fallback? - Task B4: 幽灵 spec 是在哪个环节产生的?是否在保存时过滤?
- Task B5: 商品保存时规格去重逻辑在哪里?
vr_goods_config中若有多个规格项的spec_base_id相同会怎样? - Task B6: 给出根因分析(含具体行号)和修复方案
- Task B7: 将调研报告写入
reviews/council-ghost-spec-BackendArchitect.md
阶段划分
| 阶段 | 内容 |
|---|---|
| Draft | Task 1-7(FrontendDev)+ Task S1-S3 + Task B1-B6(并行) |
| Review | Task 7 + Task S4 + Task B7(输出各自报告) |
| Finalize | Task S5:汇总到 reviews/council-ghost-spec-summary.md |
关键文件(必须全部检查)
| 文件 | 关注点 |
|---|---|
shopxo/app/plugins/vr_ticket/view/goods/ticket_detail.html |
前端规格项构建、template_snapshot fallback |
shopxo/app/plugins/vr_ticket/service/SeatSkuService.php |
GetGoodsViewData,模板不存在时的 fallback |
shopxo/app/plugins/vr_ticket/hook/AdminGoodsSaveHandle.php |
商品保存钩子,vr_goods_config 处理 |
shopxo/app/plugins/vr_ticket/admin/Admin.php |
VenueDelete 硬删除逻辑 |
shopxo/app/admin/hook/AdminGoodsSave.php |
ShopXO 商品保存钩子入口 |
依赖
- BackendArchitect:后端规格去重逻辑分析
- SecurityEngineer:安全风险评估
- FrontendDev:前端 fallback 行为分析
- 最终汇总由 SecurityEngineer 写入
reviews/council-ghost-spec-summary.md