Spring Boot医院预约挂号系统开发实战：从数据库设计到并发控制

每年到这个时间点，都会有一批计算机相关专业的同学为毕业设计挠头。如果你拿到的题目是“基于Spring Boot的医院预约挂号系统”或者“互联网医疗健康服务管理平台”，那这篇内容应该能帮你省掉不少调研时间。这个题目属于典型的Java Web全栈应用开发，标题里无论怎么写——医疗预约挂号平台、智慧医院在线诊疗预约还是互联网医疗健康服务管理，本质上都在描述同一个东西：用Spring Boot做后端，给患者提供线上挂号入口，给医生提供排班和接诊管理，给管理员提供平台运营后台。

这套系统非常适合做毕业设计，不是因为它简单，而是因为它功能边界清晰、业务场景贴近真实世界、技术栈足够主流。Spring Boot本身是当前Java后端开发的事实标准，MySQL存业务数据，Redis扛热点流量和验证码，前端用Vue或者Thymeleaf都可以。做下来之后你能讲清楚用户登录、科室检索、医生排班、号源锁定、预约记录、后台管理这一整条业务链路，在答辩时也经得起追问。下面我按自己做这类系统的完整思路，把这套平台的开发过程拆开讲清楚。

1. 这套系统到底在做什么

1.1 标题拆解：三个说法对应同一套业务

先说个实际经验。很多同学拿到这个题目后会疑惑，导师给的题目里同时出现“医疗预约挂号平台”“智慧医院在线诊疗预约系统”“互联网医疗健康服务管理平台”，这到底是几个系统？

我给你的建议是：一个系统，三层表述。第一层强调的是核心业务是“挂号”，第二层强调的是“在线预约”的诊疗服务模式，第三层强调的是平台具备“服务管理”能力。也就是说，系统的基础数据是医院、科室、医生、排班、患者，核心流程是患者在线选择科室和医生、查看可预约时间、提交预约，服务管理则是后台对医生排班、预约规则、号源数量进行配置和管理。有一个很加分的写法：把所有用户的线下问诊流程搬到线上后，还顺带把病历数据电子化，为后续的“电子健康档案”做好底层积累。这块要不要做深，视你自己时间而定，但在论文摘要里把它作为亮点提一下，是加分项。

1.2 三类角色与核心业务流

系统涉及三种核心角色——患者（前台用户）、医生、平台管理员。角色不同，界面和操作逻辑完全不一样：

• 患者端：注册登录、维护个人基本信息和就诊人管理（比如替家里老人挂号）、按科室和医生浏览排班、选择号源并提交预约、查看预约记录、取消预约。
• 医生端：查看自己的排班和当日待诊患者列表、标记接诊状态、查看患者历史预约记录。
• 管理员端：医生和科室数据管理、排班审核与配置、放号规则设置、数据统计、系统公告管理。

有一点容易被新手忽略：不要把患者和医生做成两个割裂的功能模块。真实系统中，一个用户可能既是患者（自己生病要挂号），又有医生身份（在医院执业），所以用户主表建议统一落在一张账号表里，用角色字段区分身份，而不是直接建patient表和doctor表。医生信息表通过user_id和账号表关联。这样设计的好处有两个，一是数据结构干净，避免重复注册逻辑；二是后续做权限控制时，可以直接基于用户角色进行接口拦截，Spring Security或自定义拦截器写起来都更顺手。

1.3 确立业务闭环：预约、就诊、记录

一个毕设课题如果有清晰的数据回环，至少说明你做的是“系统”而不是“页面集合”。预约挂号平台的业务闭环长这样：管理员维护基础数据 → 医生生成排班 → 患者查看并选择号源 → 预约成功后系统锁定号源/扣减余号 → 医生接诊并记录就诊状态 → 患者在“我的预约”中查看历史记录。

