Spring Boot与微信小程序医院挂号系统：从并发防超卖到毕业设计实践

1. 为什么"医院挂号系统"这类毕设年年是热门，以及你该不该选它

先说实话。每年毕业季被问到最多的一个问题就是："老师，我Java和Spring Boot都没学扎实，选什么课题能稳妥过答辩？"如果你的脑海里也有这个念头，那"基于Spring Boot + 微信小程序的医院挂号系统"确实是一个被反复验证过的优质选题。它不像电商秒杀、视频直播这类系统，动不动就牵扯分布式锁、消息队列、高并发削峰，把学生逼到崩溃；也不像纯管理后台那样毫无亮点，做出来毫无成就感。医院挂号系统天然处于一个恰到好处的区间：业务逻辑够清晰、功能模块够丰富、技术栈够主流，而且——最关键的——它有一个看似棘手但实际很好应对的真实场景：号源有限，多人抢号。这个场景足够支撑你写出有含金量的需求分析和系统设计，又在毕设时间限制内能顺利落地上线。

从技术栈分布来看，Spring Boot 负责后端接口和数据持久化，微信小程序 负责C端用户界面和交互，一个大三或大四学生只要按照"环境搭建 → 数据库设计 → 后端API开发 → 小程序页面开发 → 联调测试"这个路线走，整个项目周期可以控制在六到八周。相比纯网页端毕设，小程序选题还自带一个加分项：它可以在答辩现场用手机扫码演示，评委不需要在电脑上配环境、跑前端，体验上的说服力强很多。

但我必须先泼一盆冷水。正是因为做的人多，想要拿高分，或者说想在答辩时不被问倒，你就不能停留在"能跑就行"的水平。今年的答辩老师早就不满足于问"你这个系统有哪些表""登录是怎么实现的"，他们会追问："你的号源扣减是怎么防止超卖的？""小程序端的登录态是怎么维护的？""你用的JWT token失效了怎么处理？""MySQL的隔离级别知道吗，跟你这块有什么关系？"这些问题的背后，考察的恰恰是这个项目里最有技术含量的部分。这篇文章我把自己做这个项目时从零到一的全过程、踩过的坑、以及后期答辩中总结出来的经验完整拆给你看，全程的代码思路、表结构设计和调试细节都会包含在内。

这个项目适合下面的读者：正在选毕设课题、对Spring Boot和微信小程序都处于"学过但不太熟"阶段的同学，以及想快速掌握一个完整前后端分离全栈项目的初级开发者。如果你连Java基础语法和MySQL基本CRUD都还没过一遍，建议先去补一下基础，否则这篇内容读起来会有些吃力。

2. 两端的核心业务拆解：别急着写代码，先搞清楚"挂号"这件事到底有哪些关键路径

很多同学一拿到课题就急着启动项目初始化，其实这是大忌。医院挂号系统的难点不在增删改查，而在于"怎么把医院的业务流程用软件模型表达清楚"。我当时的做法是先画出完整的业务流程图，再拆功能模块，最后才落数据库表。这个顺序一旦反了，后期返工成本极高。

2.1 完整业务链：用户从打开小程序到完成挂号要经过哪些环节

用最通俗的话描述一个普通用户使用这个小程序的全过程：用户打开微信小程序，看到首页推荐了几个热门科室，点击"科室列表"进入所有科室页面，选定科室后看到该科室下的医生列表，点进某个医生的详情页能看到这个医生未来一周的排班日期和每个时间段的剩余号源。用户选一个自己方便的时间段，点击"预约挂号"，系统校验他还没有挂过这个时间段之后，生成一条挂号订单，并让他在小程序端确认支付或直接确认预约（视你设计的流程而定）。挂号成功后，用户在"我的预约"里能看到自己的号源记录，就诊时展示给医生看。如果需要取消，要在就诊前一天24点之前操作，取消后号源自动释放回池子里。

