企业官网建设流程全解析

1. 课题拆解：从“预约挂号系统”到“医患交互平台”

毕业设计选“医疗预约挂号系统”这类题目的同学，每年都特别多，但真正能拿高分的版本却不太多。原因很简单：大多数同学把重点放在了“挂号”两个字上，做成一个CRUD的增删改查页面，然后草草收场。实际上，标题里每一个词组都值得拆开细看——Spring Boot框架、Java Web、在线预约诊疗服务平台、门诊智能预约、医患交互系统，这五个关键词背后对应的是一整套完整的业务链路和考核维度。

先聊一下这个课题到底是什么层次的东西。“预约挂号”只是患者侧能看到的入口，完整系统至少包括三个端：患者端负责注册登录、科室浏览、医生查询、号源预约、费用支付、就诊评价；医生端负责排班查看、坐诊确认、患者查看、诊断开方；管理员端负责科室管理、医生账号管理、排班校验、号源监控、数据统计。把这三块打通，才能叫做“服务平台”，否则就只是一个小demo。

再说“智能预约”三个字。智能的核心不只是“能预约”，而是“预约得准、预约得稳”。预约得准依靠合理的排班模型和号源容量设计；预约得稳依靠数据库层面的事务控制、并发锁机制和防重复提交。这两个点恰恰是毕业设计答辩时最容易拉开差距的地方。而“医患交互”又是另一个被忽视的维度，很多同学做的系统挂完号就彻底断掉了连接，没有随访、没有沟通、没有评价闭环，这种状态下“医患交互系统开发”就名不副实。

这篇内容面向的读者有两类：一是准备拿这类课题做毕业设计或者个人练手项目的同学，二是正在带这类项目的指导教师。我会把选题拆解、表结构设计、核心业务逻辑、并发处理、权限校验、交互拓展这一整条链路完整铺开讲，配合可以直接参考的代码片段和踩坑记录，尽量让这篇东西既能当开发指导文档用，也能当答辩准备手册看。

2. 核心需求解析：先把“用户故事”写清楚再谈技术

2.1 三类角色的核心诉求

画用例图之前，先想明白谁在用这个系统。患者需要的是“最短路径完成预约”：打开系统、看到科室、选到医生、确定时间、挂号支付，整个过程最好不超过四步。医生需要的是“清晰不冲突的排班”：每天哪个时间段坐诊、剩余多少号源、已经预约了哪些患者，一眼能看清楚。管理员关心的是“数据不混乱、业务不崩盘”：号源可配置、医生排班可追溯、每日挂号流水可导出、异常订单可处理。

这三类诉求放在一起你会发现，系统的复杂度主要不是来自功能数量，而是来自三个角色的数据在同一套业务规则下要互相咬合。比如医生修改排班，会直接影响患者已经挂出的号源；管理员停诊操作，必须触发患者退号提醒；患者未按时就诊，要影响医生的爽约记录。每一种关联都是设计表结构时要提前埋下伏笔的。

2.2 业务流程闭环

一套完整的预约业务链路大概是这样：管理员创建科室 → 管理员为科室添加医生账号 → 医生在排班页面提交未来一周的坐诊计划 → 管理员审核排班并锁定号源池 → 患者在系统内搜索科室和医生 → 患者锁定号源并提交订单 → 支付成功生成电子挂号单 → 患者按时间到院就诊 → 医生完成接诊并填写诊断信息 → 患者可以对服务评价 → 管理员看到数据统计。

这条链路中，任何一个环节脱节都会导致业务流断裂。举个典型例子：患者支付完毕，医生因为临时会议停诊，如果系统做了自动退号和短信提醒，体验就完全是医院级别的；如果没有任何处理，患者到了现场才发现白跑一趟，整个系统就失去了“服务”的意义。所以“在线预约诊疗服务平台”说的不只是一个预约工具，而是一整套异常处理机制。

2.3 功能拆分清单

按模块拆分，我一般建议参考下面的清单来规划开发顺序：

• 用户体系：患者注册登录、医生账号管理、管理员账号管理（三种角色可以融合进一张用户表，也可以分表，后面细讲）
• 基础数据：科室管理、医生资料管理、号源类型维护（普通号/专家号/特需号）
• 排班管理：医生提交排班、排班审核、号源自动生成、停诊改诊
• 预约核心：号源锁定、订单创建、在线支付（测试环境可模拟）、挂号单生成、取消预约
• 医患交互：问诊留言、就诊记录查询、服务评价、健康提醒
• 统计报表：科室预约量统计、医生坐诊量统计、患者来源分析、营收流水

