微信小程序+SpringBoot实验室预约系统设计与实现-平芜编程栈

最近几年接手指导毕业设计，发现"开放实验室预约"这类题目几乎每年都有人选。倒不是说题目有多新奇，而是它特别适合用来检验一个毕业生对主流技术栈的综合掌握程度——前端是微信小程序，后端是SpringBoot，中间还夹着预约冲突检测、并发控制这些既基础又容易踩坑的业务逻辑。今天就把这个题目从需求分析到落地实现完整捋一遍，给正在做类似毕设，或者想用SpringBoot接小程序做项目的朋友一份可以直接照抄的参考方案。

这个项目表面上是一个"预约系统"，但真正做完你会发现，它其实是一个典型的"低并发、高业务复杂度"的管理系统。说低并发，是因为实验室预约的场景峰值流量远没有电商秒杀那么夸张；说高业务复杂度，是因为它牵扯多角色权限、多状态流转、时间冲突检测、消息通知、数据统计等多个模块。这种项目恰恰是毕业设计最理想的选择：工作量足够、技术覆盖面广、又不会难到做不出来。

1. 项目选题与需求拆解

1.1 开放式实验室预约到底在解决什么问题

先别急着写代码，把业务痛点理清楚比什么都重要。高校的实验室资源分两种：一种是固定排课，教务处统一安排；另一种是开放式实验室，供学生课外做实验、搞创新项目、备战竞赛使用。后者如果靠人工登记，问题很快就暴露出来——管理员不知道哪个时段空闲、学生跑空趟、钥匙管理混乱、设备使用记录断档。

所以这个系统的核心价值就一句话：让学生能在手机上看到实验室的实时空闲状态，自己选时段预约，管理员在后台审核和管理，整个过程留痕可追溯。听起来简单，但细拆下来，角色至少有三个：

学生用户：浏览实验室列表、查看空闲时段、提交预约申请、取消预约、查看个人预约记录。
实验室管理员：审核预约、管理实验室信息、管理开放时段、处理违约记录。
系统管理员：管理用户角色、配置基础数据、查看统计报表。

每个角色的需求交集和冲突点就是设计系统的切入点。例如学生希望"随时能约到"，管理员希望"杜绝霸占名额"，这就在业务层面催生了预约审核制和信用分/违约机制这两个功能模块。

1.2 毕业设计题目的"工作量性价比"分析

选这个题目还有一个很现实的原因——工作量性价比极高。一个合格的毕设系统，需要同时体现数据库设计能力、后端接口开发能力和前端交互能力。实验室预约系统恰好把这三块都覆盖了：数据库有十几张关联表，后端有RBAC权限控制和状态机设计，前端小程序有完整的用户操作路径。

横向对比几个常见的毕设题目会更直观：

题目类型	技术覆盖面	业务复杂度	答辩亮点挖掘难度
图书管理系统	中等	低	难，太常见
电商系统	高	高	中等，但容易陷入支付等坑
实验室预约系统	高	中等	易，预约冲突处理是天然亮点
博客/论坛系统	低	低	难，缺乏业务深度

预约系统在答辩时有一个天然优势：你可以把"并发场景下的预约冲突处理"作为技术亮点讲三分钟。这是很多简单管理系统没有的东西，也正是评委老师爱听的东西——你遇到了什么问题、怎么分析、怎么解决、有没有考虑更复杂的场景。

2. 技术选型与整体架构设计

2.1 后端为什么选SpringBoot而非其他框架

后端框架的选择其实没有悬念。SpringBoot作为当前Java生态最主流的微服务开发框架，在毕业设计这个层级有不可替代的优势：社区资料多、封装完善、招人端认可度高。就算你不打算做Java方向的工作，用SpringBoot做一次完整的项目，也能把IoC、AOP、ORM这些核心概念吃透，这些知识在任何后端语言里都是互通的。

版本选择上，我建议直接用Spring Boot 2.7.x，别追新。原因很现实：3.x版本要求JDK 17，很多学校的教学环境还停留在JDK 8或者JDK 11，而且3.x对部分老版本依赖的兼容性处理更麻烦，光一个spring.factories机制改动就可能让新手排查好几个小时。2.7.x配合JDK 8是经过大量项目验证的稳定组合。