注意这里面隐藏了三条关键规则：号源不能超卖，也就是同一个时间段的号被两个人同时抢到是不允许的；同一位用户不能重复挂同一个时间段的号；取消预约的截止时间规则需要前端展示、后端校验共同保证。这三条规则就是你能不能把系统讲出深度的分水岭。很多网上能下载到的源码只做了表面CRUD，根本没有处理并发扣减号源的问题，答辩时老师随便一问就露馅了。我建议你在设计阶段就把这些问题定位为"系统的核心难点"，后面无论是写文档还是做代码实现，都围绕它们展开。

2.2 角色与功能模块：患者端、医生端、管理后台分别承担什么职责

整个系统可以归纳为三个角色，但对本科生毕设来说，医生端和管理后台往往合并为一套基于浏览器或者小程序端的后台管理页面。我在自己的项目里采用了"小程序患者端 + 小程序医生端 + Spring Boot管理后台接口"的混合模式，既保证了覆盖面，又控制了开发量。下面这张表格是我实际项目里的功能清单，你可以直接参考：

这套功能列表足以支撑毕业设计论文的需求分析章节。你的用例图、功能结构图都可以从这张表引申出来。如果时间充裕，可以考虑再加一个"公告管理"或者"就诊攻略"模块，丰富系统层次感；但如果你时间紧，这些锦上添花的功能不建议碰，核心的挂号链路做扎实才是关键。

2.3 业务规则量化：一个医生每天放多少号，怎么排班，怎么释放

排班和号源是挂号系统的"心脏"。业务规则设计得好不好，直接决定代码实现复杂度。我当时设计的是这样：一个医生在一个工作日内有一个或多个排班时段，每个排班时段有固定的号源总数（比如上午门诊放30个号）。数据库里不存"30个号"这种松散数字，而是把号源数落成一条条"号源记录"。比如某个医生上午的号源总数是30，我就初始化30条号源记录，每条记录对应一个具体的时间点（每10分钟一个号），用状态字段标记"可预约 / 已被挂 / 已锁定 / 已取消"。这种做法看起来比单纯在排班表里存一个剩余数字更笨重，但好处非常明显：并发控制时不需要对数字做复杂的原子自减，只需要针对某一条具体的号源记录做状态判定和更新，逻辑清晰且不容易出错。

号源释放遵循三条规则：患者主动取消则立即释放；系统时间超过就诊日当天凌晨0点未取消则不再允许取消（号源作废）；号源在某个时间点被用户锁定了但规定时间内未确认，则自动释放回池子。最后一条规则，也就是"锁定超时自动释放"，很多毕设项目根本不做，但在真实医院系统里是必须的，建议你至少做一个简化版本，哪怕只是在代码里用延时任务或者定时扫描实现，答辩时都能成为亮点。

3. Spring Boot后端设计：表结构、分层架构和关键接口的实现逻辑

说完了业务，开始动手搭后端。这一部分我会把核心的数据库表设计、后端分层方案，以及几个重要接口的思路全部展开。代码层面我不会把每一个Controller都贴出来，那会变成一篇流水账；我挑真正影响系统质量的部分讲。

3.1 数据库表设计：一张主表加五张辅表，怎么描述清楚整个业务

我做项目时的数据库表总共有八张左右，核心表可以精简为以下六张：

这里我想解释两个容易踩坑的细节。第一，为什么不把号源做成一个数字，而非要建一个ticket表？因为号源状态是并发修改的对象，如果只维护schedule表里的remain_count，AB两个用户同时请求时很容易出现两个人都读到剩余1个号、然后都扣减成功的超卖问题。而ticket表天然就是一个行级锁的天然载体，用UPDATE ticket SET status = '已挂', user_id = ? WHERE id = ? AND status = '可预约'一条语句就能原子地完成挂号占号，数据库行锁保证同一时刻只有一个请求能更新成功。第二，appointment表里的order_no要自己生成，不要用数据库自增主键暴露给用户，生成规则可以用时间戳加随机数，也可以用一个简单的雪花算法实现，这个细节放到文档里写"，显得很专业。

3.2 后端分层与Spring Boot项目结构：为什么controller-service-mapper这个经典三层依然是最佳实践