功能清单不建议一次全部做完，开发顺序非常关键。优先级最高的是排班管理和预约核心，这两块是整个系统的命门。其次是用户体系和权限控制，这两块支撑所有业务功能能够安全运行。医患交互和统计报表放在第三梯队，等主流程跑通之后再扩展，不会影响整体进度。

3. 技术选型解析：Spring Boot这个底座到底选得对不对

3.1 主流技术栈与Spring Boot的位置

Java Web方向做毕业设计，目前主流选择大体上有这么几种：纯JSP/Servlet模式、SSM（Spring + Spring MVC + MyBatis）模式、Spring Boot + Thymeleaf模式、Spring Boot + Vue前后端分离模式、微服务拆分模式。

前两种基本属于过时技术栈，如果不是导师明确要求，不建议再用。微服务拆分对毕业设计来说有点用力过猛，光把各个中间件配起来就要花掉大量时间，业务本身又没有那么大的体量，得不偿失。最合适的区间就是Spring Boot + 模板引擎（Thymeleaf），或者Spring Boot + Vue前后端分离。

Spring Boot在这个项目里的优势非常明显。第一，自动化配置帮你去掉了大量繁琐的XML配置，开发效率高，你可以把时间用在真正拉分的业务逻辑上而不是配环境。第二，起步依赖（Starter）机制让引入功能特别轻量，比如你要用消息推送，加入WebSocket的Starter就可以开工，不需要从头搭环境。第三，Spring Boot的嵌入式Web容器让部署变简单，一个Jar包打出来就能跑，答辩现场演示的时候不用花半天调Tomcat。第四，Spring生态的扩展能力很强，从数据校验到安全框架都有现成的整合方案，做到后期你就会发现这套体系省心得多。

3.2 为什么要用MyBatis而不是Spring Data JPA

很多教材里用的是Spring Data JPA，这个技术确实写起来代码少，但我在实际项目经验里强烈建议毕业设计选MyBatis或MyBatis-Plus。原因很直接：医疗预约系统的数据查询有大量复杂的动态拼接场景。比如患者按科室、职称、日期筛选医生，这些查询条件组合起来非常多，JPA会生成很冗余的SQL，调试起来特别痛苦。MyBatis的XML映射文件可以精确控制每一条SQL，业务逻辑看得清清楚楚，答辩的时候你拿到数据库查一条记录，能直接说出来对应哪段查询逻辑，这种“清清楚楚”在项目展示中非常重要。

MyBatis-Plus则是在MyBatis基础上把单表CRUD操作简化了很多，内置分页插件，开发效率很高，适合毕业设计这种表结构清晰、单表操作居多的场景。我在下面代码示例里默认使用MyBatis-Plus，如果你习惯原生MyBatis，逻辑也是完全一致的。

3.3 数据库和中间件的合理搭配

数据存储选MySQL基本没有争议。MySQL的InnoDB引擎支持事务和外键，这对于预约这种对数据一致性要求极高的业务场景是必要条件。

Redis在这个系统里要不要上，要看你准备做到什么深度。如果你的方案只是基础版，就靠数据库的唯一索引来防重复；如果做到“智能预约”的水准，号源剩余数量这样的热点数据建议放在Redis里做预扣减，同时缓存科室列表、医生排班这类不常变的数据，性能提升会非常明显。但Redis不是必须的，如果学校实验室环境不支持，或者你不想额外引入运维负担，完全可以只用MySQL + 事务锁来实现。我在第四小节会对比这两种方案，你看完再决定要不要上。

集成开发工具用IDEA，数据库管理用Navicat或DataGrip，项目构建用Maven，版本管理用Git。这些都是通用配置，不需要复杂额外说明。

4. 数据库设计：预约系统的地基怎么打才不返工

4.1 核心数据表全景图

数据表的设计决定了这个系统能做多深，很多同学会在这一块掉链子，原因就一个：表结构设计没有考虑业务状态变化。下面这张表清单是我认为一套医疗预约系统至少该有的数据模型，你可以对照着做数据库设计：

