SpringBoot+Vue+MySQL医院预约挂号系统源码详解与部署实战

做医院预约挂号这种选题的开发者，十有八九都走在同一条路上：要么是毕业设计，要么是接了个“帮某诊所/某医院做个挂号系统”的私活，要么就是自己想练手一套前后端分离的项目。SpringBoot后端加Vue前端再加MySQL这套组合，几乎是目前这个领域最标准的答案了。标题里“可直接运行”四个字是最关键的承诺，但真正拿到源码后能不能跑起来，取决于环境、数据库脚本、依赖版本一大堆细节。这篇就围绕这套医院预约挂号系统的源码，从设计思路、表结构、核心代码逻辑到本地部署，完整拆一遍，把那些文档里不会写、但实操里一定会遇到的坑也一并说清楚。

1. 项目定位与整体架构拆解

1.1 医院预约挂号系统到底在解决什么问题

先别急着看代码。任何一个信息管理系统，第一步要搞清楚的就是它的业务边界。医院预约挂号，表面上是“患者选科室选医生选时间，挂一个号”，但往深了想，这套系统至少牵扯到四方角色的诉求：

• 患者：查科室、查医生、看排班、在线挂号、查挂号记录、取消挂号。
• 医生：查看自己的排班表，确认接诊状态，可能还要看被挂号的的患者列表。
• 医院管理员：管理科室、管理医生信息、设置排班规则、查看挂号统计。
• 系统本身：必须保证号源不超卖、一个患者不能重复挂同一个医生的号、取消挂号后号源能释放、所有操作留有记录。

这套源码就是围绕这些业务动作去设计的。所以你拿到项目之后，第一步不是急着跑起来，而是先建立一张“业务流程→模块→数据库表→接口→前端页面”的映射表。比如“患者挂号”这个动作，在前端是点击一个按钮，在接口层是调用一个挂号接口，在业务层要做号源校验和重复校验，在数据库层必然涉及预约订单表的插入和号源表的扣减。一张映射表拉通之后，整个系统就透明了。

1.2 为什么选择SpringBoot+Vue+MySQL这套组合

这不是偶然，也不是单纯跟风。选型背后是有逻辑的。

SpringBoot在Java后端领域的地位不用多说。它解决的问题是“配置地狱”，通过自动配置和起步依赖，让一个Web后端项目能在几分钟内搭起来。对于预约挂号这种业务逻辑中等复杂、需要快速交付的系统，SpringBoot的生态非常合适——SpringMVC处理请求、Spring Data JPA或MyBatis操作数据库、Spring Security或JWT做认证，全部都有成熟方案。

Vue在前端领域最大的优势是渐进式和组件化。预约挂号系统的前端，有大量列表页（医生列表、科室列表）、表单页（挂号信息填写）、状态页（预约结果），这类交互用Vue的双向数据绑定和组件复用可以写得很舒服。而且Vue生态的Element UI或Element Plus组件库，几乎是管理系统的颜值天花板，表格、表单、日期选择器、弹窗提示全是现成的，开发效率远高于手写原生HTML。

MySQL更不用犹豫。预约挂号系统的数据量，撑死也就百万级订单，MySQL完全扛得住；事务支持是InnoDB的看家本领，而挂号这种强一致性的场景恰恰离不开事务；再加上免费开源、资料多、大家都会，选它是最稳妥的。

这套组合可以概括为：前后端分离、后端只出接口、前端只管交互、数据库负责持久化。分离带来的直接好处是，前后端可以并行开发，也可以分别部署，后期扩展成小程序端或者App端，只需要复写一套前端，后端接口基本不动。

1.3 系统整体模块划分

拿到源码后，通常能看到这样一个工程结构：

hospital-register/ ├── backend/ # SpringBoot后端工程 │ ├── src/main/java │ ├── src/main/resources │ └── pom.xml ├── frontend/ # Vue前端工程 │ ├── src │ ├── package.json │ └── vue.config.js └── database/ └── hospital.sql # 数据库初始化脚本

后端内部按包划分，常见的结构是：