我见过的学生项目里，最崩溃的一种是一个Controller里堆了上千行业务代码、所有SQL都写在方法里。这不是做项目，这是给自己埋雷。Spring Boot的项目结构虽然网上讨论很多，但毕设阶段的黄金方案依然是经典三层外加一些辅助包：

code复制com.example.hospital
├── controller        // 接收请求，参数校验，返回统一结果
├── service           // 业务逻辑，事务控制
│   └── impl
├── mapper            // MyBatis-Plus的Mapper接口
├── entity            // 数据库实体
├── dto               // 前端入参对象
├── vo                // 前端出参对象
├── config            // 跨域、拦截器、全局异常处理
├── common            // 统一返回结果、枚举、工具类
└── utils             // JWT工具、日期工具、订单号生成工具

这种结构的好处是答辩时特别好讲。你可以说得很清楚：Controller层只负责接收参数和返回结果，Service层负责业务规则，Mapper层和数据库打交道。老师问"如果我要加一个支付功能，你改哪里"，你可以立刻回答"在Service层新增一个支付接口，并在预约成功后的逻辑里调用"。不需要多高深的设计模式，有条理就是加分项。

技术选型上我推荐直接用 Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0，不要去追Spring Boot 3.x。原因很务实：网上大多数教材、博客、源码都是基于2.x写的，遇到问题的时候能搜到的方案最多；而且你后面很可能要装的快速开发框架、代码生成器、各种starter对2.x的兼容性最稳定。JDK用1.8就好，别为了"新"去装JDK 17，否则一些老版本的依赖会直接报错。这不是不进步，这是毕设阶段求稳的核心策略。

3.3 微信登录后端如何配合：code换openid、自定义登录态、JWT签发与校验

登录环节是很多同学的噩梦，因为小程序端的登录跟传统网页登录完全不同。微信小程序不能像Web页面一样输入用户名密码，它的标准登录流程是：小程序端调用wx.login()拿到一个临时凭证code，把这个code发给后端；后端拿着code、appid和secret去请求微信接口，换来该用户在这个小程序里的唯一标识openid和会话密钥session_key；拿到openid后去数据库查这个用户是否存在，不存在就自动注册一个新账号；最后后端生成本系统自己的登录态返回给前端。以后的每次请求都带着这个登录态，后端通过校验它来识别用户身份。

我在项目里采用的是 JWT + 拦截器 的方案。用户登录成功后，后端生成一个JWT token，里面封装userId、openid和过期时间，返回给小程序端。小程序端每次调用需要身份的接口时，在请求头里带上Authorization: Bearer <token>。后端用一个拦截器统一校验token的合法性和有效期，校验通过才放行请求。这个方案代码量小、调式方便、而且不依赖Redis这类额外组件，特别适合毕设。很多同学会问：JWT天然有一个问题，就是服务端无法主动让token失效。如果你做了用户封禁功能，会有点尴尬。但毕设这个场景几乎不会涉及封号，所以不必过度设计。

有一个小坑我必须提醒你：不要在前端把用户的openid直接当登录凭证长期存储和使用。openid虽然能标识用户，但它是敏感数据，正确的做法是只在前端保存JWT token，需要用户身份的时候通过后端接口从token里解析。还有，一定要在微信小程序后台把request合法域名配置好，生产环境请求的域名必须是HTTPS并且备案过的，否则小程序里根本发不出网络请求。本地调试的时候可以在微信开发者工具里勾选"不校验合法域名"，这是一个能让你快速联调的后门，但上线前必须关掉。

3.4 核心接口的并发逻辑：防止号源超卖的三种可行方案

挂号这个动作是系统里最需要设计的地方。方案一，也是最简单的：在ticket表上利用数据库行锁，UPDATE ticket SET status='已挂' WHERE id=? AND status='可预约'，通过受影响行数判断是否成功。这个方案零额外依赖，代码就是一条SQL，性能足够支撑毕设。方案二，使用乐观锁：在schedule表里加一个version字段，扣减时判断version是否匹配，匹配才更新并让version+1。这个方法能在一定程度上解决超卖，但需要配合重试机制，否则并发高的场景下请求失败率会很高。方案三，使用Redis的原子操作扣减库存：性能最高，但毕设阶段引入Redis意味着要额外处理缓存和数据库的一致性、缓存预热等一堆问题，除非你本身对Redis很熟，否则不建议自己给自己加戏。