这里有一个体现思考深度的地方：预约凭证和“就诊状态”要独立管理。号源被占用后，患者按时到院找医生扫码或报号，医生在系统中确认接诊，此时预约记录变为“已完成”。如果患者预约后没来，管理员才能在后台将其标记为“爽约”。这个状态的流转设计，意味着你考虑到了真实医院里的“预约-到院-就诊-记录”路径，而不只是“提交预约”和“取消预约”两个动作。论文里写到这个点，也会让老师觉得你做过业务调研。

2. 技术方案选型：为什么是Spring Boot而不是其他

2.1 主流框架与配套组件清单

技术选型是这类项目答辩大概率被问到的问题。直接给出我这边推荐的组合：

Spring Boot的优势不用多说——它内置Tomcat，通过Maven或Gradle引入依赖后，编写一个带有@SpringBootApplication注解的入口类就能启动Web项目。大量Spring MVC的样板配置被自动完成，让你的重点放在业务逻辑而不是配置上。版本上建议选2.7.x而不是最新的3.x。原因很实际：3.x基于Jakarta EE规范，很多网上参考项目和课程资料还在用javax命名空间，你复制代码时容易踩包名不一致的坑。另外3.x对JDK有最低版本要求（JDK 17），而很多同学本机装的还是JDK 8。选2.7.x + JDK 8，是兼容性和获取参考资料方面最稳妥的组合。

另外要特别说一下MyBatis-Plus。它是在MyBatis基础上做了增强的持久层框架，单表操作几乎不需要手写SQL，内置的LambdaQueryWrapper让条件查询写起来非常舒服。比如“查询某个科室下今天有余号的排班”这种场景，用LambdaQueryWrapper拼接条件就能完成，查询结果再手动过滤余号字段，开发效率比原生MyBatis高出不少。再加上PaginationInnerInterceptor分页插件的配置，列表页的分页基本上就是几行代码的事。

2.2 单体架构为何是这个项目的最优解

你可能会看到一些博客给你的毕设提议微服务、Spring Cloud Alibaba之类的方案。我不建议这么干。预约挂号平台这个体量，用微服务纯属给自己挖坑。你需要维护的服务注册中心、网关、配置中心、多个服务模块，任何一个环节出了问题都会耗掉大量时间。毕设的核心任务是完整交付一个五脏俱全的软件系统，单体应用完全能满足需求。

单体架构下，你可以把所有业务放进一个工程中，按模块分包：

text复制com.hospital.appointment
├── controller        # 接口层
├── service           # 业务逻辑层
├── mapper            # MyBatis-Plus的Mapper接口
├── entity            # 数据库实体
├── dto               # 前端交互数据对象
├── vo                # 视图返回对象
├── config            # 配置类（Redis、拦截器、跨域等）
├── common            # 通用返回结果封装、异常处理、工具类
└── utils             # JWT工具等

这个分层写清楚之后，论文里画系统架构图也容易。面试官或答辩老师只要扫一眼包结构，就知道你对项目工程化是有意识的。如果后期想扩展，单体里也可以预留模块接口。比如预约和支付模块之间只通过Service方法调用，将来如果拆出独立的支付服务，改动点相对可控。

2.3 项目初始化：5分钟搭出一个可运行骨架

我建议你采用Maven方式构建Spring Boot项目，这也是目前团队协作中最主流的方式。如果你不用IDEA的Spring Initializr，也可以直接手写一个最简pom.xml，用Maven命令构建，理解会更深刻。

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
    <relativePath/>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>mybatis-plus-boot-starter</artifactId>
        <version>3.5.3</version>
    </dependency>
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
        <version>0.9.1</version>
    </dependency>
</dependencies>

一个常见问题是MySQL驱动的groupId在不同版本中不一样。Spring Boot 2.7.x默认管理的是mysql:mysql-connector-java，而更高版本里改成了com.mysql:mysql-connector-j。如果你从网上复制的依赖跑不起来，先检查这个坐标是否正确。

启动类不需要花哨写法，一个@SpringBootApplication注解加一个main方法就够了。很多教程会教你在启动类上再加@MapperScan("com.hospital.appointment.mapper")，这个注解的实际作用是扫描Mapper接口并注册为Bean。如果MyBatis-Plus已经配置好了，但启动时提示找不到Mapper，多半就是漏了这个注解。