• controller层：接收HTTP请求，做参数校验，返回统一结果。
• service层：核心业务逻辑，事务在这里控制。
• mapper/dao层：数据库操作。
• entity/model层：实体类映射。
• config层：跨域配置、拦截器配置、异常处理配置。
• util层：JWT工具、统一返回封装工具等。

前端内部按功能划分，常见的是：

• views：页面组件，比如Login.vue、Register.vue、DoctorList.vue。
• router：路由配置。
• store（如果有Vuex/Pinia）：全局状态管理。
• api：封装axios请求。
• components：复用组件。

模块之间是单向依赖的：Vue页面调API层，API层发HTTP请求到SpringBoot的Controller，Controller调Service，Service调Mapper，Mapper操作MySQL。这条链路非常清晰，无论是排查问题还是二次开发，沿着这条链走就不会迷路。

2. 数据库设计与核心表结构解析

2.1 用户、角色与权限的核心设计

预约挂号系统的用户绝不会只有一种。患者、医生、管理员，这三类角色如果各建一张表，逻辑上会冗余，因为都有账号、密码、姓名、手机号这些共性字段。更好的做法是“一张用户表+一个角色字段”，或者“用户表+角色表”多对多的经典RBAC模型。

这套源码如果是精简版，大概率采用前者——用户表加一个role字段，用整数区分角色（比如0表示管理员、1表示医生、2表示患者）。这样做对小型系统完全够用，登录后根据角色字段决定跳转哪个页面、调用哪些接口即可。

如果要做权限细粒度控制，就需要引入Spring Security或自定义拦截器，在拦截器里校验JWT携带的用户信息，再根据角色判断接口是否放行。我建议在二次开发时至少做一个简单的拦截器，因为很多源码只做了“登录校验”，没有做“角色校验”，会导致普通患者也能访问管理员接口，这在线上的安全风险很大。

用户表大致结构：

密码绝对禁止明文存储，至少用MD5加盐或BCrypt。很多教学性质的项目为了演示方便用了MD5加盐，生产环境建议升级为Spring Security内置的BCryptPasswordEncoder，抗字典攻击能力更强。

2.2 医生、科室、排班与预约的核心表结构

预约挂号的基础是“医生有排班、排班对应号源、号源被预约”。这个链路要拆成四张核心表：

科室表（department），字段简单：id、科室名称、科室简介、位置信息。

医生表（doctor），除了基本信息之外，关键是有department_id外键，以及title（职称，比如主任医师、副主任医师）和intro（擅长领域）。患者选择一个科室时，要能查出这个科室下所有医生，所以department_id必须建索引。

排班表（schedule），这是核心中的核心。字段包括：id、doctor_id、schedule_date（出诊日期）、time_slot（时间段，比如上午/下午或具体时段）、total_count（总号源数）、booked_count（已预约数）、status（排班状态：正常/停诊）。设计排班表时，很多人容易忽略booked_count这个字段，或者不知道它存在的意义。没有它，每次查询剩余号源就要统计预约订单表的总数，数据量一大就慢。冗余一个已预约数，查询时直接计算total_count - booked_count得到剩余号源，效率高得多。

预约订单表（appointment），记录每一次挂号行为。字段包括：id、user_id（患者）、schedule_id（排班）、doctor_id、appointment_date、time_slot、status（状态：待就诊/已完成/已取消）、create_time、cancel_time。注意这里出现了doctor_id和appointment_date等冗余字段，看似违背了数据库设计范式，但实际是出于查询效率考虑，避免每次查订单详情都要JOIN多张表，属于典型的空间换时间。

2.3 号源与订单状态流转设计

预约挂号本质上是一场资源分配游戏，核心规则是：一个号源只能被一个人持有，释放之后可以被下一个入。

订单状态流转必须能形成闭环：

• 患者提交挂号 → 创建订单，状态为“待就诊”（或“已预约”），同时booked_count加1。
• 患者取消挂号 → 订单状态改为“已取消”，同时booked_count减1。
• 医生确认就诊 → 订单状态改为“已完成”。
• 如果排班被管理员标记为“停诊”，对应订单要批量处理为“已取消”，并释放号源。