我当时选的是方案一，理由是它能用最简单的方式做到"绝不多卖一个号"，而且答辩时你能把数据库行锁、事务隔离级别、InnoDB的锁机制全部串起来讲，这比空谈理论强得多。附上核心的Service层代码思路：

java复制@Transactional(rollbackFor = Exception.class)
public AppointmentResult createAppointment(Long userId, Long ticketId) {
    // 1. 校验用户和号源是否存在（查询）
    // 2. 校验该用户是否已挂过同一排班的号（查appointment表）
    // 3. 尝试抢占号源：UPDATE ticket SET status=1, user_id=?, lock_expire_time=?
    //    WHERE id=? AND status=0 AND schedule_id=?
    int rows = ticketMapper.lockTicket(ticketId, userId);
    if (rows == 0) {
        return AppointmentResult.error("手慢了，号源已被抢走");
    }
    // 4. 生成订单号，插入appointment记录
    // 5. 更新schedule表的remain_count
    return AppointmentResult.success(orderNo);
}

你注意看，第3步是关键，这一条UPDATE语句在数据库层面是行级排他锁，两个事务同时更新同一条ticket记录时，后到的一方会被阻塞，最终只有一条语句影响行数为1，另一方拿到的影响行数为0，就此判负。事务外层加@Transactional保证第3步和第4步要么一起成功，要么一起回滚，避免出现号源扣了但订单没生成的脏数据。这套逻辑讲透，答辩环节基本稳了。

3.5 Spring Boot配置实战：application.yml里那些容易写错的地方

配置文件的坑，通常比写代码更折磨人。我总结一下最容易出错的几处。数据库连接串里，MySQL 8.0和5.7的驱动类名不同，5.7用com.mysql.jdbc.Driver，8.0之后要用com.mysql.cj.jdbc.Driver；连接串要加上useSSL=false&serverTimezone=Asia/Shanghai，前者避免本地环境SSL握手警告，后者解决时区问题，不加的话写入时间会出现"差8小时"的诡异现象。下面的配置可以直接抄：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: yourpassword
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

还有一个细节很容易被忽略：MyBatis-Plus的驼峰命名映射。默认开启下划线转驼峰，所以数据库字段create_time能自动映射到Java实体里的createTime。如果哪一天你发现查出来的字段全是null，先检查是不是在配置里关了map-underscore-to-camel-case。另外Spring Boot 2.7.x里，如果某天你启动时发现循环依赖报错，可以在配置里加spring.main.allow-circular-references: true，但更推荐的是去重构代码，避免两个Service互相调用来调用去。这个问题很隐蔽，网上大量老教程基于Spring Boot 2.5或更早版本，并没有这个限制，照抄就会出现问题，要注意甄别。

4. 小程序前端：从页面结构到接口对接的完整实现要点

后端接口写好之后，工作量的大头其实在小程序端。微信小程序的开发语言本质上就是JavaScript + WXML + WXSS，如果之前接触过Vue，上手会非常快。这一节我会从前端项目结构、关键页面实现、接口请求封装三个维度讲清楚。

4.1 小程序项目目录规划与底部导航配置

小程序开发工具创建项目时，选择"不使用云开发"就能得到一个干净的基础模板。我建议的目录结构是这样的：

code复制pages
├── index          // 首页，展示热门科室、快捷入口
├── department     // 科室列表页
├── doctor         // 医生列表页
├── doctorDetail   // 医生详情与排班选择页
├── confirmOrder   // 确认挂号页
├── orderList      // 我的预约列表
├── orderDetail    // 预约详情
├── mine           // 个人中心
└── login          // 登录页

app.json 里配置页面路由和底部TabBar，我这里设计的是三个主Tab：首页、预约（订单列表）、我的。TabBar图标需要在本地配置好，尺寸建议使用81px * 81px的PNG，太大的图标在真机上会被压缩变形，这是个小细节但直接影响UI观感。

