96 lines
5.3 KiB
Markdown
96 lines
5.3 KiB
Markdown
|
# docs/PHASE2_PLAN.md 评估报告
|
|||
|
|
|
|||
|
|
> 评审人：BackendArchitect | 日期：2026-04-20
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 准确性评分：7/10
|
|||
|
|
|
|||
|
|
### 问题 1：模板渲染根因描述过于简化
|
|||
|
|
|
|||
|
|
第一章写道"Goods.php 原来用 MyView() 加载主题模板，票务商品需要加载插件独立模板 ticket_detail.html"。这个描述正确但过于简化，遗漏了关键原因：ShopXO 插件系统是纯 Hook 系统，无法通过 config.json 覆盖控制器模板路径，加上 MyView() 的 view_path 拼接逻辑与绝对路径不兼容。缺少这一层说明会让接手者无法理解为什么必须改 Goods.php 而不是通过插件机制解决。
|
|||
|
|
|
|||
|
|
### 问题 2：Step 1 操作人信息可能过期
|
|||
|
|
|
|||
|
|
"操作人：大头（容器在本机）"——这行信息有价值，但只写了操作人没写操作时间。如果后续大头不记得这回事，接手者不知道该任务是否有主。如果大头不在，其他人能操作吗？应补充操作前提（容器在本机）或操作步骤（远程 SSH 方式）。
|
|||
|
|
|
|||
|
|
### 问题 3：核销 API 路径描述模糊
|
|||
|
|
|
|||
|
|
Step 4 写道"`POST /api/vr_ticket/verify` — B 端小程序扫码调用"，但没有说明该 API 的认证机制（是否需要 token？是否使用 RLS？）、请求参数格式、响应格式。如果开发者要实现这个 API，这份文档几乎没有参考价值。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 完整性评分：6/10
|
|||
|
|
|
|||
|
|
### 缺失项 1：容器访问方式未记录
|
|||
|
|
|
|||
|
|
Step 1 说"在 shopxo-php 容器内"，但没有说明怎么访问。是在宿主机上 `docker exec` 还是 SSH？容器 IP 是多少？端口 9000 是 PHP-FPM 不是 Web 服务。这对于不熟悉这个具体 Docker 配置的人来说是一个重大缺口。
|
|||
|
|
|
|||
|
|
### 缺失项 2：决策点 2 和 3 过于开放
|
|||
|
|
|
|||
|
|
决策点 2（loadSoldSeats 是否实时查库）涉及性能和数据一致性权衡，文档没有给出这两种方案各自的优劣。决策点 3（Layui 是否继续使用）根本没有给出可选方案。对于需要做决策的人来说，这些问题几乎是凭空抛出的。
|
|||
|
|
|
|||
|
|
### 缺失项 3：风险表缺少已知的架构决策不确定性
|
|||
|
|
|
|||
|
|
已知风险表中列出了 5 项风险（include 标签、容器未启动、Admin 鉴权链、座位模板绑定逻辑），但缺少一个关键不确定性：后台控制器已生成但未调试，调试过程中可能发现新的路由或权限问题。这个风险没有体现在表格中。
|
|||
|
|
|
|||
|
|
### 缺失项 4：核销 API 安全性未评估
|
|||
|
|
|
|||
|
|
Step 4 说"B 端小程序扫码调用"，但未说明扫码核销的安全机制：如何防止恶意刷票？如何验证核销员身份？这些问题关系到 API 设计的核心，在 Phase 2 计划阶段应该有所涉及。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 可操作性评分：7/10
|
|||
|
|
|
|||
|
|
### 优点：Step 1 成功标准非常清晰
|
|||
|
|
|
|||
|
|
"HTML 源码中不再有 ThinkTemplate 标签（`{include}` / `{$` / `{if}`），座位图 div 正常显示"——这是一个写得非常好的成功标准，可观测、可验证。
|
|||
|
|
|
|||
|
|
### 优点：模板渲染现状表格简洁有效
|
|||
|
|
|
|||
|
|
| 项目 | 状态 | 说明 | 三列结构一目了然。
|
|||
|
|
|
|||
|
|
### 建议 1：Step 3 缺少具体的联调检查清单
|
|||
|
|
|
|||
|
|
Step 3 说"确认路由可访问（后台 URL 格式）/ 验证 CRUD 操作正常 / 确认 RLS 策略"，但没有说具体怎么确认。对于路由可访问，应该给出预期的 URL 格式（如 `/adminufgeyw.php?s=plugins/index/pluginsname/vr_ticket/pluginscontrol/admin/pluginsaction/seatTemplateList`）；对于 CRUD 操作，应该说清楚需要验证哪些字段。
|
|||
|
|
|
|||
|
|
### 建议 2：决策点应给出时间限制
|
|||
|
|
|
|||
|
|
三个决策点都没有说明谁来决策、何时决策。如果长期悬而未决，Step 1-4 中哪些任务会受阻？应说明决策是阻塞性的还是非阻塞性的。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一致性评分：8/10
|
|||
|
|
|
|||
|
|
### 优点：与 docs/14 基本一致
|
|||
|
|
|
|||
|
|
与 docs/14 相比，PHASE2_PLAN.md 中表名一致（`vrt_vr_seat_templates`）、commit 号正确（7bd896764）、状态描述吻合。
|
|||
|
|
|
|||
|
|
### 轻微问题：文件路径基准同样不完整
|
|||
|
|
|
|||
|
|
与 docs/14 一样，`app/index/controller/Goods.php` 路径没有注明 `shopxo/` 子目录前缀，实际路径应为 `shopxo/app/index/controller/Goods.php`。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 误导风险评估
|
|||
|
|
|
|||
|
|
### 高风险项
|
|||
|
|
|
|||
|
|
**误导：Step 1 看似个人任务而非团队任务**
|
|||
|
|
|
|||
|
|
"操作人：大头（容器在本机）"让这份计划看起来像是依赖某一个人。如果大头有事不在，Step 1 之后的步骤全部阻塞。更好的做法是说明容器访问方式（Docker exec / SSH），让任何有环境访问权限的成员都能执行。
|
|||
|
|
|
|||
|
|
**误导：Step 2 loadSoldSeats 的定位模糊**
|
|||
|
|
|
|||
|
|
文档将 loadSoldSeats 放在"模板渲染实测"之后、"后台管理页面联调"之前，但没有说明它是前台展示层的任务还是后台管理的任务。如果它是前台座位图状态显示的一部分，它应该和 Step 1 合并，而不是单独列为一个步骤。
|
|||
|
|
|
|||
|
|
### 低风险项
|
|||
|
|
|
|||
|
|
风险表写得比较完整，P0/P1 优先级标注合理。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 总体评价
|
|||
|
|
|
|||
|
|
PHASE2_PLAN.md 整体结构清晰，现状描述准确，成功标准写得很好，与 docs/14 的一致性也令人满意。这份文档最大的问题是信息密度不够均衡：Step 1 的成功标准写得很细，Step 2-4 却缺少操作细节；决策点给出了问题但没有给出决策框架；容器访问方式缺失意味着计划高度依赖特定个人的参与。最需要改进的是补充 Step 1 的具体操作步骤和 Step 4（核销 API）的设计要点。
|