这套状态流转在代码里通常对应一个枚举类或者常量类，状态流转的合法性校验写在Service层。这里有一个容易踩的坑：取消挂号和扣减号源必须是同一个事务，否则可能出现订单取消了但号源没释放，或者号源释放了但订单还是待就诊状态的脏数据。

3. 后端核心功能实现：SpringBoot侧的重点与难点

3.1 预约挂号的并发与号源控制，这是全系统最核心的代码

预约挂号是个高并发场景。想象一下，某三甲医院某热门专家放号时间一到，几千个人同时点抢号，如果没有并发控制，就会出现超卖：号源剩余1个，却有5个人同时挂号成功。

源码里的核心代码会有类似这样的逻辑：

@Transactional public synchronized Result createAppointment(AppointmentDTO dto) { Schedule schedule = scheduleMapper.selectById(dto.getScheduleId()); if (schedule.getBookedCount() >= schedule.getTotalCount()) { return Result.error("号源已满"); } // 校验当前患者是否已预约过该排班 Integer count = appointmentMapper.countByUserIdAndScheduleId(dto.getUserId(), dto.getScheduleId()); if (count > 0) { return Result.error("您已预约过该时段"); } schedule.setBookedCount(schedule.getBookedCount() + 1); scheduleMapper.updateById(schedule); Appointment appointment = new Appointment(); // ... 填充字段 appointmentMapper.insert(appointment); return Result.success("挂号成功"); }

但这种用synchronized加锁的方式在单机部署时有效，缺点是锁在方法级别，并发量高时性能瓶颈明显，而且如果未来部署多实例，锁就失效了。

更好的方案是在数据库层做控制。比如在排班表上，更新号源时使用带条件的UPDATE：

UPDATE schedule SET booked_count = booked_count + 1 WHERE id = #{scheduleId} AND booked_count < total_count;

通过受影响行数判断是否更新成功，如果返回0说明号源已满，直接提示用户。真正上线级的系统还要用Redis做分布式锁或原子减库存，但作为教学和毕设级别的项目，这招带条件的UPDATE已经能解决绝大多数超卖问题，而且实现成本极低。

注意：事务注解必须加。挂号涉及订单表插入和排班表更新两个操作，任何一个失败都必须整体回滚，否则数据就错了。这个坑我见过不止一次——代码逻辑看着没问题，但忘了加@Transactional，测试时并发一跑，订单Create了排班却没更新，做前后端联调时半天查不出原因。

3.2 基于JWT的身份认证与接口权限控制

预约挂号系统必然需要用户登录。现在前后端分离项目的主流认证方案就是JWT（JSON Web Token）。

流程是这样的：

1. 用户提交用户名密码。
2. 后端校验通过后，生成一个JWT返回给前端。
3. 前端把JWT存到localStorage或sessionStorage，每次发起请求时在Header里带上Authorization: Bearer <token>。
4. 后端写一个拦截器，拦截需要认证的请求，解析并校验Token，从Token中获取用户ID和角色，存入请求上下文。

源码这里的重点在于Token的有效期处理和拦截器白名单配置。常见的路由路径设计：

• /api/user/login、/api/user/register：放行，免认证。
• /api/doctor/generateSchedule：需要管理员角色才能访问。
• /api/appointment/submit：需要患者登录。

拦截器里拿到用户角色后，判断当前请求的路径是否在对应角色允许的范围内。这里有个很实用的技巧：在Controller层写一个自定义注解，比如@RequireRole("admin")，然后在拦截器里通过反射判断方法上是否有这个注解，有则校验角色。这样权限控制就落到方法级别，比在拦截器里写死一堆路径匹配要优雅得多，后期维护也方便。

JWT的安全性有三点要特别提醒：

• 密钥不要硬编码，至少放到配置文件甚至环境变量里。
• Token过期时间不要设太长，否则泄露后风险很大，一般2小时左右比较合理。
• 登出功能不好做，因为JWT无状态。线上方案是维护Token黑名单，但教学项目大多忽略，也能理解。

3.3 后端统一返回格式与全局异常处理

前后端分离项目中，接口返回格式的统一是一件“没写之前无所谓，写了之后真香”的事。如果不做统一封装，有的接口返回{code:0,data:xxx}，有的直接返回{success:true}，前端axios拦截器里做统一处理时就会很痛苦。

成熟的源码会有一个Result类：

public class Result<T> { private Integer code; // 200成功，500失败 private String message; private T data; // 静态方法 success() error() }

所有Controller的返回值都用Result包装。前端axios响应拦截器里，先判断code是否等于200，等于200才走成功逻辑，否则提示message。这样不管后端有多少个接口，前端处理逻辑永远是同一套。

全局异常处理使用@RestControllerAdvice注解，定义一个类集中处理各种异常：

• 业务异常（ServiceException）→ 返回Result.error("具体业务错误")。
• 参数校验异常（MethodArgumentNotValidException）→ 返回Result.error("参数不正确")。
• 兜底异常（Exception）→ 返回Result.error("系统繁忙")，同时把堆栈打日志。

有了这个全局异常处理，Controller层就非常干净，不需要每个方法都写try-catch，业务代码看起来清爽无比。

4. 前端功能与交互设计：Vue侧的实现细节

4.1 页面结构与路由权限设计

Vue前端典型的页面结构包括：

• 登录页
• 注册页
• 患者端首页（按科室找医生）
• 医生列表页
• 医生详情页（排班信息、选时段、确认挂号）
• 挂号记录页
• 个人信息页
• 管理员后台（科室管理、医生管理、排班管理、挂号统计）

路由设计上，最关键的是路由守卫。Vue Router提供了beforeEach导航守卫，可以在页面跳转前做认证判断：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (!token && to.path !== '/login' && to.path !== '/register') { next('/login'); } else { next(); } });