为了可维护性，建议在项目根目录建一个utils/request.js，统一封装wx.request，把baseURL、token注入、响应状态处理全部放进这个文件里，页面里只需要引入并调用即可。我看过太多人每个页面里重复写一大堆wx.request，代码冗余不说，改个baseURL比登天还难。如果你在后端做了JWT登录态，小程序的请求封装里一定不要忘了从storage里取token并加到header里。响应拦截的逻辑也很简单：如果后端返回的状态码是401，就清理本地登录信息并跳转到登录页。这个逻辑不复杂，但能避免很多会话过期却莫名其妙报错的体验。

4.2 小程序登录细节：wx.login、getUserProfile和手机号快速验证的取舍

先理清一个概念：wx.login 获取的是临时code，它只能用来换openid，本身拿不到用户的头像昵称。以前可以用wx.getUserInfo弹窗获取用户头像昵称，2021年之后微信官方不再推荐这种方式，新的接口是wx.getUserProfile，通过用户主动点击行为触发授权弹窗，能得到头像昵称。这两种方式在实际项目里怎么配合？

推荐的做法是：进入小程序先静默登录，即调用wx.login拿到code，发到后端换取JWT token，这时的用户只是"临时登录"，主界面上可以看到内容；当用户需要挂号时，再弹窗引导补全头像昵称和手机号。手机号获取要注意，老版本用wx.getPhoneNumber在button上配置open-type="getPhoneNumber"，新版本微信已经改成了手机号快速验证组件，两者的返回值格式有差异，实现前一定要去微信官方文档确认你当前使用的版本。如果不想被这个环节折磨，可以在毕设里把手机号改成选填项，用户自己手动输入，彻底绕开微信接口的兼容性问题。反正毕设的核心是挂号系统，不是手机号验证。

4.3 排班选择页与号源展示：如何把后端排班数据渲染成用户友好的界面

这是整个小程序端我花时间最多的页面。用户进入医生详情后，后端返回的数据通常是：该医生未来七天的排班日期，每个日期下有哪些班次（上午、下午），每个班次下有哪些时段号源以及号源状态。底层数据结构是按排班聚合的List，但前端展示需要按日期、班次进行分组，这时就需要写一个分组的工具方法。

我用的是最简单直接的方案：后端接口直接返回一个已经按日期分好组的结构，前端只负责渲染。这种"后端多做一些、前端少操点心"的思路在小程序开发里很受用，因为小程序端的代码不能热更新，迭代成本比Web要高，把复杂的聚合逻辑放在后端，前端只需要做简单的wx:for渲染。日期分组后的WXML逻辑大致是这样：

xml复制<view class="schedule-group" wx:for="{{scheduleList}}" wx:key="workDate" wx:for-item="day">
  <view class="date-title">{{day.workDate}} 周{{day.weekText}}</view>
  <view class="time-slot" wx:for="{{day.timeSlots}}" wx:key="ticketId"
        wx:for-item="slot" bindtap="onSelectTicket" data-ticket="{{slot}}">
    <text>{{slot.ticketTime}}</text>
    <text class="status {{slot.status == 0 ? 'available' : 'disabled'}}">
      {{slot.status == 0 ? '可预约' : '已约满'}}
    </text>
  </view>
</view>

这里的slot.status最好在后端就处理成前端友好的枚举值：0可约，1已约满，2已取消。前端展示逻辑只需要判断0还是非0，简化了开发。在真机上调试时，一定记得把微信开发者工具里的"不校验合法域名"勾上，同时后端要解决跨域问题，Spring Boot里写一个CorsFilter或者使用@CrossOrigin注解，否则小程序请求会被浏览器同源策略拦一道。严格来说小程序环境不受Web跨域限制，但开发者工具里部分场景还是会碰到，提前配好不亏。

4.4 接口联调阶段你要注意的"六大怪象"

联调阶段，大概是最让人崩溃的阶段。我把碰到过的几个高频问题整理一下：