ORM框架建议用MyBatis-Plus而非纯MyBatis。纯MyBatis写CRUD的XML文件太啰嗦，MyBatis-Plus内置了通用Mapper和通用Service，单表操作一行代码都不用写SQL，复杂查询再用@Select注解或XML自定义，兼顾效率和学习深度。至于JPA，不太建议毕设选它——自动建表确实方便，但一旦涉及复杂查询，JPA的规则比SQL本身更难解释。

2.2 前端选微信小程序而不是网页或App的原因

这个决策主要从三个维度考虑：触达成本、开发效率、作品展示效果。相比需要下载安装的App，微信小程序扫一扫就能用，用户接受度高；相比网页端，小程序有微信生态的天然身份体系，不需要额外做繁琐的注册流程，直接wx.login拿openid识别用户。

从毕设展示角度来说，小程序还有一个隐性的加分项——你的演示环境不需要搭服务器供别人访问。提供给评委演示时，他们用微信扫码就能体验学生端的完整流程，这种即开即用的体验比在电脑浏览器里敲网址好得多。而且小程序自带认证、消息订阅通知等能力，这些在做"预约成功提醒""审核结果通知"功能时是天然的优势。

要注意的是，小程序开发和传统Web开发有一些"反直觉"的地方需要提前适应：没有DOM操作、组件通信靠properties和事件、页面栈管理需要手动处理。这些会在后面第五章详细讲。

2.3 整体架构与技术栈一览

整个系统采用前后端分离的单体架构，部署简单，对毕设来说完全够用：

前端：微信小程序原生开发（WXML + WXSS + JS），不引入uni-app。原生开发在排查问题时更直观，而且毕业设计用原生开发更像"自己写的"。
后端：Spring Boot 2.7.x + MyBatis-Plus 3.5.x + MySQL 8.0，接口风格采用RESTful API，统一返回JSON格式。
鉴权方案：自定义Token + Redis缓存。小程序端每次请求在请求头带上Token，后端通过拦截器校验身份和角色权限。
定时任务：Spring@Scheduled，用于自动变更预约状态（如预约超时未到自动取消）。
部署方案：后端打包成Jar包部署在服务器（腾讯云/阿里云学生机即可），小程序使用微信开发者工具上传体验版，后端接口地址配置在小程序后台的合法域名中。

这套方案有一个关键的好处：全部技术环节都是你亲手能掌控的。不像某些毕设外包项目用了一堆云服务黑盒，答辩时一问三不知。

3. 数据库设计与核心业务模型

3.1 核心表结构设计与表关系梳理

数据库是整个系统最不能含糊的部分。我见过太多人一上来就写代码，表结构乱七八糟，到后面查询逻辑全卡在自己设计的表上。先把关系理清楚：用户、实验室、预约记录这三张是铁三角，其余全部为这三者服务。

我按照实际项目经验，推荐这组核心表：

表名	核心字段	说明
`user`	id, openid, name, student_no, role, phone, credit_score	openid关联微信身份，role区分学生/管理员/系统管理员
`lab`	id, lab_name, location, capacity, equipments, description, status	实验室基础信息
`lab_time_slot`	id, lab_id, start_time, end_time, weekday	开放时段模板，按星期几配置
`reservation`	id, user_id, lab_id, date, slot_id, status, create_time	预约记录，状态机核心
`reservation_log`	id, reservation_id, operation, operator_id, create_time	操作日志，用于审计和答辩展示
`notice`	id, title, content, create_time, type	系统公告

表之间的关系很容易画出来：lab_time_slot从属于lab，reservation同时关联user和lab_time_slot，reservation_log记录对reservation的所有操作。这里有个容易出错的设计点：不要把预约时间直接存在reservation表里，而是要引用time_slot的id。这样改实验室开放时段时，已经产生的预约记录不会受影响，数据库也不用冗余存储时间字段。

考虑到学生用户可能同时被多个入口使用（小程序端和后台管理端），建议user表增加status字段做禁用/启用逻辑，而不是直接删除用户——因为已经产生了预约记录，删用户会破坏关联完整性。

3.2 预约状态机的设计与状态流转逻辑

预约状态是系统里最容易写乱的部分。我建议用常量类统一定义，而不是在代码里到处散落"1"、"2"这样的魔法值。定义如下：

