最近帮人把一套基于Spring Boot的大学生体检预约小程序从零搭到上线，过程中踩了不少坑。这类“微信小程序 + Spring Boot单体”的组合在毕业设计里出现频率极高，但很多同学只是照着网上的模板改库名、改图片，答辩时问几个问题就废了。这篇文章我不打算只贴界面截图，而是把核心设计拆开讲：业务边界怎么定、数据库表怎么建才能支撑预约和取消、后端接口哪些地方容易出并发问题、小程序端登录和请求封装怎么做才规范。如果你准备拿这个题目做项目，或者正在给类似预约系统写答辩文档，这篇文章应该能让你少走很多弯路。

先说清楚一个事实：体检预约系统看起来业务简单，但它是典型的“麻雀虽小、五脏俱全”项目。它同时涉及用户身份识别、预约资源控制、状态流转、报告文件上传和权限隔离。把这些点做扎实了，代码量不大，却说得出设计逻辑，这才是毕业设计真正想考察的东西。

1. 别急着建表：先把业务流程和使用角色理清楚

1.1 校园体检的实际场景和我敲定的页面流

我做系统前先跑了一趟学校的校医院，观察了实际排队和登记流程，才确定这不是一套“通用医疗预约系统”。校医院体检的特点是：学生按学院分批次来，体检项目大多是固定组合套餐，现场要核对姓名和学号，体检完成后由医生统一上传报告，学生在小程序里下载查看。

基于这个现实，业务闭环可以收敛成一条主线：学生打开小程序查看体检套餐，选择日期和时段，填写真实姓名、学号、手机号，提交预约；管理员在小程序对应的管理后台发布套餐、设置每天名额、查看预约名单、取消未体检的预约；体检完成后上传PDF格式报告；学生端在“预约记录”里看到报告并打开预览。

所以我确定的小程序端页面就是四个主页面：首页展示体检套餐和公告，预约页选择日期时段和填写个人信息，记录页展示预约状态与报告入口，我的页面处理登录状态和个人资料。管理端不走小程序，而是做成一个独立的Web管理页面，前后端通过接口通信。很多同学把管理功能硬塞进小程序里做，或者让小程序用户直接看到管理菜单，这种做法会让角色权限混乱，答辩时很容易被问住。

1.2 功能边界划分：哪些功能不要做

体检预约系统最容易翻车的地方在于“什么都想加”。我看到过有同学在预约系统里加了在线支付、提醒短信、医生排班、心电图上传等一大堆模块，结果数据库十几张表，到了答辩却讲不清楚核心流程。

我最后只保留了四组核心功能：套餐管理、时段名额管理、预约记录管理和报告管理。聊天消息、推送通知、支付这些一概不做。原因很简单：学校体检通常是免费或线下缴费，小程序支付功能没有真实业务场景；短信提醒需要第三方服务商，在毕设环境里会产生额外成本。如果非要体现技术亮点，可以用Spring Boot自带的定时任务做“体检前一天预约提醒”的演示逻辑，但不接入真实短信。

角色上我分成三类：普通学生用户、体检管理员、系统管理员。学生通过微信授权进入，管理员账号由系统预置。学生不能访问管理端接口，管理员也不能在小程序端提交预约，这是通过后端拦截器和接口路径规划实现的，不是靠前端隐藏按钮。

1.3 技术选型的理由：为什么是Spring Boot 2.7.18 + 原生微信小程序

先说Spring Boot版本。这个项目我选的是2.7.18搭配JDK 8或11，而不是最新版本3.x。原因非常现实：Spring Boot 3要求JDK 17起步，很多学校机房电脑还在用JDK 8，而且网上能找到的MyBatis-Plus、Knife4j、Docker配置教程大多是基于2.x版本写的。用2.7.18可以最大程度减少环境兼容性带来的额外问题，也方便答辩现场直接用一台普通电脑跑起来。

小程序端我用的是原生微信小程序，不是uni-app。原生框架在预约表单、时间选择器、上传文件这些场景都有成熟组件，而且不用额外引入编译器。如果你本身熟悉Vue，想用uni-app写一套代码以后发到其他端，也不是不行，但要注意uni-app编译出来的包体调试时容易出一些莫名其妙的问题，比如自定义导航栏高度、canvas层级错乱等，反而是给毕业设计增加负担。

后端依赖选型上，我用Spring Boot Web + MyBatis-Plus + MySQL 8.0 + JWT。MyBatis-Plus的好处是单表CRUD基本不用写XML，预约记录的分页查询直接用LambdaQueryWrapper就能完成。JWT用来做小程序登录后的身份令牌，不要让用户每次请求都带着openid跑来跑去，这样不安全也不规范。

2. 核心数据表设计：预约系统能不能自圆其说就看这里

2.1 六张表的关系与职责

数据库是整个预约系统的地基，我前后大概调整了三次表结构才定下来。最终保留了六张核心表和两张辅助表：

这里最容易被忽