第一，请求能通但返回数据是空的：多半是后端字段命名和前端不一致，比如后端返回userId前端写成了user_id，这在Spring Boot + 小程序联调里非常常见。第二，post请求后端接收不到参数：后端用@RequestBody接收JSON时，前端wx.request的header里必须设置Content-Type: application/json，不要用默认的application/x-www-form-urlencoded。第三，中文乱码：数据库连接串没加characterEncoding=utf8。第四，时间显示成"2024-12-25T08:00:00"：后端Jackson没配置日期格式，前端可以硬切字符串，也可以在application.yml里配置spring.jackson.date-format。第五，开发工具正常但真机请求失败：基本可以断定是合法域名没配置或者还没同步，这时在开发工具里打开"不校验合法域名"也救不了真机，必须在微信公众平台配置好request合法域名再重新编译。第六，所有接口都401：检查拦截器是否把登录接口也拦截了，或者前端是否在登录完成前就发起了后续请求。

联调没有捷径，唯一的建议是：给后端接口写一份简单的接口文档，把每个接口的路径、方法、入参、出参列清楚，因为调Bug的时候查文档比翻代码快得多。

5. 调试运行的完整链路：从本机环境到真机演示，一步步排掉常见的地雷

这个课题的关键词里有"调试运行"三个字，说明调试是很多用户最容易卡住的环节。我带你完整走一遍从零到能演示的流程。这里的前提是你已经装好了JDK 1.8、Maven 3.6+、MySQL 8.0、微信开发者工具和IDEA。开发工具用IDEA，别问为什么，社区版完全够用，而且它约等于这个行业的默认配置。

5.1 本地环境检查清单：JDK、Maven、MySQL的版本搭配

环境不一致导致的问题往往最让人头疼。我的建议版本组合是：

有个检查方法很关键：在命令行输入java -version、mvn -v，确认输出的版本符合预期。很多人的电脑里装了多套JDK，IDEA里配置的是JDK 17，命令行里却是1.8，最终项目编译时各种报错，经常是环境变量跟IDE配置不一致导致。把IDEA的Project Structure里的SDK和Maven Runner里的JRE都手动指定成1.8，能少走很多弯路。

5.2 从GitHub/Gitee拿到源码后，10步跑通后端

收到源码包后，不要幻想"解压即用"，Spring Boot项目从克隆到运行必然要经过这几步。第一，用IDEA的File -> Open导入项目，等Maven把依赖下载完，这一步看网络状况，可能持续几分钟到十几分钟。第二，检查application.yml里面的数据库账号密码是否与你本地一致。第三，用Navicat或命令行执行项目里附带的hospital.sql脚本，把数据库建好。第四，确认MySQL服务已启动，Windows下可以在服务列表里找到MySQL80，如果没启动就手动启动。第五，直接运行主启动类HospitalApplication.java，看控制台日志是否出现Started HospitalApplication in x.xxx seconds。第六，打开浏览器访问http://localhost:8080/api/department/list，如果能返回JSON数据，后端就通了。第七，打开微信开发者工具，导入小程序前端项目，在app.js或者utils/request.js里把baseURL改成http://localhost:8080。第八，点击"详情 -> 本地设置"，勾选"不校验合法域名"。第九，编译小程序，如果能看到首页数据，前后端联调就算通了。第十，注册一个测试账号或者直接用微信登录，走一遍完整的挂号流程，确认号源扣减和订单生成都正常。

这个流程里最容易被卡住的位置是数据库导入那一步。如果你发现hospital.sql导入报错，最常见的原因是MySQL版本差异，比如脚本用了MySQL 8.0的语法、字符集设置或者存储引擎，而你本地是5.7。处理方法分两种：要么在5.7里手动把SQL文件里不支持的语法改掉，要么直接去装一个MySQL 8.0，长痛不如短痛。

5.3 启动报错的常见解法：端口占用、依赖下载失败、Maven傻傻分不清