3. 数据库设计与核心表结构解剖

3.1 核心业务表：从用户到预约记录

预约挂号系统的核心表不建议少于下面这些。每张表我都给出核心字段设计思路，你可以直接用它来生成建表SQL。

第一张表，用户表sys_user。字段包含id、username、password（BCrypt加密后存储）、real_name、phone、role（0-患者 1-医生 2-管理员）、avatar、status。这里建议加一个字段：id_card或部分身份证号，用于挂号时做实名制校验，这个点能体现你对医疗业务合规性的理解。

第二张表，科室表department。字段包含id、dept_name、dept_desc、sort_order、create_time。尽量在开发之前就把代表性科室数据录入：内科、外科、儿科、妇产科、骨科、眼科、耳鼻喉科、皮肤科，每个科室挂2-3个医生，演示效果才会丰满。

第三张表，医生表doctor_info。关键字段包含id、user_id（关联账号表）、dept_id（关联科室）、title（职称，主任医师/副主任医师/主治医师）、intro（擅长领域简介）、consult_fee（挂号费用）。注意consult_fee不要写成字符串，用decimal类型，后面统计科室收入时会用到。

第四张表，排班表schedule。这是整个系统业务复杂度的重心，字段包含id、doctor_id、dept_id、schedule_date（出诊日期）、period（上午/下午/晚间的时段）、total_count（总号量）、remain_count（剩余号量）、status（排班状态：正常/停诊）。同一医生同一天同一时段只能有一条排班记录，这个唯一性要在代码里确保。

第五张表，预约记录表appointment。核心字段包含id、patient_id（患者用户ID）、doctor_id、schedule_id、appointment_date、period、order_no（预约流水号，建议用时间戳+随机数生成）、status（0-待就诊 1-已完成 2-已取消 3-爽约）、create_time。这张表是整个系统增量最快的表，也应该作为统计报表的数据源。

除了这五张核心表，你还需要系统公告表notice，以及对患者很有用的就诊人信息表patient_profile——允许一个账号下维护多个实际就诊人，方便替父母或子女挂号，这个细节直接提升系统可用性。基础数据字典表sys_dict可选，但在论文里体现“字典管理”能力是加分项。

3.2 排班与号源分离的底层逻辑

很多第一次做这个项目的同学会把号源直接设计成排班表里的一个整数字段：total=30，remain=30，预约成功后remain自减1。这个做法看起来简单，但有一个潜在问题——你无法精确记录“到底哪个时间段被谁约走了”，也做不到精细化的号段管理。

如果时间和精力允许，建议使用排班与号源明细分离的模式。增加一张schedule_slot表：id、schedule_id、start_time、end_time、slot_no（号序）、status（0-空闲 1-锁定 2-已预约）。比如上午的排班生成30个号源记录，每个号源对应一个具体的就诊时间点，患者预约时选择的是某个具体的时间点，而不是模糊的“上午”。这样做的好处有三个：

一是业务流程更加真实。线上预约系统通常会让患者选择具体的时间点而不是仅仅选择上午/下午。
二是事务控制清晰。预约操作针对的是schedule_slot表中的某一行，后续可以基于这一行的状态来做乐观锁更新。
三是为“取消预约后释放号源”提供了精确定位。取消一条预约时，只需根据appointment_id反向找到对应的slot记录，把状态改回空闲，同时remain_count加1，不会出现余号数目和明细对不上的问题。

但也要说一句，明细号源模式需要多维护一张表，代码量会多一些。如果距离交设计只剩两周，用排班表余票扣减模式也能完整跑通业务，只是预约粒度只能到上下午。我的建议是：论文里把两种方案做一个对比描述，强调“本系统采用余号扣减方案，减少并发下的事务复杂度”，这样不会有任何问题。

3.3 状态机设计贯穿整个预约周期

预约记录的状态流转，值得单独画一个状态机来思考。它不是一个随便改改的字段，而是整个平台的业务秩序所在。