待审核（PENDING）：学生提交预约，等待管理员审核
已通过（APPROVED）：管理员审核通过，预约生效
已拒绝（REJECTED）：管理员驳回，需要填写拒绝原因
已取消（CANCELED）：学生在未生效前主动取消
已完成（COMPLETED）：预约时间过后且用户已签到
爽约（ABSENT）：预约通过但未按时使用

状态流转的规则必须明确，这是写后端校验逻辑的依据：

PENDING → APPROVED/REJECTED：管理员操作
PENDING → CANCELED：学生在审核前取消
APPROVED → CANCELED：学生在预约开始前N小时取消（超过时限不可取消）
APPROVED → COMPLETED/ABSENT：系统定时任务在预约时段结束后自动判定（结合扫码签到结果）

状态机的价值在答辩时特别明显。你可以直接画一张状态流转图放进论文里，并解释为什么要用状态机而不是简单的布尔字段——因为状态的合法迁移有限制，状态机在代码层面天然规避了非法操作（比如已结束的预约不能再次取消）。

3.3 预约冲突检测的核心逻辑

这个模块是整个系统的技术高光点。冲突检测的本质是区间重叠判断。假设一个实验室在某天开放了两个时段：09:00-10:30和10:30-12:00，学生要预约09:30-11:00这个时间段，系统就必须判断它是否与已有预约冲突。

数据库层面查询冲突预约的SQL思路如下：

SELECT COUNT(*) FROM reservation WHERE lab_id = #{labId} AND date = #{date} AND status IN ('APPROVED', 'PENDING') AND start_time < #{endTime} AND end_time > #{startTime}

注意条件用的是start_time < 新结束时间 AND end_time > 新开始时间，这是区间重叠的标准判断公式。<=和>=边界条件要根据业务定义调整——如果时段是前闭后开（即10:30开始意味着10:30可以再约另一个），就用严格的小于大于；如果是闭区间，就用<=和>=。我建议用前闭后开，因为实验室换场的10分钟缓冲期是合理的。

单机部署、低并发场景下，这个查询配合唯一索引就足够保证不冲突了。但要防止并发提交导致的"双人同时抢到同一时段"，还需要一个兜底机制，我放在第四章结合代码讲。

4. 后端接口设计与核心实现

4.1 接口清单与统一返回格式

接口设计必须遵循RESTful风格，按资源划分。完整的接口清单应该包含以下几组：

用户模块：POST /user/login（小程序登录）、GET /user/info、PUT /user/info
实验室模块：GET /lab/list（分页查询）、GET /lab/{id}（详情）、GET /lab/{id}/slots（某实验室的开放时段）
预约模块：POST /reservation（提交预约）、GET /reservation/my（我的预约）、PUT /reservation/{id}/cancel（取消预约）、GET /reservation/times（查询某日某时间段是否可约）
管理端模块：PUT /reservation/{id}/approve、PUT /reservation/{id}/reject、GET /reservation/audit-list（待审核列表）、GET /statistics/overview（统计面板）

所有接口统一返回一个Result对象：

