简介一款基于JavaScript和微信小程序的共享棋牌室、茶室、台球室等休闲场所管理小程序源码面向小程序开发者、共享经济创业者以及毕业设计人群重点解决自助预约、门店管理、多场景运营等实际问题。压缩包包含2000个文件体积约5.53MB主要涵盖JavaScript逻辑代码、TypeScript类型与业务代码、WXML页面模板、WXSS样式文件以及JSON配置、WXS视图脚本和PNG图片资源完整呈现小程序从界面到逻辑的项目结构。功能层面支持棋牌室、茶室、台球室的自助管理并可根据需要扩展私人影院、运动场馆、民宿等共享业态。对于学习小程序组件化开发、页面生命周期、配置与脚本协同具有直接参考价值模块划分清晰便于二次开发与课程设计。目前已有186人浏览学习适合作为共享经济类小程序的入门与进阶实战案例。1. 共享棋牌室小程序三个业态共用一套源码到底怎么落地共享棋牌室、茶室、台球室这类空间生意最近两年在一二线城市开得很快核心模式就是把闲置时段按小时拆开卖给附近的人。做一套支撑这种模式的小程序听上去要同时处理三种业态其实落到数据模型上就是“房间 时段 订单”这三件事。基于 JavaScript 和微信小程序的源码工程正是把这三件事封装成了一整套可以直接部署的方案用户端支持房间浏览、时段预约、在线支付商家端支持订单管理和房间状态维护。适合谁适合手里有场地资源想快速上线预约能力的商家也适合接私活或做毕业设计的开发者——前者关心能不能跑通后者关心代码怎么组织和扩展。2. 技术选型与工程结构JavaScript 与微信小程序的边界在哪里2.1 原生小程序框架 vs uni-app为什么这套源码选原生更稳标题写的是“基于 JavaScript 和微信小程序”这句话其实已经把技术栈定死了不是 React Native不是 Flutter就是微信原生小程序框架 JavaScript 逻辑层。很多人在选型时会纠结要不要上 uni-app因为一套代码能同时编译到支付宝小程序和 H5。但做共享空间预约这类强依赖微信生态的业务原生框架有三个不可替代的优势。第一是 API 的完整性和同步速度。微信小程序每次发版新能力都是原生框架第一时间支持比如 getPhoneNumber 的改版、地理位置接口的权限调整uni-app 这类跨端框架往往要等插件适配。第二是调试体验。原生工程在微信开发者工具里的报错堆栈是直白的 JavaScript 调用链而跨端框架打包后你看到的是编译中间层遇到“真机能跑但工具里报错”这种问题排查成本翻倍。第三是包体积。台球室预约要传球桌图片棋牌室要传包间照片原生分包加载控制起来最直接。这套源码的核心逻辑——房间状态管理、时段冲突校验、订单状态机——全部用 JavaScript 函数实现不依赖任何 UI 框架。这意味着你拿到手之后即使界面想全部重做底层那套易函数和数据处理逻辑可以直接搬。我一般会先看 utils 目录里有没有独立的 time.js 和 price.js如果有说明作者已经刻意把纯计算逻辑和页面渲染拆开了这种工程的可维护性比什么都写在 Page 里的要高一个档次。2.2 从 app.json 到页面 wxml读懂一份源码工程的目录调用链拿到任何一份小程序源码我建议按“全局配置 → 工具函数 → 页面 → 组件”的顺序去读而不是先翻页面。app.json 是入口它决定了你能看到几个页面、tabBar 怎么排、哪些页面参与了分包。共享棋牌室这类工程的 app.json 通常会注册五个主页面首页推荐位、房间列表、预约确认、订单中心、个人中心另外有一个管理员专用的页面打在分包里。一份典型的目录结构长这样project/ ├── app.js ├── app.json ├── app.wxss ├── utils/ │ ├── request.js // wx.request 的 Promise 封装 │ ├── time.js // 时段生成、冲突判断、日期格式化 │ └── price.js // 金额计算、优惠分摊、保留两位小数 ├── pages/ │ ├── index/ // 首页业态入口 │ ├── rooms/ // 房间列表按业态筛选 │ ├── booking/ // 预约确认页 │ ├── order/ // 订单列表与详情 │ └── mine/ // 个人中心登录与会员信息 ├── components/ │ └── time-picker/ // 可复用的时段选择器组件 └── images/这里的关键是 app.js 里的全局登录态处理。共享空间小程序需要拿到用户的 openid 才能下单常见做法是 app.js 在 onLaunch 时调用 wx.login再把 code 发给后端换 openid 和 token存进 globalData 和 storage。request.js 封装的是统一请求入口它会在每次请求的 header 里带上 token后端验 token 失败时统一返回 401前端收到 401 就跳转登录。这套链路在小程序里是标配但很多源码工程把 token 校验写在每个页面里改起来极其痛苦。2.3 数据规范化棋牌室、茶室、台球室共用一套订单模型三种业态看起来不同棋牌室按包间收费茶室有茶位费和茶叶费台球室按球桌计时。但如果每个业态建一套订单表后台管理会变成灾难。这一类源码工程的核心设计思路是抽象一个通用房间表和一个通用订单表。房间表建议至少包含这些字段room_id、name、type1棋牌、2茶室、3台球、status0空闲、1已预约、2维护、price_per_hour基准时价、capacity容纳人数、image_url。订单表包含order_id、room_id、user_openid、booking_date预约日期、start_minute开始分钟从0点起算、end_minute、total_amount、pay_status、create_time。用 start_minute 和 end_minute 而不是“09:00-12:00”这种字符串是为了让时段冲突校验能用纯数值比较这是整份源码里最重要的数据类型规范。JavaScript 在数据处理上的灵活性在这里正好发挥后端返回的字符串时间需要转成分钟数前端用 Number() 强转后端时间戳需要格式化展示用原生 Date 配合一个 formatTime 函数。标题相关的热搜里有“javascript判断数据类型”和“javascript保留两位小数”前者出现在校验接口返回值时后者出现在金额计算里。价格计算不要直接拿浮点数相加先转成分最后用 toFixed(2) 再转回元这条规则在 price.js 里应该被严格坚持。3. 核心预约链路实现房间列表、时段锁定、下单支付3.1 房间列表动态渲染wx:for 与房间状态字段的配合房间列表页是所有用户看到的第一个数据界面它的核心问题不是“怎么遍历”而是“状态怎么表达”。共享棋牌室小程序里一个房间当天可能被分成 4 个时段出售列表页展示的应该是房间当前可约状态而不是房间的历史订单。源码里通常的做法是后端提供 /rooms 接口返回房间基础信息再提供一个 /rooms/status?date2025-06-10 接口返回每个房间在指定日期已被占用的时段集合前端把它们合并后渲染。// pages/rooms/rooms.js Page({ data: { roomList: [], filterType: 0, // 0全部 1棋牌 2茶室 3台球 bookingDate: , loading: false, }, onLoad(options) { const today this.formatDate(new Date()); this.setData({ bookingDate: today }); this.fetchRooms(); }, onPullDownRefresh() { this.fetchRooms().finally(() wx.stopPullDownRefresh()); }, formatDate(date) { const y date.getFullYear(); const m String(date.getMonth() 1).padStart(2, 0); const d String(date.getDate()).padStart(2, 0); return ${y}-${m}-${d}; }, fetchRooms() { this.setData({ loading: true }); return new Promise((resolve, reject) { wx.request({ url: ${config.apiBase}/rooms, data: { type: this.data.filterType, date: this.data.bookingDate, }, success: (res) { if (res.data res.data.data) { this.setData({ roomList: res.data.data }); } resolve(); }, fail: (err) { wx.showToast({ title: 加载失败, icon: none }); reject(err); }, complete: () this.setData({ loading: false }), }); }); }, onTypeChange(e) { this.setData({ filterType: Number(e.detail.value) }); this.fetchRooms(); }, });!-- pages/rooms/rooms.wxml -- view classfilter-bar radio-group bindchangeonTypeChange labelradio value0 checked{{filterType 0}}/全部/label labelradio value1 checked{{filterType 1}}/棋牌室/label labelradio value2 checked{{filterType 2}}/茶室/label labelradio value3 checked{{filterType 3}}/台球室/label /radio-group /view view wx:for{{roomList}} wx:keyroom_id classroom-card image src{{item.image_url}} modeaspectFill / view classroom-info text classroom-name{{item.name}}/text text classroom-type{{item.type 1 ? 棋牌 : item.type 2 ? 茶室 : 台球}}/text text classroom-price¥{{item.price_per_hour}}/小时/text /view view classroom-status {{item.status 1 ? occupied : free}} {{item.status 1 ? 已约满 : 可预约}} /view /view逻辑说明fetchRooms 把类型筛选和日期作为请求参数而不是本地过滤这样后端可以直接用 SQL 条件查询避免把全量房间数据拉到前端再过滤。radio-group 的 bindchange 返回的是字符串类型用 Number() 强转后再赋值给 data 中的 filterType防止后续比较时出现 “1 1” 这种类型陷阱。wx:key 用的是 room_id 而不是 index保证列表局部刷新时组件的状态能正确复用。参数说明bookingDate 的格式必须是 YYYY-MM-DD这是后端做日期比较的统一约定status 字段中 0 表示可预约、1 表示当天时段全部被占。需要注意列表页显示“已约满”并不代表房间维护房间维护状态建议单独用一个字段维护避免商家下架房间和用户约满混淆。3.2 时段选择与冲突校验用纯 JavaScript 函数锁住时间片预约页是整个小程序里计算密度最高的页面。用户选了房间和日期后需要看到当天所有可约时段并且不能出现两个订单重叠。这部分的处理通常分为两步第一步拿到该房间当天已经卖出的全部时段数组第二步把可约时段算出来并让用户在界面上选择。已售时段是一组 [start_minute, end_minute] 的数组例如棋牌室营业时间是 10:00 到 02:00次日要注意跨天。编程时把一天切成 15 分钟粒度共 96 个时间片每个时间片标记是否被占用。源码里用一个纯 JavaScript 函数负责判断待选时段是否与已售时段冲突// utils/time.js /** * 判断新时段是否与已占用时段重叠 * param {Array} occupied 已占用的时段数组 [{start: 600, end: 720}] * param {Number} newStart 新的开始分钟数例如 10:00 - 600 * param {Number} newEnd 新的结束分钟数例如 11:00 - 660 * returns {Boolean} true 表示冲突 */ function isTimeConflict(occupied, newStart, newEnd) { if (!Array.isArray(occupied) || occupied.length 0) { return false; } return occupied.some((slot) { const start Number(slot.start); const end Number(slot.end); // 重叠条件新开始时间早于已有结束时间且新结束时间晚于已有开始时间 return newStart end newEnd start; }); } /** * 生成从 start 到 end 之间、步长为 step 分钟的时段列表 * 返回的每个时段都带上 formatted 展示字段 */ function generateTimeSlots(startMinute, endMinute, step 60) { const slots []; let cursor startMinute; while (cursor step endMinute) { slots.push({ start: cursor, end: cursor step, label: ${formatMinute(cursor)} - ${formatMinute(cursor step)}, }); cursor step; } return slots; } function formatMinute(minute) { const h String(Math.floor(minute / 60)).padStart(2, 0); const m String(minute % 60).padStart(2, 0); return ${h}:${m}; } module.exports { isTimeConflict, generateTimeSlots, formatMinute };逻辑说明isTimeConflict 是整份源码预约逻辑的地基。它采用开区间判断即新时段与占有时段的边界恰好接上比如前一个订单到 12:00 结束新订单从 12:00 开始不算冲突这样相邻订单可以背靠背排班不浪费任何一分钟。Number() 口袋处理防止后端返回字符串导致比较出错。参数说明generateTimeSlots 的 step 控制粒度棋牌室按小时排step 传 60茶室按半小时排step 传 30。跨天场景需要注意如果营业到次日凌晨 02:00实际结束分钟是 24*60 120 1560不能直接当天 0 点归零否则凌晨时段算不出来。这类源码里处理跨天通常用“加 1440 分钟后再取模”的技巧我在踩坑章节会专门讲。3.3 下单支付链路wx.requestPayment 与回调兜底用户选好时段点击提交前端先调后端 /orders/prepay 接口后端创建订单并返回支付参数前端拿到参数后调 wx.requestPayment 拉起收银台。这里的顺序不能反很多源码把创建订单和发起支付混在一个接口里导致支付失败时订单已经生成用户重试时产生重复预约。// utils/payment.js function requestPayment(orderId) { return new Promise((resolve, reject) { wx.request({ url: ${config.apiBase}/orders/${orderId}/prepay, method: POST, success: (res) { const pay res.data.data; if (!pay || !pay.packageValue) { reject(new Error(支付参数为空)); return; } wx.requestPayment({ timeStamp: String(pay.timeStamp), nonceStr: pay.nonceStr, package: pay.packageValue, // 注意这个参数名是 package不能覆盖写 signType: pay.signType || RSA, paySign: pay.paySign, success: (payRes) { // 以后端 notify 或主动查询为准 verifyOrderPaid(orderId).then(() resolve(payRes)); }, fail: (err) { // 用户取消或支付失败订单留在“待支付”状态 reject(err); }, }); }, fail: reject, }); }); } function verifyOrderPaid(orderId) { return new Promise((resolve, reject) { wx.request({ url: ${config.apiBase}/orders/${orderId}, method: GET, success: (res) { const order res.data.data; if (order.pay_status 1) { resolve(order); } else { req一旦没有支付成功需要把订单状态回退 reject(new Error(未支付)); } }, fail: reject, }); }); }逻辑说明verifyOrderPaid 是为了解决“支付成功但前端回调丢失”的经典问题。wx.requestPayment 的 success 回调在用户完成指纹支付后立即触发但它只代表收银台关闭不代表后端已经收到微信的支付结果通知。可靠做法是支付成功后再查一次订单状态以 pay_status 1 作为最终判断依据。参数说明timeStamp 是字符串类型必须用 String() 包一层否则部分版本的小程序在 iOS 上会签名校验失败。package 字段在小程序里是保留字接口返回的字段名如果是 package赋值时要用一个中间变量比如 packageValue再拆出 package: pay.packageValue。signType 可以留空走后端默认但显式传 RSA 更稳。到这里用户端的核心链路就通了浏览列表、选时段、提交预支付、确认支付。接下来是商家端和管理员逻辑这部分源码工程里往往被单独放在分包里原因很现实商家并不需要每天打开小程序把管理页打进主包会白白增加首包体积。4. 避坑指南共享空间小程序最容易翻车的 5 个环节4.1 真机下拉刷新白屏页面数据困难户现象在开发者工具里下拉刷新一切正常但真机上连续快速下拉两次页面变成白屏控制台报 setData 调用过于频繁。原因onPullDownRefresh 里调用 fetchRooms 时loading 状态被 setData 反复更新同时 wx.stopPullDownRefresh() 在请求未完成时就先执行了第二次下拉触发时上一个请求还挂着两个请求同时 setData 同一块数据区域小程序渲染层直接卡死。解决给 fetchRooms 加一个模块级的 isRequesting 锁请求未结束时直接忽略新的触发stopPullDownRefresh 放在 finally 里执行保证请求完成后才收掉下拉动画。还有一个细节房间列表图片多时下拉刷新应该先展示占位骨架而不是空页面否则视觉上像白屏。4.2 支付回调不触发订单状态停留在“待支付”现象用户付完钱前端 success 回调也走了但直播间后台的订单状态还是待支付用户以为没付成功又付了一次。原因前端把 wx.requestPayment 的 success 当成了支付成功的最终依据。实际上微信支付的成功判定以后端收到支付结果回调为准这个回调可能延迟几秒甚至十几秒而且如果后端没有正确响应微信的回调请求微信会连续重试多次后放弃。解决支付成功后前端轮询订单接口查状态轮询次数不要超过 5 次间隔 1 到 2 秒。如果轮询结束仍未支付成功提示用户“支付结果确认中请稍后查看订单”不要直接跳转成功页。后端那边需要在收到微信回调时先校验订单金额再返回 XML 格式的成功应答这点源码工程里如果没写你必须自己补上。4.3 并发抢单导致房间状态错乱现象热门时段的棋牌室包间两个用户在同一个时间点击预约后端都校验了时段未冲突最后都创建了订单超卖。原因按下单接口在做时段冲突校验时只查了数据库里已存在的订单而没有对“查询 插入”这个复合操作加锁。两个请求同时查询发现都没有冲突然后同时插入于是同一时段被卖了两遍。解决后端接口必须使用数据库事务或者在订单表上对 room_id 和时段字段建唯一索引。具体来说就是room_id、booking_date、start_minute 三个字段组合唯一插入时捕获 1062 重复键错误并提示“该时段已被抢占”。数据库层面锁住之后前端即使并发点击也只会有一个请求成功。小程序前端还可以做一层互斥提交按钮点击后立即变为 loading 并禁用直到回调返回。4.4 审核被拒类目、隐私接口与机器行为检测现象小程序提审被驳回理由是“涉及预约服务但未选择正确类目”或“使用 getUserProfile 获取用户信息但未在后台声明”。原因持牌棋牌室、茶室、台球室这类线下场所在微信小程序的类目里通常要选“工具 - 预约”或“生活服务 - 休闲娱乐”不同地区服务类目资质要求不同。另外getUserProfile 和 getPhoneNumber 属于隐私接口小程序后台必须在“设置 - 服务内容声明”里说明收集目的否则代码里一旦调用就会被审核机拦截。解决提审前先看小程序后台的“类目管理”确认所选类目和实际提供服务的匹配度。getUserProfile 能不用就不用改用它 username 和 openid 组合识别用户。getPhoneNumber 强依赖企业认证主体个人主体小程序无法使用源码里如果写着 getPhoneNumber接私活时一定要先确认客户的主体类型。4.5 多业态混合订单字段不够用现象一个茶室订单里面既有小时的包间费又有按人收的茶位费还有茶叶选品的加价你却只有一个 total_amount 字段后台核算时对不上账。原因初始订单表设计时没有预留扩展位三个业态的成本结构差异在数据结构上被抹平了。棋牌室只有包间费台球室只有台费但茶室天然是“茶位费 商品费”的组合。解决订单表增加 amount_detail 字段存 JSON 字符串里面放一个明细数组例如 [{item: 包间2小时, amount: 120}, {item: 茶水(龙井), amount: 48}]total_amount 作为冗余只用于支付展示。JavaScript 里用 JSON.parse 解析后端接口返回时直接透传这个字段前端在订单详情页遍历渲染。这类源码工程如果一开始就把 amount_detail 设计成字符串说明作者踩过这个坑没有的话你就得自己补上。5. 从能跑到能用登录复用、数据埋点与验证顺序小程序能做出来和能上线中间还隔着一层“运营能不能用”。我接手这类源码工程后的第一件事往往是把登录逻辑和埋点逻辑重写一遍这两块是决定一个空间预约产品能不能持续运营的关键。登录复用这块getPhoneNumber 是目前最可靠的实人识别方案。具体流程是用户点击授权手机号按钮小程序获取到加密的 code后端把这个 code 通过微信接口换成手机号然后绑定到用户的 openid 上。绑定之后用户再次进来时不用重复授权前端直接拿 storage 里的 token 判断已登录。要注意这一步必须走后端不能在前端直接解析手机号。这台逻辑里最容易被忽略的是用户规模增长后 token 过期的问题每次请求响应 401 时应当静默调用 wx.login 换新 token不要弹窗打扰用户。数据埋点是另一个容易被忽略的模块。小程序自带 wx.reportAnalytics 接口可以为每个事件上报最多 40 个字段我会至少埋三个事件room_view房间曝光、booking_submit发起预约、booking_paid下单支付。这三个事件闭环下来就能算出用户从看到房间到完成支付的核心转化率比看后台的订单总数有用得多。验证顺序上我建议先在小程序开发者工具里跑通预约链路再上真机预览最后申请体验版给商家管理员试用一周重点看商家端在弱网环境下的表现。棋盘室店里面网络信号普遍不好接口请求超时后的重试机制和订单状态的本地缓存是实际运营中比花哨 UI 更重要的东西。我自己的习惯是拿到一份源码先不急着改功能而是把测试账号的预约流程完整跑十遍其中三遍刻意用两台手机同时抢同一个时段。跑通过再谈加需求。希望帮到你。本文还有配套的精品资源点击获取
共享棋牌室小程序源码解析：JavaScript与微信预约系统落地
简介一款基于JavaScript和微信小程序的共享棋牌室、茶室、台球室等休闲场所管理小程序源码面向小程序开发者、共享经济创业者以及毕业设计人群重点解决自助预约、门店管理、多场景运营等实际问题。压缩包包含2000个文件体积约5.53MB主要涵盖JavaScript逻辑代码、TypeScript类型与业务代码、WXML页面模板、WXSS样式文件以及JSON配置、WXS视图脚本和PNG图片资源完整呈现小程序从界面到逻辑的项目结构。功能层面支持棋牌室、茶室、台球室的自助管理并可根据需要扩展私人影院、运动场馆、民宿等共享业态。对于学习小程序组件化开发、页面生命周期、配置与脚本协同具有直接参考价值模块划分清晰便于二次开发与课程设计。目前已有186人浏览学习适合作为共享经济类小程序的入门与进阶实战案例。1. 共享棋牌室小程序三个业态共用一套源码到底怎么落地共享棋牌室、茶室、台球室这类空间生意最近两年在一二线城市开得很快核心模式就是把闲置时段按小时拆开卖给附近的人。做一套支撑这种模式的小程序听上去要同时处理三种业态其实落到数据模型上就是“房间 时段 订单”这三件事。基于 JavaScript 和微信小程序的源码工程正是把这三件事封装成了一整套可以直接部署的方案用户端支持房间浏览、时段预约、在线支付商家端支持订单管理和房间状态维护。适合谁适合手里有场地资源想快速上线预约能力的商家也适合接私活或做毕业设计的开发者——前者关心能不能跑通后者关心代码怎么组织和扩展。2. 技术选型与工程结构JavaScript 与微信小程序的边界在哪里2.1 原生小程序框架 vs uni-app为什么这套源码选原生更稳标题写的是“基于 JavaScript 和微信小程序”这句话其实已经把技术栈定死了不是 React Native不是 Flutter就是微信原生小程序框架 JavaScript 逻辑层。很多人在选型时会纠结要不要上 uni-app因为一套代码能同时编译到支付宝小程序和 H5。但做共享空间预约这类强依赖微信生态的业务原生框架有三个不可替代的优势。第一是 API 的完整性和同步速度。微信小程序每次发版新能力都是原生框架第一时间支持比如 getPhoneNumber 的改版、地理位置接口的权限调整uni-app 这类跨端框架往往要等插件适配。第二是调试体验。原生工程在微信开发者工具里的报错堆栈是直白的 JavaScript 调用链而跨端框架打包后你看到的是编译中间层遇到“真机能跑但工具里报错”这种问题排查成本翻倍。第三是包体积。台球室预约要传球桌图片棋牌室要传包间照片原生分包加载控制起来最直接。这套源码的核心逻辑——房间状态管理、时段冲突校验、订单状态机——全部用 JavaScript 函数实现不依赖任何 UI 框架。这意味着你拿到手之后即使界面想全部重做底层那套易函数和数据处理逻辑可以直接搬。我一般会先看 utils 目录里有没有独立的 time.js 和 price.js如果有说明作者已经刻意把纯计算逻辑和页面渲染拆开了这种工程的可维护性比什么都写在 Page 里的要高一个档次。2.2 从 app.json 到页面 wxml读懂一份源码工程的目录调用链拿到任何一份小程序源码我建议按“全局配置 → 工具函数 → 页面 → 组件”的顺序去读而不是先翻页面。app.json 是入口它决定了你能看到几个页面、tabBar 怎么排、哪些页面参与了分包。共享棋牌室这类工程的 app.json 通常会注册五个主页面首页推荐位、房间列表、预约确认、订单中心、个人中心另外有一个管理员专用的页面打在分包里。一份典型的目录结构长这样project/ ├── app.js ├── app.json ├── app.wxss ├── utils/ │ ├── request.js // wx.request 的 Promise 封装 │ ├── time.js // 时段生成、冲突判断、日期格式化 │ └── price.js // 金额计算、优惠分摊、保留两位小数 ├── pages/ │ ├── index/ // 首页业态入口 │ ├── rooms/ // 房间列表按业态筛选 │ ├── booking/ // 预约确认页 │ ├── order/ // 订单列表与详情 │ └── mine/ // 个人中心登录与会员信息 ├── components/ │ └── time-picker/ // 可复用的时段选择器组件 └── images/这里的关键是 app.js 里的全局登录态处理。共享空间小程序需要拿到用户的 openid 才能下单常见做法是 app.js 在 onLaunch 时调用 wx.login再把 code 发给后端换 openid 和 token存进 globalData 和 storage。request.js 封装的是统一请求入口它会在每次请求的 header 里带上 token后端验 token 失败时统一返回 401前端收到 401 就跳转登录。这套链路在小程序里是标配但很多源码工程把 token 校验写在每个页面里改起来极其痛苦。2.3 数据规范化棋牌室、茶室、台球室共用一套订单模型三种业态看起来不同棋牌室按包间收费茶室有茶位费和茶叶费台球室按球桌计时。但如果每个业态建一套订单表后台管理会变成灾难。这一类源码工程的核心设计思路是抽象一个通用房间表和一个通用订单表。房间表建议至少包含这些字段room_id、name、type1棋牌、2茶室、3台球、status0空闲、1已预约、2维护、price_per_hour基准时价、capacity容纳人数、image_url。订单表包含order_id、room_id、user_openid、booking_date预约日期、start_minute开始分钟从0点起算、end_minute、total_amount、pay_status、create_time。用 start_minute 和 end_minute 而不是“09:00-12:00”这种字符串是为了让时段冲突校验能用纯数值比较这是整份源码里最重要的数据类型规范。JavaScript 在数据处理上的灵活性在这里正好发挥后端返回的字符串时间需要转成分钟数前端用 Number() 强转后端时间戳需要格式化展示用原生 Date 配合一个 formatTime 函数。标题相关的热搜里有“javascript判断数据类型”和“javascript保留两位小数”前者出现在校验接口返回值时后者出现在金额计算里。价格计算不要直接拿浮点数相加先转成分最后用 toFixed(2) 再转回元这条规则在 price.js 里应该被严格坚持。3. 核心预约链路实现房间列表、时段锁定、下单支付3.1 房间列表动态渲染wx:for 与房间状态字段的配合房间列表页是所有用户看到的第一个数据界面它的核心问题不是“怎么遍历”而是“状态怎么表达”。共享棋牌室小程序里一个房间当天可能被分成 4 个时段出售列表页展示的应该是房间当前可约状态而不是房间的历史订单。源码里通常的做法是后端提供 /rooms 接口返回房间基础信息再提供一个 /rooms/status?date2025-06-10 接口返回每个房间在指定日期已被占用的时段集合前端把它们合并后渲染。// pages/rooms/rooms.js Page({ data: { roomList: [], filterType: 0, // 0全部 1棋牌 2茶室 3台球 bookingDate: , loading: false, }, onLoad(options) { const today this.formatDate(new Date()); this.setData({ bookingDate: today }); this.fetchRooms(); }, onPullDownRefresh() { this.fetchRooms().finally(() wx.stopPullDownRefresh()); }, formatDate(date) { const y date.getFullYear(); const m String(date.getMonth() 1).padStart(2, 0); const d String(date.getDate()).padStart(2, 0); return ${y}-${m}-${d}; }, fetchRooms() { this.setData({ loading: true }); return new Promise((resolve, reject) { wx.request({ url: ${config.apiBase}/rooms, data: { type: this.data.filterType, date: this.data.bookingDate, }, success: (res) { if (res.data res.data.data) { this.setData({ roomList: res.data.data }); } resolve(); }, fail: (err) { wx.showToast({ title: 加载失败, icon: none }); reject(err); }, complete: () this.setData({ loading: false }), }); }); }, onTypeChange(e) { this.setData({ filterType: Number(e.detail.value) }); this.fetchRooms(); }, });!-- pages/rooms/rooms.wxml -- view classfilter-bar radio-group bindchangeonTypeChange labelradio value0 checked{{filterType 0}}/全部/label labelradio value1 checked{{filterType 1}}/棋牌室/label labelradio value2 checked{{filterType 2}}/茶室/label labelradio value3 checked{{filterType 3}}/台球室/label /radio-group /view view wx:for{{roomList}} wx:keyroom_id classroom-card image src{{item.image_url}} modeaspectFill / view classroom-info text classroom-name{{item.name}}/text text classroom-type{{item.type 1 ? 棋牌 : item.type 2 ? 茶室 : 台球}}/text text classroom-price¥{{item.price_per_hour}}/小时/text /view view classroom-status {{item.status 1 ? occupied : free}} {{item.status 1 ? 已约满 : 可预约}} /view /view逻辑说明fetchRooms 把类型筛选和日期作为请求参数而不是本地过滤这样后端可以直接用 SQL 条件查询避免把全量房间数据拉到前端再过滤。radio-group 的 bindchange 返回的是字符串类型用 Number() 强转后再赋值给 data 中的 filterType防止后续比较时出现 “1 1” 这种类型陷阱。wx:key 用的是 room_id 而不是 index保证列表局部刷新时组件的状态能正确复用。参数说明bookingDate 的格式必须是 YYYY-MM-DD这是后端做日期比较的统一约定status 字段中 0 表示可预约、1 表示当天时段全部被占。需要注意列表页显示“已约满”并不代表房间维护房间维护状态建议单独用一个字段维护避免商家下架房间和用户约满混淆。3.2 时段选择与冲突校验用纯 JavaScript 函数锁住时间片预约页是整个小程序里计算密度最高的页面。用户选了房间和日期后需要看到当天所有可约时段并且不能出现两个订单重叠。这部分的处理通常分为两步第一步拿到该房间当天已经卖出的全部时段数组第二步把可约时段算出来并让用户在界面上选择。已售时段是一组 [start_minute, end_minute] 的数组例如棋牌室营业时间是 10:00 到 02:00次日要注意跨天。编程时把一天切成 15 分钟粒度共 96 个时间片每个时间片标记是否被占用。源码里用一个纯 JavaScript 函数负责判断待选时段是否与已售时段冲突// utils/time.js /** * 判断新时段是否与已占用时段重叠 * param {Array} occupied 已占用的时段数组 [{start: 600, end: 720}] * param {Number} newStart 新的开始分钟数例如 10:00 - 600 * param {Number} newEnd 新的结束分钟数例如 11:00 - 660 * returns {Boolean} true 表示冲突 */ function isTimeConflict(occupied, newStart, newEnd) { if (!Array.isArray(occupied) || occupied.length 0) { return false; } return occupied.some((slot) { const start Number(slot.start); const end Number(slot.end); // 重叠条件新开始时间早于已有结束时间且新结束时间晚于已有开始时间 return newStart end newEnd start; }); } /** * 生成从 start 到 end 之间、步长为 step 分钟的时段列表 * 返回的每个时段都带上 formatted 展示字段 */ function generateTimeSlots(startMinute, endMinute, step 60) { const slots []; let cursor startMinute; while (cursor step endMinute) { slots.push({ start: cursor, end: cursor step, label: ${formatMinute(cursor)} - ${formatMinute(cursor step)}, }); cursor step; } return slots; } function formatMinute(minute) { const h String(Math.floor(minute / 60)).padStart(2, 0); const m String(minute % 60).padStart(2, 0); return ${h}:${m}; } module.exports { isTimeConflict, generateTimeSlots, formatMinute };逻辑说明isTimeConflict 是整份源码预约逻辑的地基。它采用开区间判断即新时段与占有时段的边界恰好接上比如前一个订单到 12:00 结束新订单从 12:00 开始不算冲突这样相邻订单可以背靠背排班不浪费任何一分钟。Number() 口袋处理防止后端返回字符串导致比较出错。参数说明generateTimeSlots 的 step 控制粒度棋牌室按小时排step 传 60茶室按半小时排step 传 30。跨天场景需要注意如果营业到次日凌晨 02:00实际结束分钟是 24*60 120 1560不能直接当天 0 点归零否则凌晨时段算不出来。这类源码里处理跨天通常用“加 1440 分钟后再取模”的技巧我在踩坑章节会专门讲。3.3 下单支付链路wx.requestPayment 与回调兜底用户选好时段点击提交前端先调后端 /orders/prepay 接口后端创建订单并返回支付参数前端拿到参数后调 wx.requestPayment 拉起收银台。这里的顺序不能反很多源码把创建订单和发起支付混在一个接口里导致支付失败时订单已经生成用户重试时产生重复预约。// utils/payment.js function requestPayment(orderId) { return new Promise((resolve, reject) { wx.request({ url: ${config.apiBase}/orders/${orderId}/prepay, method: POST, success: (res) { const pay res.data.data; if (!pay || !pay.packageValue) { reject(new Error(支付参数为空)); return; } wx.requestPayment({ timeStamp: String(pay.timeStamp), nonceStr: pay.nonceStr, package: pay.packageValue, // 注意这个参数名是 package不能覆盖写 signType: pay.signType || RSA, paySign: pay.paySign, success: (payRes) { // 以后端 notify 或主动查询为准 verifyOrderPaid(orderId).then(() resolve(payRes)); }, fail: (err) { // 用户取消或支付失败订单留在“待支付”状态 reject(err); }, }); }, fail: reject, }); }); } function verifyOrderPaid(orderId) { return new Promise((resolve, reject) { wx.request({ url: ${config.apiBase}/orders/${orderId}, method: GET, success: (res) { const order res.data.data; if (order.pay_status 1) { resolve(order); } else { req一旦没有支付成功需要把订单状态回退 reject(new Error(未支付)); } }, fail: reject, }); }); }逻辑说明verifyOrderPaid 是为了解决“支付成功但前端回调丢失”的经典问题。wx.requestPayment 的 success 回调在用户完成指纹支付后立即触发但它只代表收银台关闭不代表后端已经收到微信的支付结果通知。可靠做法是支付成功后再查一次订单状态以 pay_status 1 作为最终判断依据。参数说明timeStamp 是字符串类型必须用 String() 包一层否则部分版本的小程序在 iOS 上会签名校验失败。package 字段在小程序里是保留字接口返回的字段名如果是 package赋值时要用一个中间变量比如 packageValue再拆出 package: pay.packageValue。signType 可以留空走后端默认但显式传 RSA 更稳。到这里用户端的核心链路就通了浏览列表、选时段、提交预支付、确认支付。接下来是商家端和管理员逻辑这部分源码工程里往往被单独放在分包里原因很现实商家并不需要每天打开小程序把管理页打进主包会白白增加首包体积。4. 避坑指南共享空间小程序最容易翻车的 5 个环节4.1 真机下拉刷新白屏页面数据困难户现象在开发者工具里下拉刷新一切正常但真机上连续快速下拉两次页面变成白屏控制台报 setData 调用过于频繁。原因onPullDownRefresh 里调用 fetchRooms 时loading 状态被 setData 反复更新同时 wx.stopPullDownRefresh() 在请求未完成时就先执行了第二次下拉触发时上一个请求还挂着两个请求同时 setData 同一块数据区域小程序渲染层直接卡死。解决给 fetchRooms 加一个模块级的 isRequesting 锁请求未结束时直接忽略新的触发stopPullDownRefresh 放在 finally 里执行保证请求完成后才收掉下拉动画。还有一个细节房间列表图片多时下拉刷新应该先展示占位骨架而不是空页面否则视觉上像白屏。4.2 支付回调不触发订单状态停留在“待支付”现象用户付完钱前端 success 回调也走了但直播间后台的订单状态还是待支付用户以为没付成功又付了一次。原因前端把 wx.requestPayment 的 success 当成了支付成功的最终依据。实际上微信支付的成功判定以后端收到支付结果回调为准这个回调可能延迟几秒甚至十几秒而且如果后端没有正确响应微信的回调请求微信会连续重试多次后放弃。解决支付成功后前端轮询订单接口查状态轮询次数不要超过 5 次间隔 1 到 2 秒。如果轮询结束仍未支付成功提示用户“支付结果确认中请稍后查看订单”不要直接跳转成功页。后端那边需要在收到微信回调时先校验订单金额再返回 XML 格式的成功应答这点源码工程里如果没写你必须自己补上。4.3 并发抢单导致房间状态错乱现象热门时段的棋牌室包间两个用户在同一个时间点击预约后端都校验了时段未冲突最后都创建了订单超卖。原因按下单接口在做时段冲突校验时只查了数据库里已存在的订单而没有对“查询 插入”这个复合操作加锁。两个请求同时查询发现都没有冲突然后同时插入于是同一时段被卖了两遍。解决后端接口必须使用数据库事务或者在订单表上对 room_id 和时段字段建唯一索引。具体来说就是room_id、booking_date、start_minute 三个字段组合唯一插入时捕获 1062 重复键错误并提示“该时段已被抢占”。数据库层面锁住之后前端即使并发点击也只会有一个请求成功。小程序前端还可以做一层互斥提交按钮点击后立即变为 loading 并禁用直到回调返回。4.4 审核被拒类目、隐私接口与机器行为检测现象小程序提审被驳回理由是“涉及预约服务但未选择正确类目”或“使用 getUserProfile 获取用户信息但未在后台声明”。原因持牌棋牌室、茶室、台球室这类线下场所在微信小程序的类目里通常要选“工具 - 预约”或“生活服务 - 休闲娱乐”不同地区服务类目资质要求不同。另外getUserProfile 和 getPhoneNumber 属于隐私接口小程序后台必须在“设置 - 服务内容声明”里说明收集目的否则代码里一旦调用就会被审核机拦截。解决提审前先看小程序后台的“类目管理”确认所选类目和实际提供服务的匹配度。getUserProfile 能不用就不用改用它 username 和 openid 组合识别用户。getPhoneNumber 强依赖企业认证主体个人主体小程序无法使用源码里如果写着 getPhoneNumber接私活时一定要先确认客户的主体类型。4.5 多业态混合订单字段不够用现象一个茶室订单里面既有小时的包间费又有按人收的茶位费还有茶叶选品的加价你却只有一个 total_amount 字段后台核算时对不上账。原因初始订单表设计时没有预留扩展位三个业态的成本结构差异在数据结构上被抹平了。棋牌室只有包间费台球室只有台费但茶室天然是“茶位费 商品费”的组合。解决订单表增加 amount_detail 字段存 JSON 字符串里面放一个明细数组例如 [{item: 包间2小时, amount: 120}, {item: 茶水(龙井), amount: 48}]total_amount 作为冗余只用于支付展示。JavaScript 里用 JSON.parse 解析后端接口返回时直接透传这个字段前端在订单详情页遍历渲染。这类源码工程如果一开始就把 amount_detail 设计成字符串说明作者踩过这个坑没有的话你就得自己补上。5. 从能跑到能用登录复用、数据埋点与验证顺序小程序能做出来和能上线中间还隔着一层“运营能不能用”。我接手这类源码工程后的第一件事往往是把登录逻辑和埋点逻辑重写一遍这两块是决定一个空间预约产品能不能持续运营的关键。登录复用这块getPhoneNumber 是目前最可靠的实人识别方案。具体流程是用户点击授权手机号按钮小程序获取到加密的 code后端把这个 code 通过微信接口换成手机号然后绑定到用户的 openid 上。绑定之后用户再次进来时不用重复授权前端直接拿 storage 里的 token 判断已登录。要注意这一步必须走后端不能在前端直接解析手机号。这台逻辑里最容易被忽略的是用户规模增长后 token 过期的问题每次请求响应 401 时应当静默调用 wx.login 换新 token不要弹窗打扰用户。数据埋点是另一个容易被忽略的模块。小程序自带 wx.reportAnalytics 接口可以为每个事件上报最多 40 个字段我会至少埋三个事件room_view房间曝光、booking_submit发起预约、booking_paid下单支付。这三个事件闭环下来就能算出用户从看到房间到完成支付的核心转化率比看后台的订单总数有用得多。验证顺序上我建议先在小程序开发者工具里跑通预约链路再上真机预览最后申请体验版给商家管理员试用一周重点看商家端在弱网环境下的表现。棋盘室店里面网络信号普遍不好接口请求超时后的重试机制和订单状态的本地缓存是实际运营中比花哨 UI 更重要的东西。我自己的习惯是拿到一份源码先不急着改功能而是把测试账号的预约流程完整跑十遍其中三遍刻意用两台手机同时抢同一个时段。跑通过再谈加需求。希望帮到你。本文还有配套的精品资源点击获取