初始状态是“待就诊”。患者在预约截止时间前可以主动取消，此时状态变为“已取消”，同时号源释放。如果患者没有取消也没有到院就诊，系统需要在次日定时任务中扫描前一天的待就诊记录，统一置为“爽约”。医生接诊完成后，将状态标记为“已完成”。如果因为医生临时停诊导致排班被取消，管理员应当支持批量把受影响预约置为“已取消”，并且短信或站内信通知患者。这个逻辑最好在代码中提供一个批量处理的Service方法，而不是靠手动一条一条改数据库。

状态字段建议用Integer类型而不是字符串，因为整数比字符串更省存储、也更容易做索引。代码中需要定义常量或者在枚举类中声明，不要直接散落魔法值。实际开发中见过太多“把0写成1”“把2和3搞混”的Bug，都是因为状态值散落各处。用枚举集中管理状态值，是投入小收益大的习惯。

java复制public enum AppointmentStatus {
    PENDING(0, "待就诊"),
    FINISHED(1, "已完成"),
    CANCELED(2, "已取消"),
    NO_SHOW(3, "爽约");

    private final Integer code;
    private final String desc;

    AppointmentStatus(Integer code, String desc) {
        this.code = code;
        this.desc = desc;
    }
    // getter...
}

4. 后端核心模块的实操实现

4.1 用户登录认证：JWT + Redis方案替代Session

传统Java Web项目里，登录状态用HttpSession保存，登录后往session里塞一个user对象，后续请求从session取出。这个方案在单机部署下没什么问题，但现在流行前后端分离，而且将来如果系统部署在多台服务器上，Session同步就是个麻烦事。JWT方案天然适合这种场景。

我的做法是：用户输入用户名密码，后端校验成功后，生成一个包含用户id、用户名、角色信息的JWT Token，返回给前端。前端在后续请求的Header中带Authorization: Bearer 。后端拦截器解析Token，放行并将用户信息放入ThreadLocal或Request Attribute中。这样的好处是服务器无状态，不需要存储会话，天然支持横向扩展。

JWT工具类建议封装三个方法：生成Token、解析Token、校验Token。一个典型的JWT工具类代码如下。

java复制@Component
public class JwtUtils {
    @Value("${jwt.secret}")
    private String secret;
    @Value("${jwt.expire}")
    private Long expire;

    public String generateToken(Long userId, String username, Integer role) {
        return Jwts.builder()
                .claim("userId", userId)
                .claim("username", username)
                .claim("role", role)
                .setSubject(username)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + expire))
                .signWith(SignatureAlgorithm.HS256, secret)
                .compact();
    }

    public Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(secret)
                .parseClaimsJws(token)
                .getBody();
    }
}

注意secret不要硬编码在代码里，放到application.yml中配置，答辩时提到“敏感配置不落代码”会显得专业。Spring Security在这个项目中是可选的——如果你已经熟练使用拦截器，完全可以自定义HandlerInterceptor实现登录校验和角色鉴权，代码比引入Spring Security一整套更简单直接。如果为了给论文增加技术亮点，把Spring Security加进来并配置SecurityFilterChain，也可以。这里要评估你个人对框架的掌握程度，不要为了用而用，答辩时说不清反而扣分。

有一点千万要注意：不能只靠前端判断登录状态，后端必须层层设防。我见过太多毕设项目只在Vue路由里做了登录判断，接口裸奔无保护，被老师一个curl命令就把用户列表全拉出来了。所有以患者身份访问的接口，都必须经过JWT拦截器。白名单只有登录接口、注册接口、获取科室列表接口、获取医生排班接口，说白了，能让未登录用户看的信息就只限于浏览层面。

4.2 预约接口并发防重：乐观锁与Redis双保险

预约挂号的入口是整个系统并发压力最大的环节，尤其是名医专家号，放号瞬间可能涌入大量请求。如果代码不做并发控制，就会出现“同一时间点被两个患者约走”的超卖问题。