@Data public class Result<T> { private Integer code; // 200成功，其他失败 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } }

这样小程序端只需要判断code，异常统一由全局异常处理器兜底，业务代码里不用到处写try-catch。

4.2 小程序登录鉴权与Token机制

小程序不同于传统网页，没有明文账号密码登录的概念。完整的登录流程是这样的：

用户点击小程序"微信一键登录"，前端调用wx.login()拿到临时凭证code。
前端把code传给后端/user/login接口。
后端用code调用微信接口code2Session，换取openid和session_key。注意这里必须配置小程序的appId和appSecret。
后端根据openid查询用户，如果不存在则自动注册一个新用户。
登录成功生成一个UUID作为token，存Redis（key为token:用户id，过期时间2小时），并返回给小程序端。

小程序端拿到token后统一存储在本地，并在每个请求的header里带上：

wx.request({ url: 'https://your.domain.com/api/reservation/list', method: 'GET', header: { 'Authorization': wx.getStorageSync('token') }, ... })

后端这边写一个AuthInterceptor拦截所有非白名单接口，校验token有效性和角色权限。这里建议用HandlerInterceptor加自定义注解@RequireRole("ADMIN")的方式做细粒度权限控制，既比Spring Security的配置式简单，又能体现你对AOP的理解。

我踩过的坑是维护登录取舍换时间。token过期后小程序端应该在全局封装request方法，遇到401响应自动跳转到登录页重新登录。如果不做这层处理，用户在后台挂一会儿再回来，所有请求都会静默失败，排查问题会发疯。

4.3 预约提交的并发控制与事务实现

这是代码实现里最有含金量的部分。刚才第三章提过冲突检测SQL，但如果两个请求同时通过了SELECT检查，都认为没冲突，然后同时插入，就会出现超约。解法分两类：

方案一：数据库唯一索引兜底（推荐）给reservation表加一个联合唯一索引，将"同一实验室同一日期同一时段同一个人"设为唯一：

ALTER TABLE reservation ADD UNIQUE INDEX uk_lab_date_slot_user (lab_id, date, slot_id, user_id);

但这只能防止同一人重复预约，防不了两个不同人抢同一时段。

方案二：SELECT ... FOR UPDATE 悲观锁（推荐用于毕设）在检查冲突时，对实验室当日记录加行锁，让并发请求串行化：

@Transactional public void createReservation(ReservationDto dto) { Lab lab = labMapper.selectByIdForUpdate(dto.getLabId()); int count = reservationMapper.countConflict( dto.getLabId(), dto.getDate(), dto.getStartTime(), dto.getEndTime()); if (count > 0) { throw new BizException("该时段已被预约，请选择其他时间"); } reservationMapper.insert(buildEntity(dto)); }

selectByIdForUpdate是SELECT * FROM lab WHERE id = ? FOR UPDATE，MySQL会在该行上加排他锁直到事务提交。由于毕设场景并发量并不高，这种方案完全够用，而且答辩时你能把锁机制讲清楚就已经很加分了。

还有一件事必须提醒：事务里不要调用远程接口，也不要执行耗时的外部操作。比如提交预约后要发送订阅消息通知管理员，这个操作必须放在事务提交后通过事件机制或异步线程执行，否则会长时间占用数据库连接，拖垮整个系统。

4.4 定时任务与状态自动流转

没有定时任务，预约系统就是个半成品。两个典型的定时任务：

任务一：超时未审核自动通过有些学校实验室不需要审核，预约提交后一定时间内无操作自动通过。用@Scheduled(cron = "0 */5 * * * ?")每5分钟扫描一次处于PENDING状态且创建时间超过30分钟的预约，自动更新为APPROVED。

任务二：预约结束自动标记状态理论上预约时段结束后，状态应该变成已完成或爽约。但这取决于用户是否签到了。推荐的做法是：在实验室门口贴签到二维码，用户预约时段内扫码调用签到接口，后端记录签到时间。定时任务在时段结束后统一扫描，已签到的置为COMPLETED，未签到的置为ABSENT并扣信用分。

定时任务要注意幂等性，防止重复执行导致状态被覆盖。建议在方法内先按条件查询符合条件的记录，再逐条判断当前状态是否符合前置条件再更新，不要直接UPDATE ... WHERE status = 'PENDING'这种全局操作——虽然SQL看着没问题，但日志会很难排查。

4.5 项目结构分层与代码规范

后端项目结构直接决定答辩时给老师的第一印象。规范的包结构如下：

com.example.labreserve ├── config // 配置类：MyBatis-Plus、Interceptor、Cors、Redis ├── controller // 接口层，只做参数校验和结果返回 ├── service // 业务层，写核心逻辑 │ └── impl ├── mapper // DAO层，继承BaseMapper ├── entity // 数据库实体 ├── dto // 请求/响应对象 ├── vo // 视图对象，按前端需求裁剪字段 ├── common // 统一返回Result、异常、常量、枚举 └── task // 定时任务

这里有个推荐的习惯：Controller里不要写任何业务逻辑，只做参数接收和调用Service。有的同学图省事直接在Controller里查库、写判断，一到答辩被老师追问"这个逻辑放在哪一层"，就露怯了。分层清晰不仅是为了规范，更是为了你被追问时能从容回答。

5. 小程序端设计与实现细节

5.1 页面结构与导航设计

小程序的页面设计要遵循"少而精"的原则，功能入口清晰比页面多更重要。我建议的页面结构是：

首页：实验室列表，展示实验室名称、位置、当前状态（空闲/使用中）、设备信息，支持关键词搜索。
预约页：选择具体日期和周几，查看该实验室的开放时段，选择时段后提交预约。
我的预约：展示全部预约记录，区分状态标签（待审核/已通过/已完成/爽约），预约通过后可以取消（限时内）。
个人中心：用户信息、信用分、我的通知、设置。

底部tabBar建议只设三个：首页、预约、我的。把"预约"和"我的预约"分开，避免tabBar太拥挤导致微信审核时被提示导航混乱。

WXML开发中比较容易被新手忽略的是列表渲染key的问题：

<view wx:for="{{labList}}" wx:key="id">

wx:key一定要给唯一值，不然数据变化时渲染会出现错乱。小程序是数据驱动视图的框架，更新数组时要用this.setData()而不是直接修改this.data。

5.2 登录授权与用户信息获取的坑

这一块是最近几年小程序开发变化最大的地方。早期可以用wx.getUserInfo()直接拿用户昵称头像，但微信早就调整了规则，现在必须用"头像昵称填写能力"让用户主动填写。很多网上教程还在教旧写法，照着做会发现按钮点了没有反应。

正确做法是：登录不弹窗，直接静默登录拿openid。进入小程序时调用wx.login拿到code，后端完成openid注册；需要用户信息时，在小程序里让用户通过button open-type="chooseAvatar"选择头像，通过input type="nickname"填写昵称，然后把这两样东西连同openid一起传给后端更新用户信息。

订阅消息通知也是毕设容易忽略的模块。预约审核结果提醒、预约超时预警都建议接入微信订阅消息，需要在小程序管理后台申请模板，然后在前端用wx.requestSubscribeMessage请求用户授权。注意订阅消息是一次性订阅，用户每次预约时需要重新发起订阅请求，不能默认用户之前授权过就一直能发。

5.3 用户操作路径与交互细节优化

交互设计上挑几个重点场景说。

场景一：选择实验室时段这是用户最核心的操作路径。不要用一个简单的picker让用户盲选，推荐做成分时段卡片横向滚动：上午、下午、晚间三个分组，每个时段卡片显示开始结束时间、当前剩余名额（有就亮、满了置灰）。用户点击卡片选中，下方显示选中的时间段，再确认提交。这样用户全程只需要两步操作。

场景二：预约取消限制取消预约必须在界面层做前置判断：只有状态为"待审核"或"已通过"且距离预约开始时间超过2小时的记录才显示"取消预约"按钮。后端同样要校验这个规则，不能只靠前端隐藏按钮，因为接口是可以被直接调用的。

场景三：分页加载预约记录多了之后，一次渲染全部数据会卡顿。小程序端用onReachBottom触发下一页加载：

onReachBottom() { if (this.data.page * this.data.pageSize >= this.data.total) { wx.showToast({ title: '没有更多了', icon: 'none' }); return; } this.setData({ page: this.data.page + 1 }, () => this.loadReservations()); }

对应的后端接口用MyBatis-Plus的Page对象分页查询，前端每次只拿10-20条数据，体验会好很多。

5.4 小程序端公共封装与调试技巧

强烈建议把wx.request封装成全局方法，统一处理baseURL、token注入、错误提示和登录态过期跳转。不然每个页面写一遍重复代码，后期维护会让你怀疑人生。封装好后，页面里只需要：

api.get('/reservation/my', { page: 1 }).then(res => { // 业务处理 });

开发调试时有两个实用的技巧。第一，真机调试时把"不校验合法域名"关掉会方便很多，但发布上线前必须在小程序管理后台配置合法域名，并且必须是HTTPS协议，不能是IP地址（除非有备案的独立IP）。第二，后端本地跑就开ngrok或natapp这类内网穿透工具把本地接口暴露成公网HTTPS，小程序开发者工具的"不校验合法域名"选项勾上，开发期联调会很丝滑。

6. 典型问题排查与避坑总结

6.1 预约冲突与并发问题

现象：两个学生同时提交同一时段预约，数据库里出现了两条重叠记录。排查思路：先看代码里有没有加事务和行锁。只靠SELECT判断再INSERT，在高并发下必然出问题。按第四章的悲观锁方案改造后，这个问题就能解决。补充建议：在预约创建接口加一个简单的Redis分布式锁也可以，SETNX lock_reservation_lab_date 1 EX 3，拿不到锁直接返回"操作太频繁"。虽然和悲观锁功能重叠，但写进论文里能让技术方案更丰富。

6.2 SpringBoot版本与依赖冲突

现象：项目启动报ClassNotFoundException或NoSuchMethodError。排查思路：绝大多数是SpringBoot版本和依赖版本不匹配。比如Spring Boot 3.x配旧版MyBatis-Plus启动器就会出问题。建议创建项目初期就锁定版本：Spring Boot 2.7.18、MyBatis-Plus 3.5.3.1、MySQL驱动8.0.33。确定后不要再轻易改依赖版本，否则版本升级带来的兼容性问题会耗费大量时间排错。

6.3 小程序审核与体验版分发

现象：小程序提交审核被拒，理由是"涉及预约功能需要相应类目"或"功能与类目不符"。排查思路：实验室预约属于"教育服务"下的"校园社区/服务"类目，需要提供相关资质。如果是毕业设计，不建议走线上发布流程，直接用体验版二维码发给评委试用就够了。在微信公众平台把成员添加为体验成员后，对方扫码即可体验，功能和发布版完全一致。经验提醒：不要把体验版二维码当作正式产品传播，体验版有时效限制且成员数量有限。答辩前提前把老师、评委的微信号加进体验成员列表，并确认他们打开的就是最新版本。

6.4 小程序包体积超限与真机白屏

现象：预览时提示source size 2612kb exceed max limit 2mb，小程序的包体积不能超过2MB。排查思路：检查图片资源是否都被打包了。小程序打包后总大小超过2MB就无法上传，常见解决方案是：图片不放在本地目录，全部上传到服务器或云端存储，页面里用网络地址引用；本地只保留必须的图标（建议用iconfont或SVG代替多张PNG）；第三方库按需引入，不要整个框架一次性引进来。另一个坑：页面引用了本地图片，但路径大小写写错，开发工具上看不出来，真机上一片空白。排查时优先看控制台资源加载请求，404的就是路径错了。

6.5 数据初始化与演示数据准备

现象：答辩演示时，录数据录了半天，现场气氛尴尬。经验建议：项目里写一个DataInitializer，应用启动时自动插入默认的实验室、时段模板、测试用户、样例预约记录。答辩前重置数据库，启动项目后所有数据都是现成的，演示流程顺畅得会让评委以为你的系统很成熟。准备几条不同状态（待审核、已通过、已完成、爽约）的预约记录，每个状态在界面上展示一下，也能直观体现状态机的设计。

6.6 论文写作与技术答辩的对应关系

毕业设计不只是做系统，论文和答辩准备同样是考核重点。写论文时把第四章的"状态机设计""乐观锁/悲观锁选型""定时任务方案"作为核心章节重点展开，每一个技术点都要能回答"为什么不用别的方案"。

答辩现场，评委大概率会问这几个问题，提前准备好答案：

为什么预约状态要设计成状态机，而不是用一个普通字段表示？
有没有考虑多人同时预约同一时段？你是如何解决的？
如果预约人数暴增到几千人同时抢，你的方案还扛得住吗？怎么优化？
用户取消预约后，释放出的时段如何及时开放给别人约？

最后一个问题尤其容易被忽略。解决方案是预约取消操作中同步清理Redis中的时段占用标记，让时段状态实时更新。把这类边界场景都补上，不仅能加功能完整度，更是答辩的加分项。

写在最后的一些实际体会

带过几届学生做类似项目后，我最大的感受是：毕业设计最怕的不是题目难，而是做着做着迷失方向。有人花了两周研究小程序动画效果，有人折腾了好几天在纠结要不要上微服务拆分，结果核心的预约流程还跑不通。这份题目真正的加分项永远是把基础业务做扎实——登录、预约、审核、状态流转、数据统计，每一条链路都演示顺畅，远比堆砌几个炫酷但无用的功能强得多。

如果你正在做这个题目，我给一条最务实的时间线建议：第1-2周完成需求分析和数据库设计，第3-4周完成后端接口和网站端管理后台，第5-6周完成小程序端主要页面和业务逻辑，第7周联调并补充异常处理，第8周开始写论文整理答辩材料。把大头先做完，后面自然从容。做系统的过程会遇到无数个"小坑"，但只要核心链路是通的，剩下的都是打磨而已。

微信小程序+SpringBoot实验室预约系统设计与实现