sileya-ai
/
vr-shopxo-plugin
1
0
Fork 0
Code Issues 3 Pull Requests Packages Projects Releases Wiki Activity
vr-shopxo-plugin/plan.md

4.1 KiB
Raw Blame History

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