最直观的解决方案是数据库层面的行锁：更新排班表时执行UPDATE schedule SET remain_count = remain_count - 1 WHERE id = ? AND remain_count > 0，然后通过受影响行数判断扣减是否成功。受影响行数为0说明余票不足，直接返回“号源已约满”。MyBatis-Plus里对应这样一段自定义SQL。

java复制@Update("UPDATE schedule SET remain_count = remain_count - 1 WHERE id = #{scheduleId} AND remain_count > 0 AND status = 1")
int deductRemainCount(@Param("scheduleId") Long scheduleId);

此处要注意，不要再先查询一遍余票再在代码里if判断扣减。查询与更新之间存在时间差，在并发环境下两条线程可能读到同一个remain_count=1，然后都进入if分支执行扣减，最终把余票扣成负数。一定要用数据库本身的原子性来保证，让update操作本身帮你判断。

更稳妥一点的做法是先用Redis做前置闸门。放号时把号源数量写入Redis，每次预约先用DECR命令扣减，扣减后的值小于0说明已经被抢完。这个方案充分利用了Redis单线程命令执行的原子性，可以减少大量无效请求直接打进MySQL。需要注意Redis扣减成功和数据库扣减成功之间不是天然一致的，所以两者之间还需要一个补偿逻辑——如果数据库扣减失败，要把Redis中的余量加回来。整套编排就是先Redis预扣，再执行数据库更新，失败则回补Redis。写到这里已经能达到“系统设计考虑过并发一致性”的答辩高度了。

4.3 取消预约与号源释放

取消预约的逻辑比预想中容易出Bug。直接DELETE预约记录是最糟糕的做法——数据没了，后续统计和审计全无从谈起。正确做法是逻辑取消：把预约记录状态改为已取消，同时把对应排班的余号数量加回1。

这里需要在一个事务中完成：先校验当前患者是不是这条预约记录的归属人，再判断预约状态是否为待就诊，只有待就诊状态才能取消；然后将预约状态置为已取消，再执行排班余票加一。事务保证两个操作要么同时成功，要么同时失败。另外可以补充一个业务规则：预约时间已过且状态为待就诊，不允许取消，需要先走“爽约”标记流程。

为了提升系统的可用性，可以考虑在患者预约成功后把提醒任务放进延时队列，或简单一点，在登录后首页轮询展示近三天的预约提醒。用Redis实现延时队列有点复杂，建议通过定时任务每分钟扫一次appointment表，查询当前时间与预约日期匹配且未就诊的记录，推送一条站内信或调用阿里云短信服务。这样毕业设计的演示效果会明显高出一截。

4.4 管理后台需要关注的调度点

管理后台的排班配置是最能拉开项目完成度的模块。不要做一个简单的“新增排班”表单就完事，要支持批量生成：管理员选择科室、医生、出诊日期区间、每天时段号量，点击生成后，系统批量创建多条排班记录。

批量生成排班的代码逻辑在后面有一段判断——如果该医生在某个日期时段已有排班，是否跳过还是覆盖？现实中为了避免误操作覆盖已有排班，默认应该是跳过并提示冲突的日期。这个业务细节会让你在答辩时有的说。新增排班后，需要将号源总量写入Redis，作为后续预约扣减的初始值。修改排班导致号源数量变动时，也要同步把Redis中的值刷成数据库中的值。

停诊管理同样是加分项。管理员将某个排班置为“停诊”时，系统应该把这个排班对应的所有待就诊预约批量取消，并提醒患者。这个提醒可以简单做：在预约记录中新增一个cancel_reason字段，写入“医生停诊”，患者的“我的预约”页面就能看到该字段并知道发生了什么。这里的处理方式虽然不算智能，但逻辑闭环没问题。

5. 服务监控与系统运维：毕设演示不失手的保障

5.1 项目中的监控与健康检查

这一小节是很多网上开源项目不会教你的内容。毕设演示最怕的是一整年的代码在关键时刻“崩了但找不到原因”，或者SQL慢查询导致页面卡死无响应。Spring Boot Actuator是这样一个组件：引入依赖并做少量配置后，它会自动暴露一组HTTP端点，提供健康检查、指标信息、环境属性、线程信息等数据。

