从零开发一个球场订场小程序

去年帮朋友的羽毛球馆做了一个订场小程序，上线三个月后，场馆的周末黄金时段基本靠小程序消化掉了，前台电话量下降了一大半。这篇文章把整个开发过程里踩过的坑和关键设计整理出来，给准备做类似项目的开发者一个参考。

一、先想清楚业务模型

球场订场看起来简单，无非是「选场地 + 选时间 + 付款」，但真正动手前要先确认几个核心问题。

• 场地类型：羽毛球、网球、篮球半场，不同运动的时间粒度不同，羽毛球通常按小时，篮球可能按半场两小时。
• 价格策略：工作日白天、工作日晚上、周末全天，三档价格是标配，有些场馆还会区分会员价。
• 预约规则：是否支持连续预订多个时段、是否允许提前几天订、取消退款的截止时间。
• 支付方式：微信支付是主流，但很多场馆还保留了线下储值卡，需要一个卡券余额体系。

这些问题没想清楚就写代码，后面改数据结构会很痛苦。建议先用一张表格把所有规则列出来，和场馆老板逐条确认。

二、技术选型与数据建模

小程序端用原生开发或者 uni-app 都可以。如果只做微信一个平台，原生开发调试体验更顺；如果后面想扩展到支付宝或抖音，uni-app 更省事。后端我用的是 Node.js + MySQL，接口层用云函数托管，省去了服务器运维。

核心表结构大致如下：

-- 场地表
CREATE TABLE court (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50),
  type TINYINT, -- 1羽毛球 2网球 3篮球
  status TINYINT DEFAULT 1
);

-- 时段价格表
CREATE TABLE price_rule (
  id INT PRIMARY KEY AUTO_INCREMENT,
  court_id INT,
  day_type TINYINT, -- 1工作日 2周末
  start_hour TINYINT,
  end_hour TINYINT,
  price DECIMAL(10,2)
);

-- 订单表
CREATE TABLE booking (
  id INT PRIMARY KEY AUTO_INCREMENT,
  user_id INT,
  court_id INT,
  book_date DATE,
  start_time DATETIME,
  end_time DATETIME,
  amount DECIMAL(10,2),
  status TINYINT -- 0待支付 1已支付 2已取消 3已完成
);

这里有个关键点：不要把时段写死在代码里。场馆的营业时间、价格档位经常调整，用配置表驱动，运营自己就能改。

三、并发订场的防重处理

这是整个项目最容易出问题的地方。两个用户同时点进同一个时段，如果只是简单地「查一下有没有订单，没有就插入」，一定会出现超卖。

我用的方案是数据库唯一索引兜底：

ALTER TABLE booking
ADD UNIQUE KEY uk_court_time (court_id, start_time);

插入时捕获唯一键冲突错误，返回「该时段已被预订」。这样即使前端有并发，数据库层面也能保证不会重复。注意取消订单时不能直接删记录，要把 status 改成已取消，否则唯一索引会挡住后续重新预订。更好的做法是把唯一索引建在「有效订单」上，MySQL 8 支持函数索引，可以用 IF(status IN (0,1), start_time, NULL) 这类表达式，不过实现起来稍复杂，小项目用前者加定时清理也够用。

四、日历选场交互设计

用户最直观的操作路径是「选日期 → 选场地 → 选时段」。小程序里我用横向滚动的日期条配合场地网格，每个时段格子有三种状态：可订、已订、已过时间。已订的格子置灰不可点，已过时间的不显示价格，避免用户误触。

有个细节值得注意：跨天时段的处理。比如晚上 22:00 到 23:00 是当天的最后一个时段，但如果场馆营业到凌晨 1 点，就要考虑把 23:00 到次日 1:00 归到哪一天。我的做法是在配置里加一个「营业日截止时间」，比如设为凌晨 2 点，那么 0 点到 2 点的时段仍然算作前一天。

五、支付与订单状态机

微信支付接入本身不复杂，麻烦的是订单状态的一致性。用户下单后进入待支付状态，超时 15 分钟未支付自动取消。这里要用到微信支付的「支付结果通知」回调，同时前端也要轮询一次订单状态做兜底。

状态流转建议画成一张图，明确每个状态的入口和出口：

• 待支付 → 已支付（支付成功回调）
• 待支付 → 已取消（超时或用户主动取消）
• 已支付 → 已取消（退款，需要调用退款接口）
• 已支付 → 已完成（到场核销，扫场地二维码）

退款这块要特别注意，微信退款是异步的，不能假设调用接口就立即成功，需要监听退款结果通知再更新订单状态。

六、上线后的运营功能

小程序上线只是开始。实际运营中，场馆老板最需要的是这几样：

1. 核销功能：每个订单生成一个二维码，前台扫码确认到场。
2. 数据看板：按天统计订单量、收入、热门时段，帮助调整价格。
3. 会员卡体系：储值卡余额支付、次卡核销，能显著提高复购率。
4. 消息通知：订场成功、开场前 2 小时提醒，减少爽约。

如果时间有限，优先做核销和数据看板，这两个是场馆日常运营的刚需。

七、小结

球场订场小程序的难点不在界面，而在业务规则的梳理和并发场景的处理。把数据模型设计好、把状态机理清楚，剩下的就是体力活。建议第一版功能尽量精简，先跑通「选场 - 支付 - 核销」这条主链路，再根据场馆的实际反馈迭代。上线后多去现场看前台怎么用，往往能发现很多在电脑前想不到的问题。