docs: 追加方案 C 决策记录和最终实现说明

reports/venue-hard-delete-evaluation.md

@@ -291,11 +291,53 @@ if (empty($seatTemplate) && !empty($config['template_snapshot'])) {
 
 ---
 
-## 风险说明
+## 决策记录
 
-当前系统**不存在真正的硬删除**，所有删除都是软删除。评估基于计划引入硬删除功能的假设。
+### 方案选定：方案 C（用户提出）— 置空 + 自清理
 
-如不实施硬删除，则 Q1 不会触发，仅需 Q2 方案 A 作为防御性编程。
+**决策日期**：2026-04-20
+
+**核心思路**（用户提出）：
+> 模板如果删除说明用户不要了，否则他就应该设置禁用。既然删除，等商品卖完继续上架，不存在的配置本来就应该同步不要了。
+
+**用户意图**：删除模板 = 用户主动放弃该模板 → 商品的 template_snapshot 也应一并清空，让商品下次保存时整块 config 干净地失效，而不是保留旧 snapshot 导致"有 snapshot 但无 template"的不一致状态。
+
+**最终方案逻辑**：
+1. `GetGoodsViewData()` 检测到模板不存在 → 将 `template_id` 和 `template_snapshot` 同时置 null → 写回 DB
+2. 前端打开编辑 → 选单为空（因为 template_id=null 对应不上任何模板）
+3. 用户保存（无 template_id）→ `AdminGoodsSaveHandle` 的 snapshot 重建条件 `$templateId > 0` 不满足 → 跳过重建 → config 块无 snapshot
+4. 商品彻底脱钩，不存在任何指向已删模板的数据
+
+**警告文案**（删除确认弹窗）：
+> 删除记录不会导致已上架商品内容变动。若需要同步场馆信息到已发布商品，请编辑对应商品并保存。
+
+### 最终实现
+
+**文件 1**：`service/SeatSkuService.php` - `GetGoodsViewData()`
+- 模板不存在时，`template_id = null` + `template_snapshot = null`
+- 同步写回 `vr_goods_config` 到 DB
+- 返回 `null` 模板，前端座位图区域空白
+
+**文件 2**：`hook/AdminGoodsSaveHandle.php` - 重建 snapshot 逻辑
+- `Db::find($templateId)` 返回 null 时 → `continue`
+- 不执行后续 `json_decode($template['seat_map'])`（避免 Fatal Error）
+- BatchGenerate 条件 `$templateId > 0` 不满足 → 跳过 SKU 生成
+
+### 与方案 A+B 的对比
+
+| | 方案 A+B | 方案 C（最终） |
+|---|---|---|
+| 模板不存在时 | fallback 到 snapshot | 置空 template_id + snapshot |
+| 用户感知 | 旧数据仍可见 | 选单为空，需重新选择 |
+| 数据一致性 | 混合状态（无 template_id 但有 snapshot）| 干净清空 |
+| 复杂度 | 两处改动 | 一处读+一处写 |
+| 符合用户意图 | 中等 | ✅ 完全一致 |
+
+### 风险说明
+
+- 删除模板前已售出的票不受影响（`goods_snapshot` 是购买时快照）
+- 正在编辑中的商品，下次保存会自动清空配置（符合"不要了"的语义）
+- 已上架商品（未重新编辑）保持原状态 → 下次编辑时才发现模板缺失 → 也按上述逻辑处理
 
 ---