在pom.xml中引入依赖：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

基础配置：

properties复制management.endpoints.web.exposure.include=health,info,metrics,env
management.endpoint.health.show-details=always

启动项目后访问/actuator/health，你会看到类似{"status":"UP","components":{"db":{"status":"UP"},"redis":{"status":"UP"}}}的返回。这个接口的价值在于：数据库或Redis连接异常时，它直接反映出来。Micrometer作为Spring Boot Actuator底层的指标门面，提供了一套统一的度量工具，可以记录JVM内存使用、线程池状态、接口调用耗时。你在论文里提一句“通过Micrometer + Spring Boot Actuator实现系统运行状态可视化监控”，一个扩展开篇就上了个档次。

5.2 Maven方式构建并启动Spring Boot项目

在本地IDE里运行项目很容易，但别忽略了命令行启动技能——很多同学演示时用的是别人的电脑或服务器，没有IDE环境，那就要依赖Maven命令操作。

bash复制# 在项目根目录执行，跳过测试并打包
mvn clean package -DskipTests

# 启动打包产物
java -jar target/appointment-platform-0.0.1-SNAPSHOT.jar

# 通过命令行传参指定运行环境
java -jar target/appointment-platform-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

# 后台运行并将日志输出到文件
nohup java -jar target/appointment-platform-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

这里补充几个可能遇到的坑：第一，如果你在Windows下执行mvn命令提示“不是内部或外部命令”，说明Maven没有配置环境变量MAVEN_HOME和PATH。第二，打包时需要确保本地Maven仓库能下载到所有依赖，首次构建会比较慢，建议使用国内的Maven镜像源。第三，生产环境建议用Java 8或Java 11版本不要偏高，因为本地开发编译版本和生产运行版本不一致时，会出现“invalid target release”或“UnsupportedClassVersionError”报错。

如果导师明确要求用外置Tomcat部署，你就需要把Spring Boot默认的打包方式从jar改成war：

xml复制<packaging>war</packaging>

同时让启动类继承SpringBootServletInitializer并重写configure方法：

java复制@SpringBootApplication
public class AppointmentApplication extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
        return builder.sources(AppointmentApplication.class);
    }

    public static void main(String[] args) {
        SpringApplication.run(AppointmentApplication.class, args);
    }
}

打包后把war丢到Tomcat的webapps目录下就行。这条路能走通，但要注意：Spring Boot内嵌Tomcat版本和外置Tomcat版本差异可能导致一些API兼容问题，整体上内置Tomcat的方式还是更省心。

5.3 部署到Linux服务器的实操清单

毕设演示如果能从云服务器上打开网址，效果会明显加分。部署本身不复杂，但有几个环境层面的注意点。

项目配置中数据库连接的URL要写成服务器的内网地址或公网地址，Redis要配置密码，不能使用默认配置裸奔。执行Java jar包前，建议先配置一个systemd服务，让应用随系统启动且崩溃后可以自动重启。

ini复制[Unit]
Description=Appointment Platform
After=network.target

[Service]
User=root
WorkingDirectory=/opt/appointment
ExecStart=/usr/bin/java -Xms256m -Xmx512m -jar /opt/appointment/appointment-platform.jar
Restart=on-failure

[Install]
WantedBy=multi-user.target

然后用systemctl daemon-reload、systemctl enable appointment、systemctl start appointment三条命令把服务拉起来。这种部署形式比直接nohup执行显得更有工程素养。如果JVM内存占用飙升，使用jstat和jmap命令排查，这个操作已经属于线上问题处理范畴了。

6. 典型开发问题与排查经验

6.1 本地启动常见问题对照与解法

我在这里把参与过的Java Web项目里最常遇到的一批问题，和对应的排查思路整理成了一张速查表：

这里专门说下乱码问题。很多同学的开发机是Windows，MySQL服务端字符集可能默认是latin1，前端传过来UTF-8的中文数据存进库就变成“??”。解决方案是建库时指定UTF-8：

sql复制CREATE DATABASE appointment_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

