简介：一套完整的会议室预订预约小程序前后台源码，专为写字楼、高校、创业园等场景设计，面向有会议室在线预约与管理需求的企业和技术开发者。压缩包为rar格式，共1185个文件，以wxml、wxss、js、ts、json等小程序前端代码为主，同时包含原生PHP后台源码，整体体积约1021KB。源码覆盖用户端预约查询、后台会议室资源管理、预订记录维护、二维码现场核销等完整流程，前端界面友好、操作路径清晰，后端不依赖第三方框架，业务逻辑易读。通过该源码可快速了解小程序预约系统与PHP后台的联动实现，也能作为二次开发或毕业设计、课程设计的基础工程。发布至今已有4145人学习下载，适合小程序开发者、PHP工程师和项目负责人参考学习。
会议室预订预约小程序，前后台源码，我是怎么从零搭起来的
搞了几年小程序开发，接过的需求里会议室预订算是被问得最多的一类。小公司十来个工位配两三间会议室，大厂动辄几十层楼上百间会议室，场景不同但核心痛点一模一样：不预定就撞车，撞了车就扯皮，扯完皮行政还得手动排表，所有人都烦。所以这次我干脆把我做的一套会议室预订预约小程序前后台源码方案整理出来，从前台预订、后台管理、数据库设计到服务端接口，该说的坑和该给的代码都放在里面，给想自己部署或者拿来二次开发的朋友当个参考。
这套东西的运行模式不复杂：用户打开微信小程序，看会议室空闲表，选时间选会议室，提交预约，后台管理员审核或自动确认，到点扫码开门，用完签退释放。典型的前后端分离结构，小程序端做交互，服务端做业务逻辑，管理端管配置和审批，再挂一个 Redis 处理时间片冲突校验。文中的方案是我实际跑过的，用的技术栈偏主流，即便你手上团队的技术栈不一样，把思路和关键代码移植过去也不需要伤筋动骨。
1. 需求梳理与整体方案设计：不只是做个日历那么简单
1.1 “前后台源码”到底包含哪几块
很多人一听到“前后台源码”第一反应是“小程序端代码 + 管理后台”，这个理解不够全。真正要落地的会议室预订项目，至少得有四块内容：用户端小程序（预订入口）、管理后台（可视化配置、审批、统计）、服务端接口层（业务逻辑与数据持久化的承载者）、以及一个常驻任务层（用来处理会议开始前的通知、超时未签到的释放、定时会议自动预订等）。
菜单级别的东西好说，真正的复杂度在业务规则上——谁来订、能订多久、是否可以跨天、要不要审批、是否收费、是否关联门禁、和钉钉或企业微信的组织架构要不要打通。不同的决策直接决定了数据库怎么设计，消息通知走哪个通道。所以第一步我建议先定两个核心问题：第一，会议室是不是稀缺资源；第二，公司有没有行政人员愿意做人工审批。这俩问题定下来，后面的方案基本不会跑偏。
我做的是假设中型公司，会议室资源偏紧张，允许多人并行预订但同一时间段同一会议室互斥，管理员可以在后台按需调整会议室状态、修改预约、拉统计报表。审批流程做了“免审+需审”两种模式，可按会议室类别区分，比如高管专用会议室走自动通过，普通洽谈间全自动，培训教室需管理员二次确认。
1.2 为什么选微信小程序而非 App 或 H5
这是个绕不开的问题。会议室预订的场景决定了用户不在电脑前，他们要么已经走到会议室门口才发现里面有人，要么开会前几分钟才想起要订会议室，手机是唯一的随身设备。选小程序而不是 App，理由很现实：用户无需下载安装，扫码即用，用完即走，打开率远高于 App；同时微信生态自带身份体系，完整跳过账号注册和短信验证。企业微信里做办公应用，小程序是目前兼容性最好的载体之一。
与此同时，后台管理端必须做成响应式网页，跑在 PC 浏览器里。管理员处理审批事项时会在多个 Tab 之间切换，小程序里做得再顺手也替代不了 PC 的窗口操作体验。所以前端是“小程序 + Web 管理后台”双入口，服务端复用同一套 API。如果你也打算自己搞，建议一开始就把后端接口设计成和终端解耦的形态，不然后面加 Web 端或者钉钉端，接口兼容会搞得你很难受。
1.3 技术栈选型和版本决策
我用的组合是 Spring Boot 3.x + MyBatis-Plus + MySQL 8.0 + Redis 7 + 微信小程序原生框架 + Vue 3 + Element Plus 管理后台。选 Spring Boot 主要是生态成熟、招人容易，事务管理能力也强，预订这种强业务逻辑场景用到事务的地方很多。MyBatis-Plus 是我个人习惯，代码生成快，条件构造器写动态查询很方便。
小程序端用原生框架，没有引入 uni-app。原因很简单，会议室预订小程序不涉及跨三端发布的需求，微信端的 API 特性能直接用就用，避免经过中间层封装后出现定位、支付、扫码等功能的兼容问题。如果团队已经有 uni-app 基础，用 uni-app 也没毛病，只是你要知道收益和成本是等价的。
数据库选型上有个细节值得单独说：房间的占用状态不要做成字段存在 MySQL 里，而要用预订记录来动态推导。因为状态是“未来某个时间段的占用”，它不是现在的事实，而是未来的计划，存储在单独的字段里会导致数据一致性维护极其痛苦。真正的做法是：每一条有效的、未取消的预约记录本身就代表了那个时间段的“占用状态”，即时查询用 Redis 里的索引做快速判定，长久的审计和报表数据保留在 MySQL。
1.4 影响范围：谁在用这套系统，用在哪里
会议室预订系统的用户范围其实比想象中广。除了常规的公司行政人员和员工，前台接待需要用它来给访客安排洽谈室；IT 运维部门需要用它管理培训机房和设备间的使用；部分公司甚至会让 HR 用来安排面试间。一个隐藏需求是——很多公司会在大屏或前台 iPad 上轮播显示当前各会议室的占用情况，这就需要服务端提供一套只读的实时状态接口，供第三方设备调用。
所以实际设计时要留好接口余地：预订记录不仅要记录谁订的、订哪个房间、什么时间段，还要记录会议的标题、人数、是否需要视频设备、是否需要外部访客权限。这些都是后来加需求时最常出现的东西，前期表结构多留两三个冗余字段，能省掉后期一大笔改动成本。
2. 数据库设计与核心表结构：预订单和调度算法才是灵魂
2.1 房间表、预订表、时间片表怎么设计
我把核心数据分成三张主表和两张辅助表。主表是会议室、预订记录、用户表；辅助表是预订明细时间片和操作日志。
会议室表的关键字段包括：id、名称、位置、容纳人数、设备列表（JSON）、是否启用、是否需要审批、开放时间段（早 8 点到晚 8 点这种）、是否允许跨天预订、所属楼层或区域。这里有一个高频踩坑的点——开放时间段千万别用单个时间字符串存，而是用open_start_time和open_end_time两个时间类型的字段，查询时才能走索引高效过滤。
预订表是核心中的核心，字段有：订单号、用户 ID、会议室 ID、会议开始时间、结束时间、会议标题、参会人数、状态（待确认/已确认/已取消/已结束/未签到）、审批人 ID、审批时间、外部访客标记、设备需求。业务里有约 90% 的查询都集中在“某个会议室在某个时间段是否空闲”和“某个用户在某个时间段有哪些预订”，所以这两组字段必须建联合索引。
时间片表是我额外加的，用来做高并发并发控制。正常的查询流程是先查该时间段是否有人订过，没订过就插入。但在并发场景下，两个用户同时请求同一个会议室同一时间，双方都查到空闲，就会双双成功——这就是常见的“超卖”问题。这个矛盾用数据库事务和唯一索引其实也能处理，但更稳的方案是引入时间片表和分布式锁，把时间粒度切分成固定长度（如 30 分钟一个槽位），预订时对多个槽位加锁。这就像电影院选座，先锁座位再支付，谁先锁谁得座。
2.2 防冲突判断：为什么会订重，怎么彻底解决
关于“订重了”的问题，我实测过几种方案，逐一说下优劣。最简单的是 Java 服务里用 synchronized 锁，但只对单实例有效；升级成分布式锁用 Redis 的 SETNX，可以解决跨实例同步问题，但细粒度不够的话会让不同会议室的请求互相阻塞。
更优雅的是用数据库层面约束。基于 MySQL 可以这样设计：预订表上加一个虚拟列room_date，存的是会议开始日期；再建立一个唯一索引uk_room_time(room_id, room_date, start_time, end_time)——但这个方案行不通，因为不同人订的时间段长度不同，9:00-10:00 和 9:30-10:30 实际上冲突，但用等值唯一索引判断不出来。
所以要真正解决问题，必须用区间重叠判断。SQL 写法是一个经典的“区间重叠判断”条件——两个时间段有交集，当且仅当 A 的开始时间小于 B 的结束时间，且 A 的结束时间大于 B 的开始时间。翻译成查询就是：
SELECT COUNT(*) FROM reservation WHERE room_id = #{roomId} AND status IN ('CONFIRMED', 'PENDING') AND start_time < #{endTime} AND end_time > #{startTime}这个查询必须配合事务和行锁一起用。实际操作是先对会议室表的对应行加SELECT ... FOR UPDATE写锁，再执行上面的查询和插入，保证同一会议室的并发请求被序列化。Redis 锁和唯一索引能做效率优化，但兜底永远靠数据库行锁。我在这上面吃过一次大亏，一开始只用了 Redis 锁，结果锁过期之后数据库层面没有兜底，出现了超卖，后来加了行锁和唯一索引双层保障才稳下来。
2.3 用户身份体系和管理员权限的落地方案
微信小程序有wx.login拿到 code，后端拿 code 换 openid，只要拿到了 openid 就能唯一标识一个用户。但公司场景里光有 openid 不够，还需要姓名、部门、手机号。所以我在用户表设计了两个字段：openid 作为登录凭证，employee_no（工号）作为业务标识。首次登录时小程序引导用户填写工号并绑定，管理员在后台确认。这个流程比每次都让用户输入手机号验证码舒服得多。
权限方面用 RBAC 模型，表结构是用户表、角色表、用户角色关联表。角色我预置了三个：普通员工、部门管理员、超级管理员。普通员工只能操作用户端小程序，部门管理员能审批本部门的会议室预订和查看本部门统计报表，超级管理员能配置所有会议室、查看全公司报表、导出数据。后台管理端的接口必须做拦截器校验 token 和角色，而且还不能只校验“是不是管理员”，因为部门管理员这个角色是横切数据权限的，必须额外携带部门编码做数据过滤。
3. 小程序端核心功能实现：从登录到预订到签到
3.1 登录态维护和 token 刷新机制
小程序端的接口请求统一封装在request.js工具类里，每次请求自动带上 token，遇到 401 状态码就尝试刷新 token，刷新失败则跳回登录页。这个机制我见过很多团队不做，结果用户一旦 token 过期就白屏或无限报错，体验很差。
下面是我的封装逻辑，可以参考：
// request.js 核心逻辑 const request = (url, method, data) => { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method, data, header: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${wx.getStorageSync('token')}` }, success: (res) => { if (res.statusCode === 401) { // token过期，尝试用 refreshToken 刷新 refreshToken().then(() => { request(url, method, data).then(resolve).catch(reject) }).catch(() => { wx.reLaunch({ url: '/pages/login/login' }) reject(res) }) } else if (res.statusCode === 200) { resolve(res.data) } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }) reject(res) } }, fail: (err) => reject(err) }) }) }按官方最新规范，刷新 token 应当使用wx.login获取新 code，后端通过 code 换取 openid 后重新生成 token。这个设计可以保证用户的登录态最长时间可达 30 天，不需要频繁重新登录。
3.2 会议室列表页：筛选和状态展示怎么做才顺手
列表页是用户打开小程序看到的第一个页面，体验好坏直接影响使用率。我采用的布局是顶部筛选栏 + 卡片列表。筛选栏包含日期选择（默认今天）、楼层/区域下拉、容纳人数最低值、设备需求多选。日期选择用原生 picker 的 mode="date"，楼层下拉用原生 picker 的 mode="selector"。如果项目要支持快速选择“今天/明天/后天”，可以额外做一个 tab 切换。
卡片列表中每个会议室卡片展示的关键信息包括：会议室名称、所属区域、容纳人数、主要设备图标、今日剩余可订时段。剩余可订时段不用每次都实时查接口，因为数据变化很快，从 Redis 中获取半小时级别的空闲槽位即可，前端拿到后直接渲染。这个方案实测下来接口响应能控制在 200ms 以内，比每次查 MySQL 快一个数量级。
用户点击某个会议室卡片后进入详情页，里面展示一周的排班表格，用不同颜色区分已预订、可预订、维护中，点击时间段弹出预订确认框，选择参会人数并填写会议标题后提交。这里的核心交互原则是“减少输入项”——能点选的不要输入，能默认的不要填。
3.3 预订流程：从点击到成功的完整链路
预订提交的完整链路是：前端校验 → 后端接口校验 → 加锁 → 检查冲突 → 插入预订单 → 返回结果 → 通知相关人员。
前端校验主要做基础合法性校验：时间不能在过去、结束时间必须晚于开始时间、时间段不能跨出会议室的开放时间段。这些校验即使后端也会做，前端仍然要有，因为用户可以绕过前端直接调用接口，但前端校验能拦截绝大多数误操作，减少无效请求。
后端的校验逻辑被我放在了 Service 层，并且使用@Transactional注解，确保整个流程要么全部成功要么全部回滚。用户提交预约后，我置入的是“待确认”状态，这是针对会议室设了审批的情况。免审状态则在插入后直接把状态变为已确认，并同步加入 Redis 空闲索引。
处理好预约后，还要做一件容易被忽略的事：异步通知。我用的方案是 Spring Boot 自带的@Async注解 + 线程池，用户提交成功后的 1 秒内，系统会发一条订阅消息或短信给参会人员，内容包含会议室位置、时间、会议主题。这里需要注意一点，别把通知逻辑写到事务里，否则通知服务的网络延迟会拖长事务时间，严重影响接口性能。
3.4 签到、续订和取消：会议室预订的几个盲区
签到功能安排在预约开始前 15 分钟到开始后 30 分钟之内，用户到达会议室后在小程序端点击确认到会。这个操作的意义是释放资源——如果用户预约了但没到，管理员可以手工释放或系统自动释放。我实现的是超过预约开始时间 30 分钟未签到的预约自动标记为“爽约”，会议室的该时间段重新变为可订。
续订是这个业务里的一个特殊场景：会议开着开着超时了，需要追加时间。续订的处理逻辑是新增一个预订记录，而不是修改原记录的结束时间，这样保留完整的操作日志。续订同样需要冲突校验，如果下一时间段已有人预约，则续订失败，提示用户换一个会议室或提前结束。
取消预约也需要注意策略：免费预约的情况下，至少应提前 30 分钟取消；如果使用了积分或额度预订，超出免费取消时限需要扣除相应信用分，这样可以从产品层面限制恶意占座。这个信用机制不是必须项，但如果你服务的公司会议资源非常紧张，我强烈建议加上，否则会出现长期占着不用的浪费现象。
4. 管理后台：会议室配置、审批流和统计报表
4.1 会议室管理：从新增到维护一个完整生命周期
管理后台的会议室管理页面我用的是表格加抽屉的形式。左侧是区域和楼层的树形结构，右侧是会议室列表。新增会议室时需要配置的信息包括基本资料、设备清单、开放时间、审批策略、封面图片。
这里有一个细节值得展开：设备清单不要用单行文本输入，而应该做成多选标签，后台存成 JSON 数组。因为报表和筛选功能会依赖设备维度统计——行政部会想知道“有多少个会议室支持视频会议”，如果存文本就很难做聚合。JSON 类型的字段在 MySQL 8 里已经支持得很好，查询时可以用JSON_CONTAINS直接过滤。
会议室的启停用和删除操作也要区分开。实际业务中“删除会议室”是低频且危险的操作：删掉一个会议室时，该会议室的未来预约怎么办、历史报表如何归档？我的方案是默认软删除，状态标记为“已停用”，历史数据全部保留。停用后新的预订请求会被拒绝，已存在的预约不受影响。
4.2 预订审批：待办、通过、驳回的操作细节
审批页面是管理后台最常用的页面。列表按“待处理/已处理”分类，核心字段是申请人、会议室、时间段、会议主题。审批通过后系统会推送一条订阅消息给申请人告知审批结果。
我踩过的坑是这个页面容易被忽略的“批量审批”需求。行政小姐姐对着几十条同类审批一条条点很费劲，所以我在表格里加了行复选框和批量通过按钮。但这带来一个新问题：并行审批的竞态。两个人同时打开后台管理页，一个人通过了一个申请，另一个人以为还没处理。解决方案是在操作时校验记录状态，如果已经被处理过，前端弹出提示并刷新列表。后端这块我用的乐观锁，通过version字段实现，防止并发覆盖状态。
4.3 预约记录查询与统计报表：一屏掌控全公司会议资源
统计报表我按日、周、月三个时间维度做了三个层级。日视图关注每个会议室的时间段占用率，周视图汇总各周每天的预订量趋势，月视图重点看各楼层各区域的资源利用率。这些报表页面是我用 Vue 3 加 ECharts 画的，后端提供聚合接口。
后端聚合统计这里用了 MyBatis-Plus 的条件构造器配合group by查询。比如要统计上个月每周的预订量，SQL 大致是：
SELECT DATE_FORMAT(start_time, '%x-%v') AS week_num, COUNT(*) AS booking_count FROM reservation WHERE status IN ('CONFIRMED', 'PENDING') AND start_time >= #{monthStart} AND start_time < #{monthEnd} GROUP BY week_num ORDER BY week_numECharts 的仪表盘和折线图对这种场景很合适，但要注意后端返回的数据格式必须设计得和图表组件对齐，否则前端要写很多数据转换代码。我踩过一次格式不匹配的坑，基础数据算了半天，发现三维时间统计的参数传递命名不一致，最后改成后端直接输出图表所需的 key 结构才省事。
4.4 系统配置：开放时间、审批开关、通知模板
系统配置页面虽然在管理后台，但它决定了整个系统在非技术层面的运行策略。比如“是否开放周末预订”、“默认预订提前时间”（提前 1 小时到提前 7 天）、“超过多少人需要审批”等等。配置存放的形式我用的是 KV 结构，一张system_config表搞定，修改后通过缓存刷新机制更新到 Redis，避免配置修改后即时生效的延迟时间过长。
有些配置影响范围很大，比如“预订默认时长”从一小时改成半小时后，前端日历展示、后端预约时长校验、冲突判断的粒度全部都会变。所以我在实现时把配置读取统一放到ConfigService中，前端需要展示配置时通过一个公共接口获取，禁止各个页面各自定义死值。后来验证这个做法很正确，有一次行政在后台把默认时长从 60 分钟改到 30 分钟，整个系统没有一行代码改动就生效了。
5. 后端接口文档与关键代码拆解：让源码真正跑起来
5.1 接口文档：核心 API 一览表
在实际写代码之前，我习惯先列好接口清单。会议室预订的后端接口我按业务模块分了六组，核心接口大致如下：
| 模块 | 接口路径 | 请求方式 | 说明 |
|---|---|---|---|
| 认证 | /api/auth/login | POST | 微信登录，code 换 token |
| 会议室 | /api/rooms/list | POST | 条件查询会议室列表，带时间筛选参数则返回可订状态 |
| 预订 | /api/reservation/create | POST | 提交预订（含防冲突校验） |
| 预订 | /api/reservation/cancel | POST | 取消预订 |
| 预订 | /api/reservation/signin | POST | 签到打卡 |
| 审批 | /api/approval/list | GET | 审批列表（管理员） |
| 审批 | /api/approval/process | POST | 审批通过/驳回 |
| 报表 | /api/stats/room-usage | GET | 会议室使用率统计 |
request 和 response 的封装也有讲究，我统一用的结构是{ "code": 0, "message": "success", "data": {} }，code 为 0 表示成功，非 0 表示业务异常。业务异常统一由全局异常处理器捕获，转换成上述结构返回，不让未处理的异常裸奔。
5.2 防冲突预订核心代码：事务 + 锁 + 唯一约束
这里给出防冲突预订的核心代码，我做了脱敏处理，但关键逻辑完整可跑。这是整个系统里最容易出 Bug 的地方，写的时候务必小心：
@Transactional(rollbackFor = Exception.class) public Reservation createReservation(CreateReservationRequest request) { // 1. 参数校验（时间合法性、会议室是否存在等） validateRequest(request); // 2. 对会议室行加写锁，串行化同一会议室的并发请求 MeetingRoom room = meetingRoomMapper.selectByIdForUpdate(request.getRoomId()); if (room == null) { throw new BizException("会议室不存在"); } // 3. 检查时间段是否在开放范围内 checkOpenTime(room, request); // 4. 核心：区间重叠检测，防止时间交叉预订 int conflictCount = reservationMapper.countConflict( request.getRoomId(), request.getStartTime(), request.getEndTime()); if (conflictCount > 0) { throw new BizException("该时间段已被预订，请选择其他时间"); } // 5. 插入预订单 Reservation reservation = new Reservation(); reservation.setUserId(request.getUserId()); reservation.setRoomId(request.getRoomId()); reservation.setStartTime(request.getStartTime()); reservation.setEndTime(request.getEndTime()); reservation.setMeetingTitle(request.getMeetingTitle()); reservation.setStatus(room.getNeedApproval() ? "PENDING" : "CONFIRMED"); reservationMapper.insert(reservation); // 6. 同步 Redis 空闲索引（异步或同步均可） roomAvailabilityService.updateIndex(reservation); return reservation; }这个方法里的第二步selectByIdForUpdate一定要存在，因为它是并发兜底的基石。Redis 锁能解决多数情况，但数据库行锁是最终的保险。还有一种情况——用户跨会议室并发请求不同会议室时，行锁各自独立没有交叉，性能完全没问题。
5.3 Redis 在空闲时段查询中的优化实践
不用 Redis 的会议室预定系统，在会议室数量超过 20 间、每天预订量超过 200 条的时候，接口延迟会开始变得非常明显。我加 Redis 索引的方案是这样的：每个会议室一天生成一个 key，比如room:1001:2025-06-20，value 是一个包含 48 个 bit 的位图，每个 bit 代表 30 分钟。预订成功后将对应时间段的位置 1，取消时置 0。
查询空闲时段时，直接取出这个位图，和“占用位图”做一次异或运算，即可得到所有空闲槽位。这个方案的优势是：查询速度 O(1)，不依赖 MySQL 聚合；实时性好，预订和取消操作能即时反映。缺点是位图精度是半小时粒度，支持更小粒度需要增加位图长度。
Redis 里的位图数据如果丢了怎么办，这是必须回答的问题。我的做法是先把 MySQL 当唯一事实来源，Redis 只是缓存。数据不一致时，通过一个定时任务每 5 分钟从 MySQL 全量重算一次近 7 天的位图。这样 Redis 挂了也没关系，查询接口会降级回 MySQL 做实时计算，无非慢一些，但功能不中断。
5.4 消息通知：订阅消息和站内信双通道
微信小程序的订阅消息（原模板消息）是通知用户的核心通道，但一个致命的限制是：一次性订阅消息必须由用户主动触发订阅动作，且只能下发一次。用户完成预订操作时弹窗申请订阅，审批通过时再申请一次，会减少骚扰也提升接受率。
我的落地方式是：预订成功时，前端弹窗订阅，后台记录订阅凭证；审批通过时，后端调用订阅消息接口推送结果，同时清理凭证。对于没有订阅权限的场景（比如小程序被封禁或用户主动关闭），必须有站内信通道兜底，实现一个全局的站内信列表接口，用户在小程序里能看到所有历史通知。这个设计我建议新项目都直接内置，因为小程序订阅消息的政策变动可能性始终存在。
5.5 支付扩展：会议室收费场景需要提前铺路
有些会议室场景需要收费，比如共享办公空间按小时计费，或者公司对超时使用员工部门进行成本分摊。虽然主流程里可以不接支付，但数据库设计时我预留了fee_rate和payment_status字段，这样后续如果需要对接支付功能，不用改表结构。
微信支付 v3 的对接主要涉及下单、回调验签、退款三个部分。服务端需要用商户私钥对请求签名，回调时需要验证微信签名并解密资源。这个环节容易踩的坑是：回调结果必须返回给微信支付“成功”的响应，否则微信会不断重试；同时回调处理要做好幂等性，同一个订单重复回调时不能重复入账。
如果你打算在会议室预订项目里接支付，只给你的强烈建议是：不要把业务主流程和支付流程强行耦合。预订先创建待支付状态的单，支付成功后再确认预订；未支付超过 15 分钟自动关闭。这样即使支付链路出问题，也不至于让整个预订系统不可用。
6. 部署环境与上线流程：本地能跑不代表上线能跑
6.1 前后台和服务端的环境要求
一套完整的部署环境我列在这里，供你对照采购服务器时参考：腾讯云或阿里云的 2 核 4G 起步，操作系统选 Ubuntu 22.04 LTS 或 CentOS 7.9 都可以，软件环境包括 JDK 17（对应 Spring Boot 3）、MySQL 8.0、Redis 7.x、Nginx 1.24。如果用容器化方案，则在此基础上加 Docker 和 Docker Compose。
小程序端正式发布必须使用 HTTPS 域名，且域名必须在小程序后台配置为 request 合法域名。服务端接口我用的域名是api.example.com，Nginx 配置 SSL 证书并反代到后端服务的 8080 端口。管理后台是 Vue 3 构建的纯静态文件，直接部署在 Nginx 的根目录即可，走另一个域名admin.example.com，并且设置 IP 白名单，只允许公司内部网络访问。
6.2 上线前要过的测试清单
上线前有一份测试清单我每次交付都会执行一遍，都是踩坑之后总结出来的硬性检查项：
- 同一会议室同一时间并发创建两个预订，必须只有一个成功。
- 不同会议室同一时间并发创建预订，两个必须都成功，不能互相阻塞。
- 预约开始前 15 分钟的小程序订阅消息能否按时触达。
- 管理员驳回预订后，用户端的状态是否在 10 秒内变为已取消。
- 会议室停用后，用户端的列表是否还显示这间会议室（应该不显示）。
- 服务器重启后，Redis 中的位图索引是否会自动重建。
- 用户瞎折腾，跨天预订或持续 24 小时预订，后端是否能正确拒绝。
- 报表接口在数据达到 10 万条时响应是否大于 3 秒。
- 管理后台连点两次审批通过，是否会造成重复操作。
上面每一项在真实项目中都可能出现过问题。最典型的是第三条，订阅消息偶尔会丢失，排查了几轮发现是 access_token 过期导致调用失败。后来加了 access_token 的定时刷新和调用失败自动重试，问题才消停下来。
6.3 源码交付时的工程规范
源码交付的目录规范也要重视，不然对方接手时一头雾水。我会把整个工程拆成四个目录：miniapp/（小程序端）、admin-web/（管理后台前端）、server/（Spring Boot 服务端）、docs/（接口文档、部署文档、数据库初始化脚本）。这样的好处是每个子项目都是独立的可构建产物，后续拆开部署或多人协作都清晰明了。
数据库初始化脚本必须放在docs/sql/下，包含建库建表语句和基础数据（比如内置管理员账号、默认会议室分类）。接口文档我推荐用 Apifox 或 Postman 导出一份完整的 JSON，再生成一份 Markdown 版。团队内部最常用的就是那份 Markdown，方便快速检索接口参数。
规范化交付的另一个重要点是环境配置：服务端的application.yml中数据库密码和 Redis 密码不能写死，必须用环境变量注入方式配置，否则源码一旦泄露还带着生产环境的密码，后果非常严重。我交付时会给一个.env.example文件列出所有环境变量的占位和说明，收到源码的人照着复制一份.env自己填即可。
7. 常见问题与排查思路实录
7.1 并发预订导致超卖：日志里看不出问题怎么办
超卖是最难排查的问题之一，因为它在并发量小时不出现，一旦多人同时抢热门会议室才会暴露。日志层面看到的表现通常是“两个请求都成功创建了预订单”。
排查思路从三处下手：先看是否加了@Transactional，没有事务则插入后无法回滚；再看selectByIdForUpdate是否真的生效，有些情况下 MyBatis 的查询可能没加FOR UPDATE，需要检查 SQL 日志确认；最后看 Redis 和数据库锁是否冲突，如果 Redis 锁先拿到了，但数据库事务还没提交，另一个实例的 Redis 锁已经过期，也会出现并发漏洞。我做的最彻底的修复是：去掉 Redis 锁，只保留数据库行锁，虽然高并发下吞吐量会下降一些，但绝对不出错。对于会议室这种低频高价值的资源，一致性比吞吐量重要得多。
7.2 小程序登录态在安卓和 iOS 上的表现不一致
小程序登录态偶发丢失，且安卓和 iOS 行为不一样，这是我遇到过的真实案例。排查发现是 iOS 对wx.setStorageSync的同步写入和异步写并发执行时有一定概率发生覆盖，而安卓上同样的代码不会。解决方案是统一改成Promise风格的wx.setStorage，保证每次写操作完成后再进行下一段逻辑。另外我还加了登录态的本地持久化和内存缓存两层，内存缓存优先，避免每次请求都读 Storage 的性能损耗。
7.3 订阅消息发送频率过高被微信限流
业务方曾提出一个需求：每周一早上给所有本周有预订安排的用户发送一条本周会议提醒。这个需求看起来合理，但因为用户量太大，在几分钟内调用订阅消息接口触发了微信的频率限制，导致部分消息被静默丢弃。
我的调整方案是把这批通知拆成多个批次，每批只发 500 条，批次之间间隔 5 秒，配合本地的任务队列和失败重试机制。同时人为给每个用户的消息发送设置随机延迟，避免在同一个秒级窗口内集中调用。上线后这个方案一直很稳，再也没有触发限流。
7.4 会议室列表打开慢：索引和缓存优化的实战
用户量上来以后，列表页接口从 200ms 膨胀到了 1.8 秒，这已经影响使用体验了。排查发现两个原因：一是会议室表关联查询的 SQL 没用上索引，导致全表扫描；二是一次查询把 50 间会议室的全部空闲时间段都从 MySQL 查出来，数据量太大。
我的修复方案是：先给room_id + start_time建联合索引，再把会议室基础信息用 Redis 缓存，空闲时段改为只查当前时间之后 24 小时的数据。如果会议室超过 30 间，列表页改造为前端分页或懒加载，每次只加载 10 间会议室，滚动到底部自动加载下一批。最终接口耗时降到了 150ms 左右。
8. 从源码到落地：上线后还要持续运营的心思
这一套系统从开发到交付，花费的时间大头其实并不在编码，而在需求确认和反复调整细节。会议室预订这件事，表面上是一个标准的信息管理系统，但不同公司的使用习惯、决策链、审批流差异巨大。代码是死的，规则是活的，所以源码里我特意把审批模式、开放时间、预订时长限制等都做成了可配置项，方便后续接手的人能在外行无码环境下调整规则。
另外我建议部署这套系统的团队，上线初期安排一名管理员在后台盯一两周，观察是否存在滥用行为、预订取消比例是否异常。这些数据能在系统稳定的前提下反哺行政策略，比如发现某层楼的会议室使用率持续低于 10%，就可以考虑调整布局或者放开跨区域预订限制。
最后再分享一个小技巧：不要等业务提需求才优化，上线后每个月拉一次使用数据，重点看“预订取消率”和“爽约率”。取消率高于 30% 说明预订约束太松或时间门槛太低；爽约率持续偏高说明需要增加信用分或自动释放机制。这些小优化不需要大改系统，调整配置就能完成，但带来的体验提升往往比一次性大版本更新要明显得多。
本文还有配套的精品资源，点击获取