角色不同，能访问的页面也不同。管理员访问患者页面没问题，但患者访问管理员后台就必须拦截。这里可以结合Vue的路由配置元信息meta: { role: 'admin' }，在守卫里再判断一次角色，字段不匹配就重定向到首页。这种双保险是做管理系统的标配，后端有接口拦截、前端有路由拦截，两层都做了才叫真正的权限控制。

4.2 从“查医生”到“预约成功”的完整交互链路

前端的核心业务场景就是预约挂号，这个流程里的交互细节，能直接看出代码的完成度。

第一步：患者进入首页，看到科室列表。点击科室后，跳转到该科室的医生列表页。

第二步：医生列表页展示医生的头像、姓名、职称、擅长领域、预约量等信息。这里往往会有一个“排班查询”按钮，点击后弹出日期选择器。

第三步：选择日期后，前端向后端请求该医生当天的排班时段。后端返回类似这样的数据：

{ "scheduleId": 27, "date": "2025-01-15", "timeSlot": "09:00-09:30", "totalCount": 20, "bookedCount": 15, "remainCount": 5 }

前端展示“剩余5个号”，如果剩余为0，按钮置灰不可点击。这一步的交互细节很重要——有些糟糕的实现是等用户点击后才提示“已满”，而优秀的实现是在展示排班时段时就把剩余号源展示出来，减少无效点击。

第四步：用户提交挂号。这需要一个二次确认弹窗，因为挂号是一个会产生实际数据的操作，防止误触。提交成功后，页面跳转到“挂号记录”，状态为“待就诊”。

这个链路看起来不难，但真正的考验在于细节：医生列表页的加载速度、日期切换时数据的刷新、提交按钮的防重复点击。尤其是最后的防重复点击，很多项目忽略了，导致用户快速点两下提交，后端又没有对应的幂等控制，就会出现两条订单。前端在提交时用一个isSubmitting标志位，提交中禁用按钮，这个几十秒就能写完的代码，价值却非常大。

4.3 前后端联调与跨域问题

“直接可运行”的源代码，最怕的就是联调时跨域报错。当Vue前端跑在http://localhost:8080，SpringBoot后端跑在http://localhost:8081，前端发请求时浏览器就会报跨域错误。

解决方式通常有两种。

方式一：后端开启CORS配置。在SpringBoot中写一个WebMvcConfigurer配置类：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true); } }

