council(draft): BackendArchitect - create Phase 2 research plan with backend direction list
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>refactor/vr-ticket-20260416
Council
parent
3b3dde5b32
commit
896df3210e
|
|
@ -0,0 +1,113 @@
|
|||
# vr-shopxo-plugin Phase 2 — Research Plan (Round 1)
|
||||
|
||||
## Context
|
||||
- Phase 0/1: 插件骨架 + 数据库迁移完成
|
||||
- Phase 2 目标: 后台管理页面开发
|
||||
- 本轮: 纯研究讨论，不写代码
|
||||
|
||||
---
|
||||
|
||||
## Research Direction List (BackendArchitect)
|
||||
|
||||
### R1: 后台 API 设计 — ThinkPHP 8 控制器层规范
|
||||
|
||||
**Why:** ShopXO 基于 ThinkPHP 8，后台控制器需遵循其 Request/Response 约定，否则无法与现有 auth middleware 配合。
|
||||
|
||||
**Key Questions:**
|
||||
- [ ] ShopXO Admin 控制器基类是什么？是否有统一的 `BaseAdmin` 或 `AdminController`？
|
||||
- [ ] ThinkPHP 8 的 `Request` 对象如何获取当前登录 admin id / role？
|
||||
- [ ] API 返回格式是统一 JSON 还是沿用 ShopXO 的 `Json` 渲染器？
|
||||
- [ ] 分页参数命名规范：ShopXO 默认用 `page`/`limit` 还是 `page`/`pageSize`？
|
||||
- [ ] 新增 controller 是否需要在某个注册处声明（路由/菜单）？
|
||||
|
||||
---
|
||||
|
||||
### R2: 权限模型 — 多角色鉴权设计
|
||||
|
||||
**Why:** 核销员(vr_verifiers)与超级管理员属于不同角色，后台功能需要细粒度权限控制。
|
||||
|
||||
**Key Questions:**
|
||||
- [ ] ShopXO admin 用户表(`sx_admin`)的 role 字段结构是怎样的？是 RBAC 吗？
|
||||
- [ ] 核销员是否复用 admin 表，还是独立表(`vr_verifiers`)？各自权限如何隔离？
|
||||
- [ ] 座位模板编辑 / 电子票导出 / 核销记录查看是否需要分开授权？
|
||||
- [ ] 是否有现成的权限中间件可以复用，还是需要自行实现？
|
||||
|
||||
---
|
||||
|
||||
### R3: 数据库查询优化 — 大数据量导出场景
|
||||
|
||||
**Why:** 电子票列表 + 核销记录在数据量大时有分页和内存压力。
|
||||
|
||||
**Key Questions:**
|
||||
- [ ] `vr_tickets` / `vr_verifications` 当前预估数据规模？是否需要游标分页？
|
||||
- [ ] 导出功能（CSV/Excel）PHP 侧是否需要流式输出避免OOM？
|
||||
- [ ] `vr_verifications` 的 `verified_at` 字段是否建索引？
|
||||
- [ ] 是否需要读写分离？ShopXO 数据层是否支持？
|
||||
- [ ] 是否有批量查询 N+1 问题（如查询票时重复查 holder info）？
|
||||
|
||||
---
|
||||
|
||||
### R4: 事务一致性 — 核销操作的原子性
|
||||
|
||||
**Why:** 核销涉及两张表(`vr_verifications` 写入 + `vr_tickets.status` 更新)，若并发核销同一票会导致重复核销。
|
||||
|
||||
**Key Questions:**
|
||||
- [ ] ThinkPHP 8 Db facade 的事务写法（`Db::transaction()`）如何与 Model 层配合？
|
||||
- [ ] 是否需要悲观锁（`SELECT ... FOR UPDATE`）防止并发核销？
|
||||
- [ ] 乐观锁（version 字段）是否适用于高并发核销场景？
|
||||
- [ ] 核销失败后的补偿逻辑如何设计？
|
||||
|
||||
---
|
||||
|
||||
### R5: 存储过程 / 事件驱动 — 核销通知异步化
|
||||
|
||||
**Why:** 核销操作可能触发通知（站内信/微信），同步执行会阻塞核销响应。
|
||||
|
||||
**Key Questions:**
|
||||
- [ ] ShopXO 是否有事件/队列机制（Redis/DB queue）？
|
||||
- [ ] ThinkPHP 8 的 `Queue::later()` 或 `event()` 是否可用？
|
||||
- [ ] 若无队列，核销通知是否可以降级为同步日志+后台任务补偿？
|
||||
- [ ] 是否需要记录核销操作的 event log 供后续审计？
|
||||
|
||||
---
|
||||
|
||||
## Task Checklist (Phase 2)
|
||||
|
||||
- [ ] 座位模板管理 CRUD — API + Controller
|
||||
- [ ] 电子票列表 / 详情 / 导出 — API + Controller
|
||||
- [ ] 核销员管理（增删改查）— API + Controller
|
||||
- [ ] 核销记录查询 — API + Controller
|
||||
- [ ] Admin 控制器鉴权（P1 安全修复）— Middleware
|
||||
|
||||
---
|
||||
|
||||
## Phase Breakdown
|
||||
|
||||
| Phase | 内容 | Owner |
|
||||
|-------|------|-------|
|
||||
| Round 1 | 研究讨论 + 汇总 Research Direction | All |
|
||||
| Round 2 | 执行：API Controller 开发 | BackendArchitect |
|
||||
| Round 2 | 执行：前台 UI 页面适配 | FrontendDev |
|
||||
| Round 2 | 执行：安全鉴权 + 审计 | SecurityEngineer |
|
||||
| Round 3 | 联调 + 交叉 Review | All |
|
||||
| Round 4 | Finalize：合并到 main | All |
|
||||
|
||||
---
|
||||
|
||||
## Claim Status
|
||||
|
||||
- [ ] 座位模板管理 CRUD — `[Unclaimed]`
|
||||
- [ ] 电子票列表/导出 — `[Unclaimed]`
|
||||
- [ ] 核销员管理 — `[Unclaimed]`
|
||||
- [ ] 核销记录查询 — `[Unclaimed]`
|
||||
- [ ] Admin 鉴权 Middleware — `[Unclaimed]`
|
||||
|
||||
---
|
||||
|
||||
## Dependencies
|
||||
- SecurityEngineer: 鉴权设计需先于其他后台功能确定
|
||||
- FrontendDev: UI 框架选型需在 Round 1 确定，否则影响 Round 2 API 返回格式
|
||||
|
||||
---
|
||||
|
||||
*Council — BackendArchitect | Round 1 | 2026/04/15*
|
||||
Loading…
Reference in New Issue