我在帮人调项目时遇到过最多的三类启动错误及解法写在这里。端口占用：Port 8080 was already in use，这是最常见的，打开命令行执行netstat -ano | findstr 8080，找到占用端口的PID，在任务管理器里结束掉对应进程，或者直接修改application.yml里的server.port改成8081。Maven依赖下载失败：IDEA里pom.xml会疯狂报红，多半是网络原因没把依赖拉全，把本地仓库C:\Users\你的用户名\.m2\repository里对应的报错目录删掉，回到IDEA执行Maven -> Reload Project重新下载。启动类找不到：这通常是因为IDEA没有正确识别Spring Boot项目结构，右键点击HospitalApplication.java，选择Run即可启动，如果IDEA连主类的绿色三角都没有，检查一下是不是没有Project SDK。

关于Spring Boot版本太高这个热词搜索量很高，我的建议是不管源码里用的是多少版本，只要项目能正常编译运行，不要去动它。很多同学一看到pom里有版本号就容易手痒去升级，结果升级后各种注解失效、配置项改名，这不是给自己添堵吗？前面也说了，用2.7.x就是求稳，别折腾。

5.4 真机演示前的黄金三分钟：扫码演示如何做才不会翻车

答辩演示是最后一公里，至少提前一天做一次完整演练。第一，保证笔记本电脑和手机连接的是同一个网络热点或者同一个局域网；第二，后端启动时用--server.address=0.0.0.0，确保监听所有网卡，不要把地址绑定到127.0.0.1，否则手机访问不到你电脑上的接口；第三，微信开发者工具中把本地设置的"不校验合法域名"勾选好，但真机上依然要预览版才能调用本地接口，生成预览版二维码的方式是点工具正上方的"预览"按钮，手机会弹出二维码，扫码后在真机上打开。如果你使用的是体验版或正式版，网络层必须走HTTPS并且配置好合法域名，本地局域网IP是不被允许的。第四，提前在系统里准备好演示数据：一个患者账号、一个医生账号、几个有号源的排班，保证演示时不会出现"今天没有号源可挂"的尴尬情况。第五，如果演示现场网络不好，可以考虑先在开发者工具上把关键步骤截图保存，至少面子上说得过去。

6. 文档写作与答辩准备：怎么把项目从"能跑"讲到"很有深度"

到这个阶段，你的系统功能已经全部完成了，接下来是论文和答辩。很多人的论文就是流水账，大量截图加操作说明，答辩时被老师问两句就答不上来。其实抓住了评审逻辑，论文写作和答辩准备完全可以对症下药。

6.1 需求分析和系统设计部分怎么写才不像充话费送的

我见过太多论文，需求分析就一两页，系统设计也是一张架构图走天下。看起来篇幅很薄，其实是肚子里没货。要写厚、写实，你的切入点可以用核心业务链路分析：用户挂号流程涉及哪些状态变化、号源状态从"可预约"到"已锁定"再到"已挂"或"已取消"的转换规则是什么、取消预约的时限规则如何在前端和后端双重校验。把这些规则用文字、表格、状态图（论文里可以用状态图，注意不要用mermaid，用画图软件画好再插入）表达出来，这部分内容就非常扎实了。

系统设计章节要包括架构设计、功能模块设计、数据库设计、接口设计四大部分。数据库设计必须给出每张表的字段说明、字段类型、约束和索引设计；接口设计建议用表格列出各接口的路径、请求方式、入参、出参。这里的"接口设计"是有讲究的：不要只写接口路径，要写清参数的类型和校验规则。比如"获取医生排班接口，GET /api/schedule/list，参数doctorId（Long，必填）"，这种规格化的描述能体现你的工程素养。

6.2 答辩环节的高频追问和应对思路

答辩的追问通常围绕下面几个方向，每个都准备好，心里就有底了。

第一个方向是"为什么"。为什么用Spring Boot？为什么用MyBatis-Plus而不用JPA？为什么引入JWT？这里回答的思路不是"因为大家都在用"，而是从需求出发给出理由：Spring Boot简化配置、内嵌Tomcat、生态成熟；MyBatis-Plus对单表CRUD零SQL而复杂查询又能手写SQL，比JPA更可控；JWT无状态、易于水平扩展、小程序端存储简单。