方式二：前端配置代理。在Vue的vue.config.js中：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } }

前端发请求时用/api/xxx，代理服务器把请求转发到后端，浏览器端就没有跨域问题了。这种方式在开发环境下更常用，因为它不会修改后端代码的CORS策略，上线时前端部署到和后端同域的位置，也就不存在跨域。我个人更推荐代理方案，因为后端配置allowCredentials(true)配合allowedOriginPatterns("*")在某些浏览器版本下有坑，代理方案更省心。

5. 实操过程中的部署运行全流程记录

5.1 环境准备与版本选择，这一步出问题的概率最高

拿到源码后第一件事不是双击运行，而是检查环境。

需要准备的工具和版本，我强烈建议按这个组合来配置：

检查顺序是：先看pom.xml里的SpringBoot版本，再看package.json里的Vue版本，最后看application.yml里的数据库配置。

有一个坑必须专门提：MySQL 8.0的驱动类变成了com.mysql.cj.jdbc.Driver，并且需要时区配置serverTimezone=Asia/Shanghai，很多老旧源码还是com.mysql.jdbc.Driver，直接启动会报“Loading class ... is deprecated”警告或连接失败，要改成8.0的写法。另外MySQL 8.0默认的密码认证插件是caching_sha2_password，有些旧版JDBC驱动不认，要么在连接串里加上allowPublicKeyRetrieval=true，要么把用户的认证插件改回mysql_native_password。这些属于不写在README里、但人人都会遇到的经典问题。

5.2 数据库初始化的正确姿势

数据库脚本（通常是hospital.sql）拿到手后，不要急着在命令行里一把梭执行。推荐做法是：

1. 打开MySQL命令行或Navicat，新建数据库，字符集选择utf8mb4——这个字符集能存四字节的Emoji和生僻字，老项目用utf8的话，将来患者姓名里有个生僻字就写入失败。
2. 选择该数据库后，运行SQL脚本。
3. 执行完成后，检查几张核心表是否创建成功，通过SELECT COUNT(*) FROM user查看是否插入了初始账号（通常有管理员账号可以直接登录后台）。

初始化数据很关键。很多源码的SQL脚本里带了演示数据，比如几个科室、几个医生、几天的排班，这是为了让你登录后页面不空。如果脚本里没有初始排班数据，登录后你会发现找不到任何可预约的医生，这时候需要自己手动在管理员后台创建科室、医生、排班。

这里有一个小技巧：用Navicat直接打开SQL脚本执行时，如果脚本里包含了创建存储过程或触发器的语句，某些图形化工具会因为分隔符问题报错。遇到这种情况，优先用命令行执行：mysql -u root -p hospital < hospital.sql，成功率最高。

5.3 后端启动步骤：从配置修改到成功跑通

修改application.yml是后端启动前的必经步骤。需要注意的配置项：

server: port: 8081 spring: datasource: url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB

密码改成自己本地的数据库密码，这个不用多说。但服务端口要注意——如果8081被占用，改成8080或者9090之类的空闲端口，改完后前端代理的target地址也要同步改。

启动时用IDEA打开backend文件夹，等待Maven下载依赖（第一次启动需要一些时间），然后找到主类（通常是Application或HospitalApplication），右键点击Run。

后端启动成功的判断标准：控制台出现类似Tomcat started on port(s): 8081或者Started Application in X.XX seconds的日志，并且没有红色堆栈异常。

常见的启动失败原因，我遇到过三种：

• 端口被占用：启动报Port 8081 was already in use，要么关掉占用进程，要么改端口。
• 数据库连接失败：报Cannot create PoolableConnectionFactory，九成是账号密码或URL配置错误，用命令行先测一下mysql -u root -p能否登录。
• 表不存在：报Table 'hospital.user' doesn't exist，说明SQL脚本没执行成功，回到上一步重新初始化。

5.4 前端启动步骤与常见问题处理

前端相对简单，但有两个问题特别常见。

打开终端，进入frontend目录，先执行依赖安装：

npm install

