1. 项目概述场馆预订这个事听起来好像就是“挂个日历让人选时间”但真正做过的人都知道里面的坑一点都不少。我去年帮某体育中心做了一套线上场馆预订小程序源码系统核心就是“分时计费在线预订”项目做完后我觉得这套思路很值得单独拿出来聊聊。标题里的“分时计费”这四个字才是整个系统的灵魂预订只是外壳计费规则才是真正决定系统复杂度的东西。先说说这个项目解决的实际问题。某体育中心有羽毛球馆、篮球馆、乒乓球室一共十来个场地。以前全靠前台电话接单手写登记本记录时间月底财务对着本子核对账单节假日高峰期经常漏记、错记甚至出现过同一个场地同一时段被订了两次的情况。场馆运营方想上一套系统但又不愿意改变太多使用习惯——用户要能看场地、选时间、在线付款管理员要能设置不同场地的价格不同时段价格还不一样月底要能自动出账单统计哪个场地赚钱、哪个时段闲置。需求看起来不复杂但真正落地时你会发现“分时计费”四个字牵扯出时间片、价格模板、锁定策略、支付回调、自动关单等一系列问题。这套系统的核心思路可以概括成一句话把场馆资源切成可售卖的时间片让价格随时间变化用状态机管理每个时间片从空闲到锁定到核销的全生命周期。这套方案适合谁看如果你是做场馆、球场、自习室、会议室、停车位这类“按时段出租场资源”的系统这篇文章可以给你一套参考设计如果你只是在做一个简单的预约小程序也能从里面提取出通用的订单状态管理和锁时段的思路。前端用什么框架反而不是重点重点是后端那几个核心设计决定了系统稳不稳、会不会超卖、账对不对得上。2. 整体设计与需求拆解2.1 为什么“分时计费”不是简单加个价格字段很多没做过这块的朋友第一反应是把场地表加一个 price 字段用多少钱一小时去计算。这想法一开始就会遇到问题。同一个羽毛球场工作日下午两点和周末晚上七点价格能一样吗工作日白天没人来订出去就是赚到周末晚上黄金场次不打折甚至要加价。如果只用一个固定单价运营方就没法用价格杠杆去调控低谷时段的需求系统上线后八成会被抱怨“不如原来的手工模式灵活”。分时计费的正确做法是把“场地”和“价格”拆成两个独立概念。场地是一个物理资源它有编号、有位置、有类型长期不变。价格则是一个随时可调的规则可以按季节调、按节假日调、按周几调、按具体时段调。场地和价格之间是引用关系不耦合在同一个表里。我在这套系统里设计了一张 price_rule 表每条规则大概长这样适用场地范围可以指定全部场地也可以指定某一组场地适用日期类型周一至周日、工作日、周末、节假日时间段比如 09:00-12:00、18:00-22:00单价按小时计费或者按场次计费最低预订时长比如至少订 1 小时有些场地要求至少订 2 小时状态启用/停用运营人员在后台新增一条规则比如“周六周日上午 9 点到 12 点羽毛球场地60 元/小时”保存后立即生效。计价模块在用户下单时根据场地匹配、日期匹配、时间匹配三条线索自动算出总价。2.2 核心功能模块拆解整套系统按功能域可以拆成五大块每一块都有各自需要重点处理的地方。第一块是场地资源管理。场地包含物理属性和运营属性物理属性就是名称、位置、面积、设施运营属性包括默认开放时间、最小预订单位、是否支持连续多时段预订、是否允许取消。这些属性直接影响下单逻辑比如某场馆规定“预订开场前 2 小时内不得取消”这个限制如果不在系统里体现后期退款纠纷会很难处理。第二块是时段模板。场地不能一天 24 小时都在卖运营方得先定义一天被切成多少个可售时段。我采用的是按固定间隔生成时段的方法比如从 09:00 开始每 30 分钟一个刻度到 22:00 结束。用户选“9 点到 10 点”系统自动对应 09:00-09:30 和 09:30-10:00 两个时间片。这样做的优势是无论用户选多少时长拆出来的底层时间片粒度一致库存校验和锁定逻辑都可以统一处理。第三块是订单与支付。这是系统的核心链路用户选场地下单系统锁定时间片用户支付支付回调成功后时间片从未支付变成已支付最后到场核销。这套流程每个节点都有前置条件和后置动作不能省。第四块是会员与优惠。场馆运营方很喜欢搞充值赠送、时段折扣这类活动。设计时我预留了用户等级字段和优惠券表但把具体规则做成了可配置项不写死在代码里。比如“银卡会员工作日首小时 8 折”这类规则由运营在后台配置系统根据用户等级和订单条件自动匹配最优优惠。第五块是经营统计。月底对账必须有数据支撑。我额外做了两张报表一张按时间维度统计的营收报表一张按场地维度统计的使用率报表。运营方最关心的是“哪些时段卖得不好”有了数据才知道要不要调整价格策略。2.3 基础数据模型设计要点数据模型是整个系统最见功底的地方。我直接说几个关键表的设计思路后面实操部分会给出更具体的实现。场地表venue的核心字段是场地名称、场地类型、状态。注意要加一个排序字段前端场地列表的展示顺序由它控制不然用户看到的场地顺序会很乱。计费规则表price_rule上面已经提到了核心是适用日期、时间区间、单价、最小预订时长。有一个容易被忽略的点规则之间可能会重叠比如“周末全天上浮 10%”和“周日上午 8 点到 10 点特价”同时存在时必须定义优先级。我在系统里采用的是最精准优先原则即时间段匹配到更细粒度的规则时以细粒度规则为准。订单表booking_order的核心字段包括订单号、场地 ID、开始时间、结束时间、总金额、状态、用户 ID、备注。订单号我用了“日期小时级时间戳随机数”的组合保证并发下不重复。时间片锁定表slot_lock是防止超卖的关键。每个可售时间片在用户下单时插入一条锁定记录状态为锁定中支付成功后变成已占用超过支付时限后自动释放。这张表的存在让“查库存”和“锁库存”变成了两个独立操作。3. 核心细节解析与实操要点3.1 时段锁定的并发控制场馆预订系统最怕的就是超卖两个人同时看中同一个场地同一个时段都下单了最后只有一个能成功。解决这个问题的方案有很多但从实际效果和实现成本来看我推荐数据库唯一索引 状态前置校验的双重保险。先说最简单可靠的方案。锁定记录表里把场地 ID、开始时间、结束时间、锁定日期四个字段设成联合唯一索引。当用户提交锁定时直接 INSERT 一条锁定记录。如果两个人恰好同时提交数据库层面只有一个能插入成功另一个会报唯一索引冲突由代码捕获后返回“该时段已被抢订”。这种方案不需要引入 Redis也不需要复杂的分布式锁单机部署的场景下性能足够、逻辑简单是最不容易出错的做法。有的读者可能会问为什么要单独建一张锁定表而不是直接在订单表上加唯一索引因为在“未支付”状态下订单是随时可能失效的。如果把锁定状态放在订单表里就得多维护一个中间状态逻辑会绕。单独建表锁定生命周期清晰释放时直接删记录就行。当然如果你的系统访问量特别大比如抢热门演唱会场地那种量级数据库唯一索引依然是最终防线但可以在它前面加一层 Redis 预占来减轻数据库压力。先用 Redis SETNX 抢锁抢到后再落库没抢到就直接返回失败这样绝大多数请求根本不会打到数据库上。3.2 跨时段预订的计费逻辑用户一次订三小时恰好跨了两个价格时段这两段的单价不一样怎么算总价这是分时计费最核心的计算场景。我的算法思路是“切片计价”把用户预订的整段时间按计费规则的边界切成多个子段先找每个子段对应的单价再累加。举个例子某场地价格规则是“下午时段14:00-18:0040 元/小时晚间时段18:00-22:0060 元/小时”用户订 17:00-19:00系统把它切成两段17:00-18:00 按 40 算18:00-19:00 按 60 算总价 100 元。实现时要注意计费规则的边界时间必须是半小时或一小时的整数倍和系统的时段刻度对齐。如果规则边界和场地的最小预订单位不一致切片运算会非常麻烦。我在这套系统里规定所有时段价格规则的时间点必须从整点或半点开始虽然有点限制运营方的灵活性但换来的是稳定可靠的计费结果。3.3 订单状态机设计订单状态不能只用一个字段存几个数字每个状态之间的流转必须要有明确条件。我这套系统的状态定义为待支付用户下单成功但尚未付款对应的时间片锁定中已支付支付回调成功时间片锁定状态变为已占用已核销用户到场后确认使用订单流程完成已取消用户主动取消或系统超时关单锁定自动释放已退款整单退款或部分退款后订单进入终态状态的流转规则必须写清楚不然测试阶段会发现各种奇怪问题。比如“待支付”状态下用户点了取消不能直接变成“已取消”要先判断支付是否真的没有成功如果用户其实是付过钱了只是回调延迟这时取消订单就有可能造成“钱付了但场地被释放”的严重问题。我在这一块的处理是取消操作前先向支付渠道查单确认支付状态查不到支付成功记录才会真正去释放场地。3.4 核销环节的防重复验证核销这个动作看起来简单就是扫个码、打个标记。但如果不加防护同一个订单的核销二维码可以被保存、转发、重复使用。我的做法是每个订单生成一个一次性消费码核销接口处同时校验订单状态和消费码状态一旦核销成功立即将消费码标记为已使用。同时后台保留核销人、核销时间的记录如果出现纠纷可以追溯。还有一个细节容易被忽略核销人员和预订人可能是同一个人也可能是场馆前台。前台的核销入口建议单独做一个管理员小程序端或管理层权限不能让用户自己把自己核销了不然就失去了核销的验证意义。4. 实操过程与核心环节实现4.1 可售时段生成算法系统里场地每天的可售时段不是写死在代码里的而是根据“运营配置的开场时间和结束时间 最小预订单位”计算出来的。这样运营人员调整开放时间时前端和后台会自动同步。我的实现思路是写一个时段生成服务输入场地当天开放时间输出该场地当天的所有可选时间段。核心代码如下伪代码便于理解逻辑function generateTimeSlots(openTime, closeTime, minUnitMinutes) { const slots []; const [openHour, openMinute] openTime.split(:).map(Number); const [closeHour, closeMinute] closeTime.split(:).map(Number); let current openHour * 60 openMinute; const end closeHour * 60 closeMinute; while (current minUnitMinutes end) { const startLabel formatTime(current); const endLabel formatTime(current minUnitMinutes); slots.push({ start: startLabel, end: endLabel }); current minUnitMinutes; } return slots; } function formatTime(minutes) { const h String(Math.floor(minutes / 60)).padStart(2, 0); const m String(minutes % 60).padStart(2, 0); return ${h}:${m}; }这还不够用户预订一个半小时或者两小时得支持跨多个槽位。我另外写了“预订时段有效性校验”和“库存合并查询”两个接口前者校验用户选择的开始结束时间是否在开放时间范围内、时长是否合法后者把所有被用户选中的连续槽位状态合并查询只要有一个被占用就提示不可订。4.2 计费服务完整实现计费这块我把流程分为三步取规则、切时间片、算总价。每次预订请求进来后端先根据场地 ID 查当前生效的价格规则然后根据预订时间对计费规则做切片最后累加各切片价格。实际开发时我发现最麻烦的不是计算过程而是规则的匹配优先级。上面提过我用的策略是“最精准优先”即如果某段预订时间命中的规则不止一条选择时间粒度更细的那条。举个实战例子某场馆有一条规则是“工作日 18:00 后所有场地晚场价 60 元/小时”还有一条规则是“羽毛球场周三 19:00-21:00 特惠 40 元/小时”。从 19:00 到 21:00 这段时间如果用户订羽毛球场就命中第二条用户订篮球场命中第一条。代码实现时用了一个打分函数日期匹配度 时段匹配度的具体程度得分高的优先。4.3 预订-支付-回调主链路开发这条主链路的顺序必须严格遵守不能调换用户在端上选择场地、时间系统实时查询该时段可用性用户确认下单后端先做库存预占插入锁定记录锁定成功后创建订单状态待支付调用支付接口生成支付参数用户完成支付支付平台异步回调到商户后台回调接口校验订单金额和商户密钥确认无误后更新订单状态为已支付同时更新锁定记录为已占用若用户超过支付时限未付款系统自动关单释放锁定有一个很常见的坑是用户已经付款但回调接口因为网络问题没有及时通知到系统。这时用户看到的状态可能还是“待支付”如果系统按超时关单处理就会把场地释放掉。我在系统里做了双保险一是回调接口处理幂等重复回调不产生重复逻辑二是关单定时任务执行前先调用支付平台的查单接口确认只有确实未支付的订单才会被关掉。4.4 前端小程序核心页面与交互小程序端我用了跨端框架个人习惯用 Vue 语法的跨端方案能同时编译到微信、支付宝等不同端核心页面有四个场馆列表页、场地详情预订页、订单确认页、订单列表页。预订页的交互我觉得是决定用户体验的关键。用户点开一个场地后我今天和明天的可售时段以网格形式展示绿色代表空闲、灰色代表已占用、红色代表当前选中。选开始时间后系统自动根据最小预订时长展示可选的结束时间。这里有个小技巧结束时间的候选项是根据计费规则的边界自动计算的比如某场地两小时起订那开始时间是 14:00 时可用结束时间是 16:00、17:00、18:00 等整点而不是随意滚动选择。这样既保证了计费正确也避免用户选出一段无法计算价格的组合。订单确认页需要展示明细包括基础费用、每段单价、总价、优惠金额。用户付款前可以核对每笔钱是怎么来的这一点非常重要——场馆运营方对“用户以为支付 50 元结果被扣 70 元”这种事非常敏感明细展示是减少客服压力的最简单手段。4.5 部署与上线配置上线前有几个必须检查的配置项漏一个都可能会出事故支付回调地址必须是公网可访问的 HTTPS 地址支付平台不支持回调到内网订单超时时间设置我一般设为 15 分钟太短用户来不及付款太长会导致场地被无效占用定时关单任务必须保证单实例运行多实例部署时如果每个实例都执行一次关单扫描会出现重复操作需要用分布式锁或配置开关控制数据库连接池大小要合理设置高峰期回调请求和用户查询并发上来时连接池不够会直接拖垮服务5. 常见问题与排查技巧实录这一节记录我在开发过程中真实遇到过的典型问题已经整理成速查表方便你按图索骥。5.1 高频问题速查表现象可能原因排查思路用户明明付款了订单还停在待支付回调延迟或回调失败在小程序支付成功返回后主动调用后端“查询订单”接口以后端查单结果为准检查回调日志同一个场地同时被两个用户下单且都成功了库存校验和锁定没有原子化检查是否先查后插应改为直接插入锁定记录通过唯一索引兜底用户在 A 时段订了 1 小时计算出的金额和预期不一致计费规则边界处理有误打日志输出切片明细比对人工计算的金额订单取消后场地还是显示占用取消流程只改了订单状态没有释放锁定记录检查取消逻辑是否同时调用了释放锁定的接口周末黄金时段没人下单运营想改价格立即生效但不生效价格规则缓存未更新检查缓存策略应设置后台修改价格时主动刷新对应规则缓存用户订了两小时中途跨了三个价格时段账单按最长时段计价了切片算法只取了开始时间所在时段的价格检查算法是否真正按规则边界拆分了时间片后再计价退款后后台统计金额和支付渠道对不上部分退款场景未区分原订单金额与实退金额检查统计报表是否只统计了订单原金额没有扣减退款金额5.2 回调丢失的终极兜底方案上面提到回调可能丢失这里展开说说我最终的兜底方案。我在订单表里专门加了一个字段叫“同步状态”每次收到支付回调后除了更新订单还会在本地记录回调时间。同时做了一个每分钟执行一次的对账任务把所有超过支付时间但状态仍为“待支付”且未取消的订单拿去支付平台主动查单如果查到已支付就自动补单避免用户付了钱场地被释放的极端情况。这个兜底任务上线后才真正把“待支付残留”这个隐患压下去了。对于做预订类小程序的人来说这个对账任务不是可选项而是必需品。5.3 时间相关的隐藏坑场馆预订系统里时间处理是事故高发区我总结了三条经验。第一前端传时间一定要传时间戳或标准 ISO 字符串不能传“2024-01-15 14:00”这种格式让后端猜。不同时区、不同设备解析结果可能不一样出现一个“8 点订的场地变成了 7 点”的 bug 时排查成本极高。第二涉及节假日判断不要把节假日规则写死在代码里。运营方需要能自己配置“元旦当天闭馆”或“春节假期按假日价格”因此日期类型判断必须有对应的数据表支撑而不是在代码里用 if 判断公历日期。第三订单的开始结束时间建议用“日期 时间”的 DateTime 类型存储不要存成字符串。用字符串存的系统后期做统计报表、计算时长、跨周跨月筛选时都会痛苦到怀疑人生。5.4 对账与数据一致性检查系统上线运行后我最担心的是钱对不上账。支付平台的账单和本地系统的订单记录必须每日对账这个工作不能依赖人工。我在后台做了一个“日终对账”页面每天凌晨拉取支付渠道前一天的全部成功交易与本地订单表逐笔比对订单号是否存在、金额是否一致、状态是否已支付。比对结果分为“本地无此单”“金额不一致”“状态不一致”三类每类都有对应的处理流程。这套机制上线后财务人员可以在一分钟内完成前一天的对账工作而不是逐条核对Excel表。6. 经验总结与个人体会这套场馆预订小程序做下来我最深的感受是预订功能只是入口计费规则才是系统复杂度的核心来源也是运营方最看重的部分。很多团队做这类项目时喜欢先把前端界面做得很炫后端却只用一个简单的字段存价格结果一到运营配置阶段就开始返工。我建议是先把计费规则模型建清楚再去写前端页面顺序不能反。第二点体会是场馆预订系统的难点不在“开发”而在“精细化”。精细到什么程度呢运营方会问你“能不能只允许会员在工作日订场地”“能不能限制每人每天最多订两小时”“能不能设置开场前 24 小时内不可取消”。这些需求单个看起来都不难但组合起来就会让状态机变得很复杂。因此我在项目里把这个“规则面板”单独做了个配置中心每个规则都有开关和生效时间不写死在代码里。最后分享一个小技巧这类系统做完后建议在后台留一个“模拟下单”的测试入口管理员可以模拟任意用户、任意时段下单并快速取消或完成支付。这个入口在验收测试和后期排查问题时特别有用几乎每天都用得到。比如运营反馈某个时段明明没人订却无法预订用这个模拟入口可以直接复现不用等真实用户来配合。我当时加了这个功能之后开发测试效率至少提升了一倍。如果你也在做场馆预订类的小程序这个功能值得提前规划在内。
