分时计费+在线预订：场馆预约小程序源码系统设计与实践

开场场馆排期的那些事真该用系统管起来了你有没有见过体育场馆的排期表我见过最原始的一种前台白板上画着一周格子的表格电话来了就手动填填重了就两边扯皮临时改时间还要拿橡皮擦擦半天。羽毛球馆、篮球馆、共享琴房、会议室、自习室这类按时间租场地的场景几乎都有同一个痛点分时计费规则一复杂光靠人脑和Excel根本撑不住。我今天要分享的就是一套分时计费在线预订的场馆预订小程序源码系统。它解决的问题很明确用户在小程序里在线选场地、选时段、付钱商家在后台配置时段价格、查看排期、核销订单。从场地利用率到账目清晰度都能拉高一个档次。适合正在经营球馆、影棚、培训教室的运营者也适合想接这类定制项目的开发者参考落地。我刚拿到这类需求时也踩过不少坑。尤其是分时计费这件事做起来远比表面复杂——价格规则怎么配多个用户同时抢一个场次怎么防超卖用户付了钱没来怎么办管理端怎么看到今天的排期这些细节本文都会一条条拆开讲。1. 这套系统到底在解决什么管排期、算费用、收订单1.1 从白板排期到在线预订差的不只是便利很多非技术背景的场馆老板会问我请个前台不就够了吗实际上当场地数量超过3片每天开放12小时每半小时一个时段一天就有几十上百个可售单元。电话预订容易出现口头重复、手写漏记微信收钱和表上登记对不上账会员来了发现场地被占体验很差。更麻烦的是分时计费。羽毛球馆工作日下午和周末晚上的价格可以差一倍长租客户要打七折临时散客按原价特殊节假日还要整体上浮。这些规则写在纸上是一句话落到系统里就得设计一套时段价格规则引擎。谁来做小程序和后台都得配合。所以场馆管理更智能这句话落到功能层面其实是四件事可售状态实时可见用户端看到的可用场次就是数据库里的真实状态杜绝超卖。阶梯价格自动计算不同时段、不同日期类型工作日/周末/节假日自动匹配价格。订单资金可追溯线上支付、核销、退款全链路留痕对账不再靠Excel。排期冲突自动拦截时间段被占用后其他用户无法再提交靠数据库唯一约束保证。1.2 用户、商家、管理员三方角色看同一套数据我习惯把这类系统拆成三个端来设计因为每个端看到的信息粒度完全不同角色使用端核心诉求C端用户微信小程序就近找场地、按时间筛选、支付便捷、订单可查商家运营管理后台Web/小程序排期总览、价格调整、锁场/包场、核销平台管理员管理后台场地信息维护、商家配置、订单数据统计小程序端不用做得太重核心是选时间→选场地→付款这条链路越短越好。真正的复杂度集中在服务端和管理后台——那里才是分时计费和排期冲突的核心战场。2. 分时计费的核心模型时段模板、价格规则与锁场方案2.1 为什么我强烈建议用固定时段模板而不是自由选时长第一次设计时我天真地以为分时计费就是用户自己输入开始时间和结束时间系统按分钟算钱。做出来才发现问题一堆订2小时的用户把另一个用户想订的1小时包在了中间形成碎片时段每个订单时长不一样场地利用率预测不准退订后重新补位困难。后来所有案例几乎都统一改为固定时段模板。以30分钟或1小时为一个最小时间单位场馆每天被切成一个个场次。比如某球馆每天9点到22点每小时一个场次那就是13个可售时段。这样做的好处非常明显可售单元是确定数量的排期面板画出来就是规整的网格。计费变得极其简单每个场次单独定价用户订的就是场次本身。冲突检测退化为这个场次是否已被下单不用做时间区间重叠判断。代价是灵活性下降用户不能订15:20到16:40这种非标时长。但实际运营中绝大多数场馆都接受这个约束因为标准化才方便编排和统计。2.2 五张核心表场地、时段、价格、订单与占用明细有了固定时段模板数据库设计就清晰了。我整理过一套比较稳妥的表结构供参考场地表venue记录场馆和具体场地的ID、名称、类型、开放时间。这里的场地指可被预订的物理单元比如一片羽毛球场、一个会议室。时段模板表time_slot_template定义场地的开放时段列表。比如场地A09:00-09:59、10:00-10:59……直到22:00-22:59。价格规则表price_rule字段包括场地ID、适用日期类型工作日/周末/节假日、适用时段、时段单价。这一层才是分时计费的精髓。价格规则要支持叠加比如周末基础价节假日上浮20%会员折扣这样的组合所以在设计上我会单独建一张price_rule表而不是把价格直接写死在场地上。订单表order订单主表记录订单号、用户ID、场地ID、总金额、支付状态、订单状态。这个状态字段非常关键我会在2.3节详细说。场次占用明细表slot_occupancy这是防止超卖的真正兜底。每个可售单元日期场地时段一条记录订单创建时就插入。如果两个用户同时抢同一个场次谁的插入先成功谁就拿到。因为我对日期场地时段建了唯一索引后插入的一方会直接报重复键错误。2.3 并发抢场唯一索引比什么锁都靠谱不少没做过这类系统的同学第一反应是用加锁来防止超卖。比如给场地记录加select for update或者用Redis分布式锁。我都试过但最终被验证最稳的反而是数据库唯一索引约束。具体玩法是用户提交订单时后端事务里执行insert into slot_occupancy (date, venue_id, time_slot, order_id) values (?, ?, ?, ?)。如果同一时刻有两个请求插入相同日期、场地、时段的记录数据库会拒绝后一个并抛出唯一键冲突异常。捕获这个异常返回该场次已被预订完全不依赖任何锁服务也不怕多实例重复部署。这个方法对小型场馆系统来说性能上和可靠性上都是最优解。等到单场馆高峰期真的需要扛大量并发再在Redis层做预减库存也行但那时候先得解决的问题是和尚多了粥少而不是技术瓶颈。订单状态机我也建议一开始就定好待支付创建订单并锁定场次给15分钟支付窗口。已支付/待使用用户到店核销前。已核销用户到店后扫码或报手机号完成。已取消用户在待支付状态主动取消或超时未支付被系统释放。已退款和已取消的差异是用户付过款且得到退款。超时释放机制我会用延迟任务来处理。方案可以很轻创建订单时顺手把订单ID和释放时间写进Redis的zset一个定时任务每分钟扫一次把到时的待支付订单取消并释放场次。3. 小程序端在线预订的完整流程实现3.1 首页与场地列表先解决数据该不该缓存小程序端的首个难点其实不是支付而是页面加载和数据缓存。以我的经验首页和场地列表往往是用户反复进出的页面每次都拉全量接口又慢又费流量。常见的优化是分层缓存场地基础信息名称、图片、地址改动极少本地缓存24小时没问题。某一天的场次状态可订/被占实时性要求高但也可以缓存30秒到1分钟再加下拉刷新兜底。在微信小程序里用wx.setStorageSync和wx.getStorageSync即可key建议加上版本号后缀。比如cache_venue_list_v2以后数据结构调整了可以强制失效避免老用户读到脏数据。顶部导航栏高度这类细节也值得注意。用自定义导航栏做嵌入式页面需要调用wx.getMenuButtonBoundingClientRect()拿胶囊按钮的位置再动态算高度。不同机型计算结果不一样不能写死固定px值不然iPhone和Android下的错位一眼就看出来。3.2 选场地→选时段→提交订单交互串联的要点一个完整的预订流程小程序页面上通常是三步选日期横向日历滚动的日期栏默认今天允许预订未来7天或14天。选场地和时段围棋盘式的网格横轴是各个场地纵轴是时段每个格子颜色标识可订/被占/已满。确认订单右侧显示出所选场地、日期、时段、单价和金额选择支付方式提交。这个网格是预订体验的胜负手。我的实现思路是由后端一次性返回某日期所有场地所有时段的状态矩阵前端渲染成二维网格用户点到一个格子就高亮点第二次取消选择。一个订单只允许订同一场地连续时段减少拼单复杂度也方便商家排期——当然如果你希望支持跨场地区域下单后台规则要另行设计。需要注意不要在前端校验时段合法性只在后端做最终校验。前端做的再漂亮都可以绕过后端拿到请求后必须重新检查时段是否被占用、价格是否与当前规则一致。3.3 支付回调、幂等处理与超时释放微信小程序支付的常规链路是前端调用wx.requestPayment拉起收银台用户支付成功后微信服务端发起notify回调到我们的后端接口。这里有一个高频坑回调可能重复推送。微信官方文档明确说了回调通知会多次投递直到商户返回成功。所以后端处理回调时第一件事不是改订单状态而是查订单当前状态。如果已经是已支付直接返回成功不再重复处理。同时回调接口要校验appid、订单号、金额是否和库中一致金额不一致直接拒绝防止伪通知。超时释放的实现我在前面提过下单时锁定场次并给15分钟支付窗口超时取消。这里补充一个细节取消订单后必须同步释放slot_occupancy里的记录。很多人只改了订单状态为已取消结果场次占用明细没删导致这个时段永远不可订被商家误以为是系统bug。这个删除操作和订单状态更新要做在同一个事务里。4. 商家管理端的排期面板和动态调价4.1 日排期面板让商家一眼看清今天剩什么管理后台最核心的页面是一张按场地×时段排列的排期网格。它和用户端网格数据同源但展示的是订单信息和收入信息。每个格子显示的状态可以是空闲、锁场预留、已预订附订单号和手机号尾号。这个页面建议做成当天视图多日概览两种模式。当天视图精确到每个时段多日概览按天统计营收和预订率。预订率是很有价值的指标公式是预订率 当日已预订场次数 / 当日可售总场次数连续观察这个指标就能看出什么时段热、什么时段冷清为动态调价提供依据。商家最怕的不是空场而是不知道哪段时间空、为什么空。技术实现上管理后台用Web做就行React或Vue都可以。接口层和小程序复用同一套后端API只是返回字段更多。比如用户端场地状态返回布尔值管理端要返回订单ID和订单金额。4.2 动态调价、包场与临时锁场分时计费系统的刚性需求之一就是动态调价。同一个场地工作日白天可能30元每小时周末晚上可能要80元每小时。价格规则我习惯做成一个可叠加的配置关系基础价格场地默认单价。时段系数对不同time_slot设置系数比如晚高峰1.5倍。日历价格对特定日期节假日、赛事日设置单日价格直接覆盖基础价。动态调价不需要出在订单创建时而是每晚由定时任务预计算第二天的所有场次价格更新到可售单元价格字段里。别看这个做法简单它解决了实时计算的并发压力也方便管理端预看一下明天的价格有没有配错。包场和临时锁场也是常见功能。包场相当于一次性下单包含连续多个时段临时锁场则是不产生订单直接把某些格子设置成不可订状态。这两种操作在管理端本质都是写slot_occupancy表只是锁场记录没有关联订单ID类型标记为admin_lock。4.3 到店核销与营收统计线上卖票只是第一步线下履约才闭环。到店核销的做法不复杂商家在管理端输入用户手机号或扫用户出示的小程序订单二维码系统匹配到已支付的订单将状态改为已核销。注意一个订单只能核销一次核销接口要带上用户身份和订单状态校验防止用同一个订单二维码反复扫码薅羊毛。营收统计我建议直接按日期维度聚合订单表当日营收状态为已支付和已核销的订单金额总和。分场地营收看出哪片场地赚钱。退款金额单独列出和营收分开看。这些统计指标用SQL聚合查询就行没必要一开始就上BI系统。等订单量大了再考虑建预计算表或上独立统计库。5. 上线部署与小程序研发的实用避坑5.1 npm 安装脚本被系统拦截PowerShell 策略问题很多开发者在本地拉源码后第一步就卡在环境上。最常见的是在Windows PowerShell里执行npm install时报错npm : 无法加载文件 ... npm.ps1因为在此系统上禁止运行脚本。这不是代码的问题而是PowerShell默认执行策略限制。解决方案有两种以管理员身份打开PowerShell执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned回车选Y。或者不用PowerShell改用cmd来执行npm命令。我建议用第一种因为后续还有一些自动化脚本也会受影响。如果公司电脑有统一安全策略就退而求其次把项目目录下的脚本用node xxx.js直接执行绕过ps1。5.2 HTTPS 域名、开发版过期与本地抓包调试微信小程序要求线上环境的请求域名必须是HTTPS且在后台配置过合法域名。本地开发阶段有两个省事手段在开发者工具右上角详情→本地设置里勾选不校验合法域名。后端临时用IP或http协议跑但主要场景适合联调。开发版小程序还有一个常见的坑过一段时间会显示开发版已过期请重新扫码。这是微信安全机制不用紧张重新在开发者工具上传或预览用真机扫码打开即可。所以我一般会提醒团队开发阶段不要依赖一个固定的开发版小程序长期测试养成随时更新预览版本的习惯。抓包调试我常用Charles或whistle。小程序真机调试会走系统代理和证书校验需要给手机安装抓包工具的HTTPS证书。微信小程序的请求证书校验比较严格安装证书后如果还是抓不到检查是否把抓包工具设置为系统代理而不是仅WLAN代理。5.3 前端框架选型原生、uniapp 还是 Taro这个源码系统的前端选择很多人在原生小程序和跨端框架之间纠结。我的看法很直接如果业务只在微信生态里原生小程序完全够用生命周期清晰、调试工具兼容性最好。如果你预期后续要出支付宝小程序、抖音小程序或者要复用App端的代码uniapp是性价比最高的方案Vue语法、一套代码多端发行。Taro适合React技术栈团队性能也不错但对新手的上手门槛比uniapp高。从热度和实际出货量看uniapp在这类源码分发项目中更流行因为很多采购者本身有Web背景Vue的亲和力比WXMLJS原生更强。不过要注意uniapp虽然一套代码多端发布但支付、地图、蓝牙这类原生能力仍然要写条件编译的端差异代码别期待零改动。5.4 服务器最低配置与日常维护建议总有人问我家里的电脑能当服务器部署小程序吗。答案是能开发、能demo但不建议正式运营。家里电脑的IP随时变需要内网穿透断电断网直接影响业务微信后台要求合法域名且备案域名解析到家用宽带IP也会遇到端口封锁和备案风险。正规做法是上云服务器。这套系统按用户量和数据量估算初期配置选2核4G足够带宽按3M起步。数据库用MySQL 8.0Redis可选、但超时释放和缓存都能用。部署推荐用宝塔面板或Docker Compose前者对非专业运维友好后者方便迁移。日常维护关注三件事数据库定时备份每天一次冷备开启binlog、SSL证书自动续期腾讯云/阿里云免费证书一年一换、日志定期清理。小程序端如果连续出现客服投诉场地显示可订但下单失败第一时间查slot_occupancy表是否有残留脏数据而不是急着改代码。一些基于项目实践的真实心得这套分时计费在线预订场馆系统核心难度的排序和大多数人想的相反小程序端只是皮真正值钱的是分时计费规则引擎和并发锁场设计。固定时段模板唯一索引订单状态机这三板斧把90%以上的业务逻辑复杂度都锤平了。如果你是自己动手改源码我建议第一件事先读懂slot_occupancy表和订单状态迁移关系再去动页面。凡是改了订单状态而不同步场次占用的改动都会留下脏数据这是后续维护最糟心的问题。如果正在考虑用它作为自己场馆的运营工具可以从最小闭环跑起先上用户端下单支付商家端核销动态调价可以等到有真实需求数据再逐步开启。系统是为人服务的别让功能列表拖累运营节奏。