用户表要不要和患者、医生拆开，这是我们踩过坑后得出的结论。简单方案是只用一张用户表加一个字段区分角色，但医生、患者属性差异很大，比如医生有职称和专业方向，患者有紧急联系人和医保号，混在一张表里会有一堆NULL字段，查询也麻烦。建议把公共登录信息放在t_user，把不同角色的私有信息分别抽到t_patient和t_doctor中，这样逻辑清晰，扩展也容易。

4.2 排班和号源模型的精细设计

排班表和挂号单表是整个数据库设计的核心，需要花最长时间打磨这两张表。

t_schedule表里要有这些字段：

private Long id; private Long doctorId; private LocalDate scheduleDate; private String startTime; private String endTime; private Integer totalSlots; private Integer remainSlots; private Integer scheduleType; private Integer status;

total_slots和remain_slots这两个字段就是“智能预约”的物理基础。医生提交排班时系统自动生成号源池，比如2025年6月1日上午8:00到12:00排了班，则total_slots设为40，remain_slots初始也为40。患者发起预约时先检查remain_slots，大于0就继续，预约成功事务里扣减1，取消则回补1。这个逻辑要放在同一个数据库事务里执行，保证不会出现两个患者同时挂到最后一个号源的情况。

挂号单表的设计更要细致：

private Long id; private Long patientId; private Long scheduleId; private String orderNo; private BigDecimal regFee; private Integer status; private LocalDateTime createTime; private LocalDateTime regTime; private LocalDateTime cancelTime;

status字段用数字枚举来控制状态流转，建议取值：0-待支付，1-已支付待就诊，2-已完成，3-已取消，4-已退号，5-爽约。这里有一个非常容易出错的地方：患者取消挂号动作和号源回补动作必须绑在同一事务里，否则会出现号源被扣掉但患者已经取消的脏数据。

有了这个状态机，后面所有模块的查询和统计才有依据。比如统计某个医生一个月的出诊量，只需要执行“count from t_registration where doctor_id = X and status in (2, 5)”，就能得到准确数据。

4.3 索引设计与查询效率

预约系统的高频查询有哪几个？患者查看医生排班（按科室+日期）、患者查看历史挂号记录（按用户ID）、管理员统计医生工作量（时间范围+医生ID）、医生查看某天预约患者名单（医生ID+日期）。这些查询条件在设计索引的时候要提前想到位：

ALTER TABLE t_schedule ADD INDEX idx_doctor_date (doctor_id, schedule_date); ALTER TABLE t_registration ADD INDEX idx_patient (patient_id); ALTER TABLE t_registration ADD INDEX idx_doctor_date (schedule_id, reg_time); ALTER TABLE t_payment ADD INDEX idx_order (registration_id);

有一点要特别提醒：索引不是越多越好。比如挂号单表，patient_id这个索引能覆盖大多数患者侧查询，不要再对所有字段组合建索引，否则插入数据时维护索引压力会很大，反而拖慢性能。表数据量在这个项目的量级下，用对上面那几条核心索引就够了。

5. 核心业务逻辑与代码实现：预约号源锁定是重中之重

5.1 环境准备与工程骨架搭建

先用Spring Initializr或IDEA内置工具创建工程，依赖选择：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

如果走前后端分离路线，再加spring-boot-starter-validation用于参数校验、JWT工具包来签发令牌。模板引擎用Thymeleaf的话，页面和后台代码放在同一个工程里就行，部署更方便。

项目的基本目录结构按职责分包：

com.example.medical ├── controller // 接口控制层，接收前端请求 ├── service // 业务逻辑层，核心事务都在这里 ├── mapper // 数据访问层，MyBatis的Mapper接口 ├── entity // 实体类，对应每张数据表 ├── dto // 数据传输对象，接收前端入参 ├── vo // 视图对象，返回给前端的数据 ├── config // 配置类，包括安全配置和拦截器配置 ├── common // 通用工具类和统一结果返回封装 └── exception // 自定义异常与全局异常处理

这个结构不是死的，但分层一定要有。别把所有代码都堆在Controller里，否则答辩时导师提问“Service层和Controller层的职责如何划分”，你会回答不上来。

5.2 排班生成逻辑

排班功能是预约系统的源头，没有排班就没有号源。医生模块的核心是一个排班生成Service：