npm install是个玄学操作，有时候一次就成，有时候会卡住或报错。在国内网络环境下，node-sass、chromedriver这类需要下载二进制文件的依赖最容易失败。解决方式是配置镜像源：在项目根目录创建.npmrc文件，写入：

registry=https://registry.npmmirror.com sass_binary_site=https://npmmirror.com/mirrors/node-sass

然后重新执行npm install。如果之前已经安装到一半，先把node_modules文件夹删掉再重装，不然容易有残留的坏包。

依赖安装成功后，执行：

npm run serve

看到类似App running at: Local: http://localhost:8080就说明前端启动成功。用浏览器打开这个地址，能看到登录页，说明前后端起码各自是通的。

前端启动时另外会踩的一个坑是Node版本不匹配。Vue 2项目搭配Element UI时，Node 17以上的版本在运行npm run serve时会报ERR_OSSL_EVP_UNSUPPORTED错误，这是因为OpenSSL的哈希算法限制变了。解决方案有两个：一是降Node版本到16.x；二是在package.json的scripts里修改启动命令为set NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service serve。我自己处理这种问题时，更倾向直接用Node 16，一劳永逸。

5.5 账号体系打通：从登录到访问后台

前后端都启动成功后，用数据库里预设的管理员账号登录（注意看SQL脚本里的INSERT语句，管理员账号密码通常在注释里有说明，常见的如admin / 123456）。如果登录报错“用户名或密码错误”，但是SQL脚本确实执行了，检查一下登录接口的逻辑，有可能密码在初始化脚本里是加密存储的，直接明文登录不进去，需要通过注册接口或者密码工具类生成加密后的密文再更新到数据库。

登录成功后，浏览器F12打开开发者工具，切到Network面板，能看到登录请求返回了一个JWT Token，后续请求的Header里都会带Authorization字段。到这个状态，前后端链路就彻底打通了。

6. 常见问题与排查技巧实录

6.1 跨域报错：从“接口500”到“前端拿不到数据”的伪装

前后端分离项目里，跨域报错有时候会伪装成其他错误，容易误导排查方向。

一个我遇到过的场景：前端登录页输入账号密码，点击登录后，F12看到请求状态码是200，但响应体是localhost:8081/api/user/login 404。仔细看才发现，前端请求的URL是/api/user/login，但代理转发没生效，实际请求打到了8080端口的Vue开发服务器上，Vue路由把/api/user/login当成前端路由处理了，返回了200和首页的HTML。

排查跨域问题的标准姿势是：先在浏览器直接访问后端接口地址http://localhost:8081/api/user/login，看能否返回JSON。能返回就说明后端接口没问题，问题出在前端代理或CORS配置上。用curl直接模拟请求也很方便：

curl -X POST http://localhost:8081/api/user/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"123456"}'

能拿到JSON说明后端链路（包括数据库）是通的，然后逐层往前排查。

6.2 数据库连接失败：一个关于空密码的经典教训

有些源码为了本地测试方便，把spring.datasource.password留空。如果你本地的MySQL root账号设了密码，启动时会报连接失败。反过来，如果你本地MySQL是空密码，源码里却写了密码，也会连不上。

这个问题的本质是环境信息与代码配置不一致。正确的处理方式是：把自己本地的数据库账号密码填到配置文件里，而不是反过来去改MySQL的密码。改MySQL密码会牵连其他项目，得不偿失。

6.3 排班数据不显示：需要先检查时间字段

前后端联调时，患者端点了医生排班后页面一直空白或者提示“暂无排班”，第一反应不要盯着前端渲染代码看，先用浏览器直接请求后端接口，确认返回数据是否为空。如果接口确实返回空，大概率是排班表里的schedule_date字段时间范围不对——比如SQL脚本里预置的排班是前几周的，或者根本没有排班数据。

这种问题通过管理员后台手动新增一条排班记录就能验证。在排班管理页面选医生、选日期、填号源总数，保存后再去患者端查，如果数据出来了，说明业务链路是通的，之前的“Bug”只是没有可用数据，根本不是代码问题。

6.4 更新数据库密码字段后仍提示登录失败

