简介智慧预约系统小程序源码覆盖美容美发、医院、试乘试驾、家政、婚庆、活动、会议室、驾校、景区等百余种预约场景面向需要快速搭建线上预约平台的开发者、商家及系统集成方解决多行业服务预约管理难、客户等待时间长、线下排班效率低等问题。压缩包共2000个文件以1477个js逻辑脚本、310个css样式、154个json配置为主辅以少量html、md说明文档整体大小33.55MB目录结构清晰便于定位核心模块。目前已有72人学习下载源码内置预约查询、在线支付、用户权限管理等成熟功能并封装了数据库操作与支付接口对接模块可大幅缩短开发周期经严格测试运行稳定支持基于Nginx 1.20PHP7.2MySQL5.6环境直接部署。开发者既能快速上线通用预约服务也能针对美业、医疗、驾校等特定行业做二次开发预留的可扩展性便于后续迭代升级持续适配市场变化是低成本搭建专属预约服务平台的高性价比选择。1. 智慧预约系统小程序源码它到底解决的是哪类「预约」问题拿到「智慧预约系统小程序源码」这套工程很多人的第一反应是先看界面好不好看、页面多不多但真正让这类源码值钱的从来不是UI而是它背后对预约规则的抽象能力。所谓「适用于百余种预约场景」从工程角度翻译过来就是理发店按「技师时段」约、政务大厅按「窗口日期」约、健身馆按「场地场次」约、食堂按「餐别座位」约这些五花八门的业务拆到底层抽象后其实只有几个变量在变。如果你正打算快速搭建一套预约小程序或者你是一个被各种行业客户追着要「定制预约」的开发者这套源码能让你省掉最重复的那部分工作但也需要你先搞清它约束了哪些规则、哪些坑它管不着。本文不分析项目里的每个页面只按我落地这类系统的经验把预约建模、小程序端闭环、服务端防超约和改造避坑讲清楚。2. 预约规则建模先定日历与时间片再谈「百余种场景」怎么收敛2.1 预约场景为什么多拆开看只是正交参数在组合一百多种预约场景听着吓人但真正落到数据结构上它是由几个正交维度组合出来的。我做过一个统一的预约模型认为任何预约业务都能拆成「谁、约什么、什么时候用、用多久、要不要审核、收不收费」六个问题。谁就是用户身份和手机号约什么就是资源类型——工位、座位、设备、号源什么时候用是日期和时段用多久对应时间片粒度要不要审核对应订单状态机收不收费对应订单金额字段。把这六列放到一张配置表里每增加一列的可选值场景组合就成倍增长所谓百余种场景就是这些枚举值乘出来的。所以拿到一套「智慧预约系统小程序源码」第一个要去翻的地方不是小程序页面目录而是后端有没有一张「预约规则配置表」或者一个「场景配置类」。如果没有那这套源码大概率只写死了某一两种预约逻辑后面每接一个客户都要改代码如果有哪怕配置项粗糙后续扩展成本也会低一个量级。我一般建议的表结构分两张一张存预约资源门店/场馆/号源一张存预约规则时间段、名额、审核开关订单表再单独建。2.2 场景模板的字段设计一份 JSON 配置示例下面这份配置是我在多个项目里调得最顺的模板结构它同时覆盖了「按时段约」和「按场次约」两种主逻辑。放后端库里时可以直接存 JSON或者拆成字段看你的持久化习惯。{ ruleId: R20250301, resourceType: SEAT, timeGranularity: 30, timeSlots: [ { slotId: S1, start: 09:00, end: 09:30, capacity: 10 }, { slotId: S2, start: 09:30, end: 10:00, capacity: 0 }, { slotId: S3, start: 10:00, end: 10:30, capacity: 10 } ], allowFutureDays: 7, needReview: false, needPay: false, maxPerUserPerDay: 1, restDays: [2025-05-01, 2025-05-02] }参数说明timeGranularity是时间片的粒度分钟它决定了用户是从固定下拉时段里选还是自己选开始时间后系统帮你算结束时间。capacity: 0这个写法我建议保留它比删掉时段更利于前端展示「已约满」而不是直接消失让用户以为是系统 bug。allowFutureDays控制可预约天数是防止用户把未来一个月的号全占掉的关键参数政务、体检类场景一般只放 3 到 7 天。maxPerUserPerDay是同一用户单日预约上限不设这个字段靠人肉去防刷约基本防不住。restDays列表则是做节假日闭馆用的很多源码只在「周几」上做排除遇到法定节假日就要靠这个字段兜底。这段 JSON 定义好了之后你的服务端校验就只需要做一件事用户提交的预约请求必须能在这个规则表里找到一个合法的时间片并且那个时间片的剩余名额大于 0。前端怎么展示、怎么选反而都是次要的。3. 用微信小程序前端把预约流程跑通从「登录获取手机号」到「提单」的最小闭环3.1 微信小程序登录获取手机号别在授权弹窗上翻车任何预约类小程序第一步基本都是过微信登录。现在微信官方主推的是「手机号快速验证组件」也就是button open-typegetPhoneNumber这种方式。它是目前微信小程序登录获取手机号最省事的路径前提是你的小程序完成了微信认证且接口不是个人主体能开的。真机调试时开发者工具里经常表现正常但手机上一点就无反应这不是玄学多半是基础库版本太低或者你用了测试号——测试号不支持这个组件。button open-typegetPhoneNumber bind:getphonenumberhandleGetPhoneNumber classlogin-btn 微信一键登录 /button// pages/login/login.js Page({ handleGetPhoneNumber(e) { if (e.detail.errMsg ! getPhoneNumber:ok) { // 用户点取消或组件受限给出可回退的手动输入入口 wx.showToast({ title: 需要手机号完成预约, icon: none }); return; } const code e.detail.code; // 动态令牌五分钟有效 wx.login({ success(loginRes) { wx.request({ url: https://api.example.com/auth/phone, method: POST, data: { loginCode: loginRes.code, phoneCode: code }, success(res) { // 后端返回自定义登录态 token存入 storage wx.setStorageSync(token, res.data.token); wx.navigateBack(); } }); } }); } });逻辑说明e.detail.code是微信返回的临时凭证前端拿它和后端的wx.login的 code 一起发给服务端服务端再调微信接口换取手机号。很多新手直接把e.detail.phoneNumber拿来用结果发现大部分用户手机号被微信隐藏只返回脱敏的purePhoneNumber字段等于拿不到完整号码这就是翻车点。参数说明loginCode和phoneCode都建议在服务端限制为一次性使用五分钟后过期防止别人抓包后重放。token建议存storage并在每次请求的 header 里带上。这里必须提一句网上那些「小程序抓包」教程讲的就是抓这种登录和预约接口我强烈建议你在服务端加上签名校验和时间戳防重放而不是把接口裸奔出去。3.2 预约表单与提单动态标题、导航栏高度与日期选择预约页的功能很标准选日期、选时间片、填备注、提交。但两个小细节容易让页面看起来「业余」一是小程序顶部导航栏的高度不同机型尤其是 iPhone 带刘海屏的导航栏高度不一样用wx.getWindowInfo()拿到状态栏高度再计算比写死64px稳得多。二是页面标题很多预约场景需要根据资源名动态设置标题比如「某某理发店 - 预约」直接在onLoad里调用wx.setNavigationBarTitle即可不要在配置文件里写死。// pages/book/book.js const dayjs require(dayjs); Page({ data: { dateList: [], slotList: [], selectedSlot: null, resourceName: 标准预约 }, onLoad(options) { const { resourceId } options; // 动态设置标题避免每个页面都在 app.json 里写死 wx.setNavigationBarTitle({ title: this.data.resourceName - 预约 }); // 生成未来 7 天的日期列表对应 allowFutureDays const days []; for (let i 0; i 7; i) { days.push(dayjs().add(i, day).format(YYYY-MM-DD)); } this.setData({ dateList: days }); // 拉取某日期的可约时间片 this.fetchSlots(resourceId, days[0]); }, fetchSlots(resourceId, date) { wx.request({ url: https://api.example.com/slots, data: { resourceId, date }, success: (res) this.setData({ slotList: res.data.slots }) }); }, submitOrder() { const { resourceId, selectedSlot, dateList } this.data; if (!selectedSlot) { wx.showToast({ title: 请选择时间段, icon: none }); return; } wx.request({ url: https://api.example.com/orders, method: POST, header: { Authorization: wx.getStorageSync(token) }, data: { resourceId, date: dateList[0], slotId: selectedSlot.slotId }, success: (res) { if (res.data.code 0) { wx.showToast({ title: 预约成功 }); } else { wx.showToast({ title: res.data.msg, icon: none }); } } }); } });逻辑说明日期列表只做 7 天是因为后端规则里allowFutureDays就是 7前端不防的话用户选到第 8 天提交会被服务端拒绝体验很差。slotId是后端定义的标识前端不要自己拼时间字符串提交否则服务端的并发校验完全没有抓手。参数说明date统一用YYYY-MM-DD字符串别用Date对象直接传给后端序列化后时区容易出偏差。Authorization头里的 token 就是登录接口拿到的自定义登录态每次请求都要校验没有 token 一律 401。4. 服务端并发与防超约锁、库存和取消释放的三道关卡4.1 为什么高并发下预约会「超卖」预约系统的核心难点和电商秒杀一样是并发下名额不能超。两个人同时提交最后一个名额数据库的capacity字段如果只是简单「先查再减」两个请求都会读到剩余 1然后同时更新成 0最终两张订单都成功——这在预约场景里是最致命的 bug。更隐蔽的是预约系统的并发往往不是真的高而是「锁的粒度不对」造成的比如同一场馆下有 10 个时间段你把整个场馆的库存锁住了A 时段被抢时 B 时段的请求全部阻塞用户就觉得卡死。常见的做法是锁定范围精确到「资源 日期 时间片」这一行。用一个独立的库存表或者 Redis 键来存每个时间片的剩余量扣减时走原子操作而不是在订单表里做聚合查询。4.2 预占 超时释放一套落地的防超约写法下面这段是用 Node.js 配合 Redis 写的预占逻辑适合预约这种「先锁后下单」的交互。用户选定时间片后先预占库存预占成功后前端进入填写信息页倒计时结束没提交就自动释放。// services/bookingService.js const redis require(redis); const client redis.createClient({ url: redis://127.0.0.1:6379 }); const LOCK_PREFIX booking:slot:; const LOCK_TTL 120; // 预占锁 120 秒 async function reserveSlot(resourceId, date, slotId, userId) { const lockKey ${LOCK_PREFIX}${resourceId}:${date}:${slotId}; // 1. 用 Lua 脚本原子扣减防止并发读到同一个余量 const lua local current tonumber(redis.call(GET, KEYS[1]) or 0) if current 0 then return -1 end redis.call(DECR, KEYS[1]) redis.call(SET, KEYS[2], ARGV[1], EX, ARGV[2]) return current - 1 ; const result await client.eval(lua, { keys: [lockKey, ${lockKey}:holder], arguments: [userId, String(LOCK_TTL)] }); if (result -1) { throw new Error(该时段已被约满); } // 2. 给预占加一个定时释放的兜底防止用户不提交也不退出 setTimeout(async () { const holder await client.get(${lockKey}:holder); if (holder userId) { await client.incr(lockKey); // 归还库存 await client.del(${lockKey}:holder); } }, LOCK_TTL * 1000); return true; }逻辑说明Lua 脚本的核心是「检查当前库存是否大于 0再决定是否扣减」这两步在同一个脚本里执行Redis 单线程特性保证它原子。第二个键holder记录的是预占用户定时器释放时只归还该用户的锁避免 A 预占后超时、B 刚扣成功却被 A 的定时器误释放。参数说明LOCK_TTL是预占有效期120 秒是根据「从选时间到填完表单提交」的正常耗时定的太短用户来不及填太长会浪费库存。这个值建议做成配置项不同场景差别很大体检预约可能需要 10 分钟理发店 2 分钟足够。真正提交订单后要主动删掉${lockKey}:holder并把库存改成已使用不能跳过。4.3 取消预约的正确释放顺序取消预约比新增预约更容易写出 bug原因是顺序反了。很多人先改订单状态为「已取消」再归还库存——这中间如果归还库存失败名额就永久消失了用户还看不到任何异常整个时段的容量慢慢变成 0。正确顺序是先归还库存再更新订单状态如果库存归还成功但订单状态更新失败最多是用户还能再约一次比名额被吞要好处理得多。// services/bookingService.js async function cancelOrder(orderId, userId) { const order await db.getOrderById(orderId); if (order.userId ! userId) { throw new Error(无权取消他人订单); } const lockKey ${LOCK_PREFIX}${order.resourceId}:${order.date}:${order.slotId}; // 1. 归还库存 await client.incr(lockKey); // 2. 删除预占标记防止定时器二次归还 await client.del(${lockKey}:holder); // 3. 更新订单状态 await db.updateOrderStatus(orderId, CANCELLED); return true; }参数说明这里没有把两步放进事务是为了优先保证「名额释放成功」。实际项目中incr和updateOrderStatus之间如果进程崩溃会出现名额释放了但订单仍显示有效的情况这属于可以接受的数据不一致通过定时对账订单状态与库存总量来兜底即可。黑匣子一样的线上问题绝大多数都是这个释放顺序写反导致的。5. 源码改造避坑清单五处经常翻车的落地细节5.1 迁移动态令牌校验抓包重放被薅羊毛现象线上预约系统上线第一天有人用同一个请求反复提交把某个时段的名额全部占完但没有生成任何有效支付或核销记录。原因登录接口和预约接口都只校验了 token 是否有效没有校验 token 与请求体的绑定关系请求被工具重放后服务端无法识别。解决预约接口增加时间戳与签名参数sign md5(token timestamp slotId salt)服务端校验时间戳偏差不超过 5 分钟且 sign 正确从根上堵住重放。我在这套源码的二次开发中把签名校验单独抽了一个中间件所有写接口默认启用。5.2 前端绕过后端传「时段 ID」而不是传「时间字符串」现象用户通过抓包改成提交一个预约时间直接绕过下架的时间段在非开放时间预约成功。原因后端校验逻辑完全相信前端传来的startTime/endTime字符串没有去规则表里反查这个时段是否真实存在且可约。解决后端在创建订单时用前端传来的slotId去timeSlots配置里重新取一遍start和end前端传的任何时间字符串一律忽略。这是我反复强调的一条字段权限的事前端可以做后端不能不防。5.3 时区与日期存储不一致凌晨下单落在前一天现象凌晨 00:30 用户在手机端预约「今天」的号管理后台却显示成了「明天」。原因前端把new Date()直接传给后端后端把它当作 UTC 时间存储展示端再按本地时区转换导致跨时区/跨日时偏了一天。解决前后端约定所有日期参数用YYYY-MM-DD字符串、时间戳统一用毫秒存储固化用 UTC。预约日期这种业务字段不要用数据库的datetime类型去存「业务日期」用字符串类型存2025-06-01最不容易出错。5.4 微信手机号组件在开发者工具正常、真机失效现象开发者工具里点「微信一键登录」弹窗正常、能拿到 code真机上一按没反应或者弹窗一闪而过。原因手机号快速验证组件的接口能力依赖「已认证的小程序 基础库 2.21.2 以上」开发者工具默认模拟了认证环境而真机判断严格得多。解决先确认小程序已完成微信认证且非个人主体然后在app.json里把libVersion提到最新稳定版最后用真机调试而不是开发者工具预览。实在不行就降级为「手机号手动输入 短信验证码」体验差一点但胜在稳定。5.5 后端逻辑放前端校验规则被批量绕过现象服务端收到的预约并发一高就出现超约但本地压测怎么打都不超。原因防超约的capacity校验写在了前端 JavaScript 里后端只做了简单的INSERT没有对名额做原子扣减。解决库存扣减必须回到服务端 Redis 锁或数据库行锁上前端校验只是用户体验优化不能当业务防线。这个坑在拿开源小程序源码改造成完整系统时尤其常见因为很多源码为了让演示跑起来方便把大量逻辑塞进了前端。6. 把「百余种场景」落进参数配置一套模板切换不同预约业态预约模板化改造的最后一步是让运营人员改配置就能开新业务而不是每次找开发改代码。我常用的做法是在管理后台提供一个「预约模板」页面把第 2 章的 JSON 配置做成可视化表单保存后直接覆盖线上规则。下面这个配置片段展示了一个典型的「门诊分时段预约」模板和「健身房场地预约」模板的区别两者共用同一套底层接口只是参数不同{ clinic: { resourceType: NUMBER, timeGranularity: 15, needReview: false, needPay: true, allowFutureDays: 3, maxPerUserPerDay: 1 }, gym: { resourceType: FIELD, timeGranularity: 60, needReview: true, needPay: false, allowFutureDays: 7, maxPerUserPerDay: 2 } }参数说明门诊场景号源粒度 15 分钟、未来 3 天、付费健身场景场地粒度 60 分钟、未来 7 天、需要审核。前端拿到resourceType后切换表单渲染逻辑字段名不变只是展示组件不同。needReview打开后订单进入「待审核」状态管理后台要有审核列表审核通过后库存才真正扣减关闭则提交即扣减。配置化改造到位后验证方式也很简单后台新建一个模板改两个参数——timeGranularity和needReview——小程序端不动一行代码重新加载后预约页就按新时间片渲染了。我个人的习惯是每次上配置先开一个小流量测试资源约一轮真实用户再放量避免模板配置错误把正常业务流量带崩。这事我做下来最大的教训是预约系统源码的「智慧」不在界面多炫而在你愿意为规则抽象投入多少。把时间片、库存、审核、支付这几个正交变量想清楚一百种场景和一种场景的工程量差别远没有想象中大。希望帮到你。本文还有配套的精品资源点击获取