面向羽毛球馆日常运营的全栈平台，将线上预约、到店开场、会员储值、商城取货和经营核对串联起来，为用户、前台、管理员和维修人员提供各自的工作区。
BF 羽毛球馆以线上预约与到店服务共享场地安排为基础，连接会员账户、支付订单、商品库存、取货凭证、赛事和社区。普通用户办理预约与消费，前台处理散客开场、储值和取货，管理员负责经营与权限管理，维修人员只读查看维护安排。
前端使用 Vue 3、TypeScript、Pinia 与 Element Plus，后端采用 Tornado 异步请求模型，通过 aiomysql 连接池和异步 Redis 客户端处理网络与数据库 I/O。
本页截图拍摄于 2026-09-29，来自本地独立演示环境，界面保留中文原貌；历史交易主要发生于 9 月 24 日。支付是项目内模拟，不是支付宝官方沙箱或真实转账。正式 HTTPS 部署、微信公众号挂链和真实扫码设备仍需另行验收。点击图片可打开原图。
当前新预约以 MySQL 事务为权威边界：先用 FOR UPDATE 锁定相关场地行，再复核有效预约、维护占用和报价；预约、支付单与审计记录在同一事务中提交。线上订场、到店开场、续场和改期使用统一的冲突规则。Redis 保留验证码、令牌和既有临时锁等用途，但不再是新预约占场防重的主要依据。
项目已保存一轮经真实 Tornado HTTP 路由、JWT 与角色校验的测量：macOS arm64、Python 3.14.3、MySQL 5.7.28，连接池上限 10。每类先执行一次首请求，再以 20 并发上限执行 200 次请求。
| 场景 | P50 (ms) | P95 (ms) | 失败 / 样本 |
|---|---|---|---|
| 商城结算报价 | 15.39 | 17.93 | 0 / 200 |
| 商城模拟收款 | 61.00 | 74.46 | 0 / 200 |
| 全局流水查询 | 305.47 | 349.48 | 0 / 200 |
用户可在时间表中连续选时，也可以给出最早开始时间、运动时长与场地偏好，让系统寻找完整空闲窗口。推荐算法通过前缀和筛选连续时段，再按时间偏差、偏好、价格及零散空档排序，最多返回三个候选并解释理由；推荐不占位，下单时仍需重新检查。
确认预约前展示原价、会员折扣、应付金额与可用余额，支持储值余额或项目内模拟支付宝。价格或权益变动会要求重新确认；有效待付订单保留成交快照。取消、过期和改期分别处理占用释放与差额结算，退款退回原支付渠道，模拟支付宝退款不会增加会员余额。
会员中心统一管理等级、有效期、余额、积分与账户流水。前台或管理员可以办理模拟收款储值，账户变更保留原因、经办人和关联业务。待支付订单的占用与可用余额分开显示，用户可核对储值、消费、退款及人工调整，而不是只看到一个余额数字。
平台还提供活动赛事报名、球友圈、公告和通知中心，使场馆系统同时覆盖交易、组织与社群触达，而不是停留在单一预约工具。
商城结算前重新核对价格、库存与可用余额，支持储值余额和模拟支付宝。待付订单预留库存，付款成功后生成取货二维码与可读码；前台或管理员先查询订单，再确认整单交付。同一订单只能核销一次，退款申请期间冻结取货，退款成功后凭证失效。
前台按完整时段原价为散客开场，无需先注册。例如 14:10 到店选择 14:00–15:00，仍支付整段费用并在 15:00 结束；相邻续场、收款和经办记录可追溯。前台不能发布赛事或公告，维修人员只读查看维护原因与时段，恢复开放由管理员确认。
管理员在全局流水中区分渠道收款、储值充值、余额消费和退款，避免“充值 100 元再消费 100 元”被统计成 200 元渠道收款。预约结束不等于已到场：到场率与记录覆盖率分别披露，人工调整也不混入经营收入。
