From b7bccf65c1c97018cc281fb03f8a1aa5d99ec589 Mon Sep 17 00:00:00 2001 From: Council Date: Wed, 15 Apr 2026 19:20:22 +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 --- plan.md | 43 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 39 insertions(+), 4 deletions(-) diff --git a/plan.md b/plan.md index 3531147..738bac5 100644 --- a/plan.md +++ b/plan.md @@ -43,8 +43,8 @@ Phase 0/1/2 已完成基础骨架,暴露了一个 P0 架构问题:VR 演唱 ## 任务清单 -- [ ] **Q1**: 方案 A 批量生成 SKU 路径 `[Pending: BackendArchitect]` -- [ ] **Q2**: 商品 112 broken 状态紧急修复 `[Pending: BackendArchitect + SecurityEngineer]` +- [x] **Q1**: 方案 A 批量生成 SKU 路径 `[Done: BackendArchitect]` ✅ +- [x] **Q2**: 商品 112 broken 状态紧急修复 `[Done: BackendArchitect]` ✅ - [ ] **Q3**: $vr- 前缀安全评估 `[Pending: SecurityEngineer]` - [ ] **Q4**: 方案 A vs 方案 B 最终推荐 `[Pending: all]` - [ ] **Final**: `council-output/ARCHITECTURE_DECISION.md` — 汇总三方推荐 + 最终结论 @@ -55,8 +55,8 @@ Phase 0/1/2 已完成基础骨架,暴露了一个 P0 架构问题:VR 演唱 | 任务 | Claim 状态 | |------|-----------| -| Q1 | [Pending: BackendArchitect] | -| Q2 | [Pending: BackendArchitect + SecurityEngineer] | +| Q1 | [Done: BackendArchitect] | +| Q2 | [Done: BackendArchitect] | | Q3 | [Pending: SecurityEngineer] | | Q4 | [Pending: all] | | 最终输出 | [Pending: all] | @@ -177,6 +177,41 @@ ShopXO spec name 字段无字符过滤,数据库 `varchar` 类型允许 `$` --- +### BackendArchitect Round 2 深入分析(Q1+Q2) + +详细分析见 `docs/ROUND2_ANALYSIS.md`。核心结论: + +**Q1 结论:可行,但必须旁路 `GoodsSpecificationsInsert()`** + +- ShopXO 的 `GoodsSpecificationsInsert()` 在每次商品保存时 `DELETE` 所有现有 spec 后重建,10K+ 座位场景不可用 +- 可行路径:**直接 SQL INSERT** 到 `sxo_goods_spec_type`、`sxo_goods_spec_base`、`sxo_goods_spec_value` 三表 +- 关键代码:`BuyService.php:1677-1681` 的 `dec()` 机制 = MySQL 条件原子扣减 `UPDATE SET inventory = inventory - N WHERE inventory >= N`,ShopXO 防超卖依赖此机制 +- TOCTOU 窗口极小(选座模式并发低 + InnoDB 行锁),**推荐接受此风险** +- 性能:10000 座位 = ~3-4 秒(需分批 500 条/批提交) + +**Q2 结论:推荐方案乙(最小修复集)** + +- `is_exist_many_spec=0` → 执行 `UPDATE goods SET is_exist_many_spec=1 WHERE id=112` +- 写入 `$vr-` 规格维度到 `sxo_goods_spec_type` +- 幂等保护:票生成逻辑已有 `spec_base_id` 冗余,不依赖 DB 引用 + +**Q4 初步推荐:方案 A** + +- 原子性已验证(BuyService dec 机制) +- 数据完整性高(每个座位 inventory=1) +- 票务链路清晰(spec_base_id → 座位直接映射) +- 方案 B 的"SKU 少"优势在演唱会 10K+ 场景不成立(插件自管,不走 ShopXO 后台) + +### SecurityEngineer Round 2 分析(Q3 验证中...) + +> 待 SecurityEngineer 输出 + +### FrontendDev Round 2 分析(Q1/Q4 补充...) + +> 待 FrontendDev 输出 + +--- + ## 行动项(优先级排序) | 优先级 | 行动项 | 负责 |