第二个方向是"安全性"。数据库密码、微信appsecret等敏感信息怎么处理？不要硬编码在代码里，要放在配置文件且不提交到Git仓库。接口层的参数校验怎么做？要用Spring Validation框架，不要只靠前端。密码要不要加密？如果系统里有管理员的登录，密码一定要用BCrypt加密存储，不要用MD5，这是一个安全常识，你主动做出来，评审老师会觉得你有安全意识。

第三个方向是"并发与性能"。号源如何防止超卖？数据库行锁、乐观锁、Redis预扣减三选一，能讲清楚你用的那一种就够。从"单个医生排班剩余号数"的维度看，并发量级并不高，所以行锁方案完全够用。如果被问到"用户量大了怎么办"，可以从引入Redis缓存热门科室、引入消息队列削峰、数据库读写分离三个方向简要展开，不需要真正实现，能说出思路就行。

第四个方向是"扩展性"。如果要支持在线支付怎么办？加一步支付订单表，接入微信支付统一下单接口，前端调起支付，后端接收支付回调回调更新订单状态。如果要支持多院区怎么办？在department表或schedule表里增加院区字段，查询时增加筛选条件即可。这些扩展思路在论文的"不足与展望"章节里写出来，既有诚意又有深度。

6.3 文档附带的几个加分项：把演示视频和技术说明做到"拿来即用"

源码包里的文档如果能做到让人拿到手就能一步步跟着复现，这个项目就成功了。实践中，最容易被忽视的是少一个"环境搭建指南.md"。这份文档把JDK、Maven、MySQL、微信开发者工具、IDEA的安装和版本要求写清楚；把数据库导入步骤、后端启动步骤、小程序导入步骤分别列清楚；最后把常见报错和解决方案做成一个简表：报错信息、原因、解决方案。这份文件价值极高，不仅对你自己的后续维护有用，对老师、对可能使用这套代码做二次开发的人都是最好的说明书。

演示视频建议录成一个五分钟左右的短视频：先展示后端启动和数据库初始化，再展示小程序的登录、浏览科室、查看医生排班、预约挂号、取消预约全流程，最后展示管理后台的基础数据维护。视频要清晰、稳定、最好带关键步骤文字说明。这些材料聚合在一起，就不再是一个普通的毕设源码包，而是一份完整的教学实训项目。

7. 关于这套项目后续还能怎么扩展：几条真实的延伸思路

项目交付之后，如果你想在毕设基础上再挖掘一点价值，或者想在简历上多写一笔，可以从下面几个方向考虑扩展。一是接入真实在线支付：尽管医疗挂号系统通常不需要复杂支付流程，但模拟微信支付并完成后端回调处理，属于一个非常标准的第三方接口集成案例。二是增加管理端数据可视化报表：Spring Boot后端加一个ECharts的统计页面，统计各科室挂号量、医生接诊量、每日预约趋势，这种数据图表对用户和管理者来说一目了然，答辩时也很有视觉冲击力。三是搭建一个基于WebSocket的消息通知模块：用户挂号成功、医生排班变更时，系统主动推送消息到小程序端，这个功能虽然实现工作量不小，但一旦做出来，系统的实时性就上了一个台阶。

当然，扩展的方向也要考虑时间成本。如果是在答辩前一周才想起来要加功能，我建议你保守一点，不加功能，转而把已有的代码质量再打磨一遍：重构掉明显的重复代码、把Service层里散落的业务规则抽取成枚举和常量类、补充几个核心方法的单元测试。这些工作对答辩的加分效果同样明显，甚至比硬塞一个新功能更安全。

我个人在反复调试这类项目的过程中，最大的体会是：毕设考察的不是你用了多少新技术，而是你对一件事情的完整操盘能力——从需求分析、数据库建模、后端接口设计，到前端页面实现、联调排错、文档整理，再到答辩表达，这整条链路本身就是工程师日常工作的一个缩影。把这套项目吃透，你收获的不仅是一个可以交差的毕业设计，而是"如何从零完整交付一个前后端分离系统"的实战经验。这种能力，到了公司里依然受用。