同时数据源URL显式声明编码：

properties复制spring.datasource.url=jdbc:mysql://localhost:3306/appointment_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

6.2 并发那点事：从日志里找到Bug

并发超卖问题如果只在理论层面推演，很难被察觉。有一次我在本地用JMeter开200个线程同时请求预约接口，然后去查数据库，发现余号被扣成了负数，而预约记录只有150条，凭空多出50个“幽灵号”。排查过程很典型。

先看日志。日志里出现了大面积的“库存不足”提示，这说明部分请求确实被拦截了，但仍然存在扣减成功和库存不足界限模糊的窗口。SQL输出显示执行顺序是select remain_count，然后update remain_count = remain_count - 1。两个线程同时读到余号1，都认为自己抢到了号，然后连续执行update把余号扣成-1。修复方法就是前面说的，把查询+更新改为单条条件更新语句，同时确保调整后的字段有索引且支持行锁。这里推荐你写一个Test Controller把并发场景模拟出来，或者在答辩时口头描述利用JMeter测试和预期结果，非常加分。

6.3 面试答辩阶段容易被追问的6个点

这个项目做完之后，你需要准备下面这些高频追问的应答思路。这不是背诵，是为了确认你是真的做过，而不是搬运来的。

第一，为什么选Redis做验证码存储？因为Java Web传统Session无法解决分布式场景下会话共享，且Redis自带失效时间，可以用来做验证码有效期控制。

第二，如果同一个用户重复点击两次预约按钮怎么办？前端按钮置灰防止重复提交，后端用数据库唯一约束和事务保证同一患者同一时段只能存在一条待就诊记录。

第三，权限怎么控制的？后端拦截器解析JWT并判断角色，患者只能访问预约相关接口，医生端接口单独限定医生角色，管理员接口限定管理员角色。

第四，一个医生同时有多条排班，医生端如何知道当天要看哪些患者？通过doctor_id和appointment_date关联当前医生的待就诊预约记录，按时间排序展示。

第五，如何保证用户密码安全？BCrypt加密存储，而不是MD5，MD5已经不适合作为密码存储方案了，因为彩虹表攻击风险高。

第六，为什么所有接口返回统一的Result结构？将code、message、data封装为公共类，前端只用处理一种返回结构即可，后续扩展统一异常也方便。

7. 代码之外的加分项：测试与演示

我见过太多毕设项目从头到尾没写过一行测试代码，系统功能看起来全通，但答辩一演示就原地翻车。给你一个最省力的建议：不用追求JUnit单元测试覆盖率多高，但你至少要在本地把完整的“患者注册→登录→查科室→选医生→预约→医生登录→确认就诊→查看历史记录”主链路用接口测试跑一遍。我个人的习惯是用IDEA的HTTP Client脚本把关键请求串起来，或者用Postman导出Collection，回头演示时一条一条点过去，干净利落无废话。

还有一个容易被忽视的坑：演示数据。系统里如果只有两个医生和一个科室，演示效果会大打折扣。建议初始化一批数据：5个科室、10个医生、每个医生未来一周排班。再给这个医生账号配一条待就诊预约和一条已完成预约，这样演示时无论是患者视角还是医生视角都有内容可看。编写一个CommandLineRunner，在应用启动时执行初始化逻辑插入数据，或者直接提供一个init.sql脚本，提交论文时把初始数据部分写在文档中会更干净。

最后说一个个人体会。做这个毕设如果要追求高标准，不要把精力全放在堆页面和调接口上，最有价值的部分是业务建模能力和接口设计的意识。把用户数据模型设计得干净、把预约号源流转得严密、把排班和停诊这类边界场景处理到位，同时把所有模块间的调用关系梳理清楚，那么哪怕前端界面朴实一点，只要清晰规整、功能闭环，答辩老师也会感受到系统“骨架”是健康的。把核心业务捋顺之后，再多做一点页面交互细节上的打磨，比如预约倒计时提醒、就诊引导文案、管理端预览仪表盘，项目在毕业设计展览中的观感会好非常多。