这个坑比较隐蔽。很多系统在注册接口里把用户的密码做了某种加密（比如MD5加盐），但管理员修改密码的接口直接用明文更新到数据库，导致两条链路生成的密码格式不一致，用户用新密码登录时无论如何都不对。

排查思路：在数据库里查一下user表的password字段，看看是老用户的32位十六进制字符串还是明文。如果是明文，试着用旧密码登录；如果都是密文，把修改密码接口的代码和注册接口的代码并排对照，确认它们是否用了同一个加密工具类。这种问题通常是二次开发时改了加密逻辑但没有完全统一导致的。

7. 二次开发与扩展方向

7.1 从“能用”到“好用”的四个改造建议

一套能跑起来的预约挂号系统是起点，距离“真正能上线给人用”还有不少距离。如果要做二次开发，我建议优先考虑以下四个方向：

第一，引入Redis优化高并发抢号。目前基于数据库的号源控制能解决低并发超卖，但真要面对高并发瞬时流量，数据库扛不住。用Redis的DECR指令原子扣减号源，提前把号源数量缓存到Redis，抢号请求先打Redis，成功后再异步落库，性能和一致性都能兼顾。

第二，增加短信/邮件通知。预约成功和停诊改期，患者需要一个及时的通知渠道。接入第三方短信服务的成本不高，但价值很大。

第三，增加支付功能。如果医院要求在线支付挂号费，就需要对接支付接口。这会引入支付回调处理、订单状态增加“已支付”、退款逻辑等一整套流程，复杂度上一个台阶。

第四，增加排班规则的灵活性。现在的系统大多手工设置排班，好一点的方向是做成周规则式排班：定义“每周一上午的9:00-12:00出诊”，系统自动生成未来N周的排班数据。这能大幅减少管理员的重复劳动，也是让这个系统从课程设计走向实际应用的关键一步。

7.2 部署上线时不能忽略的安全底座

如果项目要部署到云服务器，有不少配置需要加固。配置文件里的数据库密码建议用环境变量注入，不要明文写在application.yml里提交到代码仓库；后端接口的JWT密钥建议设置一个随机的长字符串；前端通过Nginx部署时，配置location /api反向代理到后端服务，同时开启HTTPS保证数据传输加密；管理员后台建议再叠加一层IP白名单。

另外还有一个小细节：SpringBoot生产环境启动时，不要用java -jar后加--spring.profiles.active=dev这种裸奔方式，至少加一个-Xms512m -Xmx512m控制JVM堆内存，防止内存溢出让整台服务器卡死。

7.3 把这套源码作为学习素材的最佳打开方式

这套源码的价值不只是“能跑”，更在于它是一份完整的前后端分离项目的活教材。学习的时候，我建议按三层来吸收：

• 第一层：能跑会改。先按前文步骤把项目跑起来，再改改页面上的文字、换换颜色、加一个字段，熟悉整个工程的骨架。
• 第二层：理解链路。从前端点一次“挂号”，数据是怎么从Vue组件到axios、再到Controller、Service、Mapper、最后落到MySQL的，画出这条链路，理解每一层存在的意义。
• 第三层：重构优化。尝试自己动手把某个环节替换成更高级的方案，比如把数据库加锁扣减号源改成Redis扣减、把JWT拦截器换成Spring Security、给每个实体类加上MyBatis-Plus的LambdaQueryWrapper。改完一个环节，能力就上一个台阶。

我在帮人review同类毕设项目时发现，很多人拿到源码只关心“能不能跑”，完全没花时间理解代码之间的调用关系，一到答辩被问“你的流程是怎么设计的”就支支吾吾。源码是死的，理解是活的。把“患者挂号”这条主链路彻底走通，这个项目就算真正属于你了。

最后分享一个我自己在本地跑这类项目时的习惯：启动后端前，先把MySQL服务、Redis服务（如果故事里用到）都确认启动好，开一个终端专门盯后端日志，开另一个终端盯前端编译输出。日志是所有排查的第一线索——后端日志看到Started Application再操作前端，前端日志看到Compiled successfully再打开浏览器。顺序对了，整个联调过程会顺畅很多。