@Service public class ScheduleService { @Transactional(rollbackFor = Exception.class) public ScheduleVO createSchedule(ScheduleDTO dto) { Schedule schedule = new Schedule(); schedule.setDoctorId(dto.getDoctorId()); schedule.setScheduleDate(dto.getScheduleDate()); schedule.setStartTime(dto.getStartTime()); schedule.setEndTime(dto.getEndTime()); schedule.setTotalSlots(dto.getTotalSlots()); schedule.setRemainSlots(dto.getTotalSlots()); schedule.setStatus(1); schedule.setCreateTime(LocalDateTime.now()); // 校验医生在同一天同一时段是否有冲突排班 Integer count = scheduleMapper.selectOverlapCount( dto.getDoctorId(), dto.getScheduleDate(), dto.getStartTime(), dto.getEndTime()); if (count > 0) { throw new BizException("该时段已有排班，请勿重复排班"); } scheduleMapper.insert(schedule); return scheduleToVO(schedule); } }

这里最容易被忽略的问题是：排班审核状态。医生提交的排班默认是待审核状态，管理员审核通过之后才对外展示，这样做的好处是防止医生随意排班放号，保证号源池的准确性。在排班查询接口里，患者端只能看到status为已通过的排班。

5.3 号源锁定的并发方案

挂号是并发最集中的操作。两个患者同时抢最后一个号源，如果没有并发控制，就会导致超卖——这是整个系统最该提前防守的点。

第一个方案是数据库乐观锁。在t_schedule表增加version字段，更新时带上版本条件：

@Transactional(rollbackFor = Exception.class) public Registration createOrder(RegisterDTO dto) { Schedule schedule = scheduleMapper.selectById(dto.getScheduleId()); if (schedule.getRemainSlots() <= 0) { throw new BizException("号源已满，预约失败"); } int updateCount = scheduleMapper.deductSlot( schedule.getId(), schedule.getRemainSlots(), schedule.getVersion()); // 如果影响行数为0，说明有其他线程也抢到了同一排班，重试或失败 if (updateCount == 0) { throw new BizException("预约人数过多，请稍后重试"); } Registration registration = new Registration(); registration.setPatientId(dto.getPatientId()); registration.setScheduleId(dto.getScheduleId()); registration.setOrderNo(generateOrderNo()); registration.setRegFee(schedule.getRegFee()); registration.setStatus(0); registration.setCreateTime(LocalDateTime.now()); registrationMapper.insert(registration); return registration; }

deductSlot对应的Mapper方法：

UPDATE t_schedule SET remain_slots = remain_slots - 1, version = version + 1 WHERE id = #{id} AND version = #{oldVersion} AND remain_slots > 0

第二个方案是Redis预扣减。号源余量放进Redis缓存，预约开始时先用原子操作DECR预扣，扣到负数说明号源已空，拒绝请求。支付成功后把订单信息异步写入数据库。这个方案的高明之处在于把扣减操作放在内存里，并发能力远超数据库更新，但引入的技术复杂度也高了，需要处理缓存和数据库的一致性问题。

我建议基础方案用乐观锁就够了，能说明白并发控制的思想，也足够应付答辩。如果项目想冲击优秀，可以在文档里把Redis方案作为扩展写在对比分析里，展示你思考过并发演进路径，这是加分项。

5.4 订单状态流转与超时处理

订单从创建到完成要经过完整的状态流转。患者下了单但一直不支付，占用号源不释放，会影响其他患者预约。此时需要一个超时处理机制。常规做法是：订单创建30分钟内未支付，状态自动变为已取消，号源回补。

实现上分三个层次：

第一层，在查询时做逻辑判断，查订单时如果发现是待支付且创建时间超过30分钟，先更新状态为已取消再返回。这个方案适合数据量小的场景。

第二层，项目启动时启动一个定时任务，每隔几分钟扫描待支付订单，批量处理超时订单并回补号源。用Spring的@Scheduled注解就能实现：

@Scheduled(cron = "0 */5 * * * ?") public void handleTimeoutOrders() { List<Registration> timeoutOrders = registrationMapper.selectTimeoutOrders( LocalDateTime.now().minusMinutes(30), 0); for (Registration order : timeoutOrders) { cancelOrderInternal(order.getId(), "订单超时未支付，自动取消"); } }

第三层，如果是大型商用系统会用消息队列延迟消息来处理，但毕业设计做到前两层就完全足够了。在答辩环节，能解释清楚定时任务的触发逻辑和如何保证不重复处理，是非常加分的点。

5.5 防重复提交与幂等设计

一个常见场景：患者手速快点了两次提交按钮，结果生成两笔订单。防重复提交可以从三个层面来防：

前端层面，点击提交后立即置灰按钮，并加防抖逻辑。后端层面，利用数据库唯一约束，在t_registration表设计一个联合唯一索引，把patient_id和schedule_id外加一个当天日期构成唯一键。更稳妥的方案是客户端生成一个幂等键，携带在请求头里，后端把这个键做唯一校验。

if (registrationMapper.selectByToken(dto.getRequestId()) != null) { throw new BizException("请勿重复提交"); }

这个requestId在订单创建时与订单记录绑定，存一个独立的token字段，这样同一个请求重复提交时就会被拦截。

6. 权限体系与登录安全：三种角色一套系统怎么管理

6.1 JWT登录态与Spring Security整合

系统有三种角色，每种角色能访问的接口不同，这就要做权限控制。推荐用Spring Security + JWT的方案，无状态认证，非常适合前后端分离模式。

配置链结构如下：

@Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers("/api/user/login", "/api/user/register", "/api/dept/list").permitAll() .antMatchers("/api/doctor/**").hasRole("DOCTOR") .antMatchers("/api/admin/**").hasRole("ADMIN") .antMatchers("/api/patient/**").hasAnyRole("PATIENT", "DOCTOR", "ADMIN") .anyRequest().authenticated() .and() .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class); }

JWT过滤器做的就是解析请求头中的令牌，校验签名，然后将用户信息和角色放入SecurityContext。用户登录成功后签发两个令牌：accessToken有效期为2小时，用于日常接口访问；refreshToken有效期为7天，用于续期。

密码存储一定要用BCrypt加密，不要用明文或者MD5。Spring Security内置了BCryptPasswordEncoder，调用encode方法存库，matches方法校验，这是行业标准做法。在方案文档里把这个写清楚，答辩时可以讲明白为什么不能用MD5——因为彩虹表攻击可以轻松逆向常见密码。

6.2 权限越权防护的细节

权限控制不要只依赖接口路径的拦截，数据级别的越权问题一定要在业务逻辑中做二次校验。比如患者只能查看自己的挂号记录，医生只能查看自己排班下的患者列表，管理员可以查看所有数据。代码中要明确写清楚这条约束：

public List<RegistrationVO> patientHistory(Long currentUserId, Long patientId) { // 校验访问者是否就是该患者本人 if (!currentUserId.equals(patientId)) { throw new ForbiddenException("无权查看他人就诊记录"); } return registrationMapper.selectByPatient(patientId); }

这一层校验很容易被忽略，但恰恰是工程化思维和对安全的理解程度的体现。做项目时可以提前在方案里罗列敏感接口，逐个检查是否做好了垂直权限控制。

6.3 操作日志与审计

并行的记录是很重要的加分项。每次预约、取消、改诊、停诊操作，都记录一条操作日志，包含操作人、操作类型、操作时间、操作对象、结果。用一张t_operation_log表保存。好处是答辩时，你可以现场演示“查某位患者一个月的全部操作轨迹”，这样既展示了数据设计能力，也展示了业务追溯能力。

7. 医患交互与功能扩展规划

7.1 在线问诊模块的设计思路

谨慎处理“在线问诊”和“开处方”你未必真的需要完整实现的边界。合规的重点是：在线问诊模块的核心价值，至少应该覆盖“预约后到就诊前”这段等待期的沟通需求。患者在线提交挂号单后，可以给医生留言描述病情现状；医生在出诊前查看患者留言，提前掌握情况；同步支持医生发起随访提醒。

这个模块用一张t_consultation表加会话字段就可以实现，扩展聊天窗口时再用WebSocket推送消息。

7.2 就诊评价与反馈闭环

诊疗结束后，患者可以给医生打分和写评价。评价模块的价值不仅在于功能本身，更在于完成“预约—就诊—评价”的业务闭环。评价表里给一个匿名标识字段，患者可以选择匿名评价，避免心理负担。医生端可以看到评价但不能看到评价人是谁。管理员端看到汇总评分和差异化的评价分析，这些数据可以用于方案中的数据分析模块。

7.3 消息通知机制

通知模块有两种实现路线。轻量级的是站内信，在t_notification表存一条记录，患者登录后在消息列表看到。重量级的是短信和邮件推送，需要在平台注册模板，配置成本较高。毕业设计建议做站内信就可以，如果项目要求高一点，可以在通知模块预留短信接口的抽象层，写一个短信Sender接口和对应的模拟实现类，在文档中写明生产环境如何替换为真实服务。这样既保留了扩展余地，不会因为接入真实短信通道而卡在资质审核上。

8. 常见问题与排坑实录

8.1 号源超卖事故复盘

我在一个模拟项目X里真实遇到过一次：患者同时抢同一个医生最后一个号源，两个请求都通过，都创建了订单。查下来的原因是没有控制好事务边界，创建订单前查询了剩余号源，然后做了一段耗时的逻辑处理，再执行扣减，导致出问题的窗口期拉得特别长。后来我在项目里实测对比加不加乐观锁的表现，发现同一时刻高并发请求下，加了乐观锁后异常率就控制住了。实际结果是最直观的说服力，建议你写方案时也用实验数据说明这个对比。

8.2 事务不生效的典型场景

Spring的@Transactional默认只在RuntimeException时回滚。如果你在Service方法里catch了异常但没有手动抛出，事务不会自动回滚。这样一个场景会产生大问题：扣减号源成功、更新订单失败、程序吞掉异常，数据库里出现订单缺失但号源已经减少的情况。解决方法是自定义业务异常继承RuntimeException，在catch块里抛出，或者直接在Service方法里把事务边界分清楚，不要跨方法做复杂操作。

8.3 日期时间的时区坑

Date类型存储LocalDateTime有可能会被序列化出奇怪的格式。建议在application.yml里显式配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

排班逻辑中比较日期时，尽量用LocalDate和LocalDateTime，不要用java.util.Date，能避免大量时间比较的错误。这是Java 8日期时间API的价值——类型安全，语义明确，没有时区歧义。

8.4 前端页面展示的常见坑

Thymeleaf模板引擎页面里，时间格式化用#temporals或#dates。如果直接输出LocalDateTime对象，会出现一串英文格式还带T。我建议在Controller层统一用VO对象转换，前端只接收格式化好的字符串，这样模板引擎的工作量会小很多。

8.5 稳定环境的必查清单

一个完整的可运行项目，建议按这个清单做验收：

• 数据库初始化脚本能否一键执行，是否存在外键关联导致插入顺序错误的问题
• 项目是否能直接用Maven打Jar包并且启动无报错
• 三种角色是否能正常登录且访问权限正确
• 预约流程能否完整走通：查询、下单、支付、就诊、评价
• 取消预约后号源是否回补
• 并发场景下能否正确处理超卖
• 数据统计是否准确，尤其在跨月和月底这些边界时间

8.6 答辩演示的角度

演示系统前，准备好两个关键测试账号：医生账号里准备几条不同状态的排班，患者账号里准备几张不同状态的挂号单。拿一个正在就诊状态的订单尝试取消，让系统提示状态不允许取消——这种现场演示比花哨的功能更能证明系统考虑到了边界条件。

9. 结尾：做到什么程度才算真正做完

如果让我给这个项目定一个“完成”的标准，不是所有功能都写完，也不是答辩PPT做完，而是一句话能讲清“这个系统如何保证两个患者不会同时挂到同一个号源”。能回答清楚这个问题，说明你真的理解了事务、并发和数据一致性的关系，也说明你真正消化了这个课题的核心。

这个题目最值钱的地方并不在“会不会写Spring Boot代码”，而在于你有没有把“预约”两个字背后的业务矛盾想明白。毕业答辩里导师也会顺着这个方向去追问，把余量扣减、防重复提交、订单状态机、权限越权这些问题都用真实场景做扎实，你对这套线上预约系统的理解就已经超出大多数同届同学了。

如果还有余力，在基础功能稳定之后，可以做一个小扩展方向：把排班策略从手工配置改成自动推荐算法，依据医生历史接诊量和患者预约高峰时段来生成建议排班。再加一个投屏式数据大屏模块，把今日预约量、科室热度、医生负荷度做成可视化图表，整个项目的完整度和冲击力会再上一个台阶。先守住主流程，再谈扩展，顺序不要乱。