企业官网建设流程全解析

Spring Boot医疗服务平台毕设怎么做？从选题到答辩的全流程拆解

每年毕业季一到，计算机专业的学生群里总会冒出同一个问题："后端用Spring Boot做个什么题目好？"说实话，医疗服务平台这个选题我做了不少次，帮学弟学妹们改过代码，也听他们吐槽过答辩老师问的各种刁钻问题。这个题目确实经典——业务场景清晰、模块边界好划分、演示效果好，而且Spring Boot这套技术栈本身就是目前Java后端的绝对主流，做完这个项目，找实习写简历的时候也能直接拿出来讲。

我先把话撂在这儿：医疗服务平台这个毕设，核心不是把代码跑起来，而是让评委看到你对"用户、医生、管理员"这三类角色的业务理解，以及你在权限控制、预约状态流转、病历和处方管理这些关键点上的设计思路。这篇博文我就按自己做项目的完整过程来拆，从选题定位、技术选型，到数据库设计、后端接口实现，再到答辩准备和常见坑位，一步不落。

1. 项目整体设计与思路拆解

1.1 医疗平台的核心需求定位

拿这个题目做毕设，第一件事就是想清楚"我这个平台到底解决什么问题"。线下就医的痛点大家都清楚：挂号要排队、就诊记录散落在不同科室、医生开完处方患者还要跑上跑下缴费拿药。医疗服务平台要解决的，就是把这一条链路的线上化。

所以平台至少要覆盖三个角色，三条业务线。患者端能注册登录、查科室和医生、预约挂号、看自己的病历和检查报告；医生端能看自己的排班和患者列表、写病历、开处方；管理端则负责维护科室、医生、药品的基础数据，以及处理号源排班。

业务闭环说白了就是：患者线上挂号 → 医生按排班接诊 → 问诊后写病历开处方 → 患者查看处方和检查结果。把这条主链路做通，再围绕它补充注册、登录、支付记录、统计这些小功能，整个项目的骨架就立住了。

我在带人做这类项目时反复强调一个原则：不要一开始就想着加"在线支付""消息推送""视频问诊"这些花活。毕设考察的是你能不能把一个完整业务用代码实现出来，优先保证主流程扎实，再考虑扩展功能。花哨功能做得半吊子，答辩时反而容易露怯。

1.2 为什么选Spring Boot做毕设

最近几年Spring Boot取代传统SSM成为毕业设计主流，原因很直接。Spring Boot把Spring生态里那一大堆繁琐的XML配置干掉了，通过自动配置和Starter机制，引入一个依赖就相当于帮你把这一组库都装好配好。举个例子，你想用MySQL，引入spring-boot-starter-data-jpa或者mybatis-spring-boot-starter，再加上数据源配置，连接就能用，不用再像SSM时期那样写一堆applicationContext.xml。

对内嵌Tomcat的支持也非常舒服，本地开发一个java -jar命令就能起服务，不像以前还要单独装Tomcat再部署war包。这一点对毕设项目的演示场景特别友好——答辩现场不可能让你慢慢配环境，能快速启动、快速演示才是王道。

从就业角度看，Spring Boot已经是Java后端的绝对主流，微服务、云原生这些进阶方向全都建立在Spring Boot基础之上。做完这个毕设，你对自动装配、依赖注入、AOP、Spring MVC的工作流程会有真实体感，面试聊项目经历时也有干货可讲。

1.3 技术选型背后的取舍

我见过太多人在选型上纠结半天，其实技术选型的核心原则就一条：选你自己最熟或者最容易查资料搞定的组合。我的惯用搭配如下：

• 后端框架：Spring Boot 2.7.x。为什么不追最新的Spring Boot 3.x？因为3.x要求JDK 17，并且不少第三方starter的兼容性还没跟上。做毕设求稳，2.7版本资料最丰富，网上报错解决方案一搜一大把。
• ORM框架：MyBatis Plus。相比原生MyBatis，Plus提供了开箱即用的CRUD方法，分页插件也成熟，能省掉大量重复的SQL和Mapper XML。如果你对MyBatis原生写法很熟，用原生也没问题，但Plus的效率优势在毕设这种赶工场景下非常明显。
• 权限认证：Spring Security + JWT。Spring Security体系完整，JWT免去了Session共享和跨域处理Session的麻烦，前后端分离场景下最顺手。
• 前端：Vue 2 + Element UI。Vue 3对新手并不友好多少，反而Element UI的文档和案例多如牛毛，抄样式、调组件都快。
• 数据库：MySQL 8.0。行业事实标准，Navicat连上就操作，毕业设计必备。

不推荐在毕设里做的几个选择：分布式锁、消息队列、微服务注册中心——除非你的课题就是研究这些，否则引入它们只会让系统复杂度失控，答辩也讲不清楚。

2. 核心功能模块与数据库设计

2.1 功能模块怎么划分才清晰

模块划分影响的不只是代码结构，还直接影响你答辩讲解时的逻辑。我的建议是前端按角色拆页面，后端按业务域拆模块，前后端呼应。

患者端功能清单：注册登录、首页科室展示、医生列表按科室筛选、预约挂号、我的挂号记录、病历详情查看、检查报告列表与详情、个人资料维护。

医生端功能清单：今日接诊列表、患者历史病历查询、新建病历（主诉、诊断、处理意见）、处方开单（支持从药品库选择药品）、查看自己名下的患者记录。

管理端功能清单：用户管理（医生账号启停、患者账号维护）、科室管理、医生排班管理（设置每周坐诊时间并分配号源）、药品管理（药品CRUD和库存维护）、数据概览（注册人数、当日挂号量等统计）。

模块清晰的好处是分工明确，你自己写代码时可以一部分一部分完成，每完成一个模块就能跑通一部分流程，心态上也稳很多。

2.2 数据库表设计思路

数据库表设计是答辩时的高频考点，评委一般都爱问"你这几个表是什么关系、为什么这么设计"。我设计的核心表如下：

• sys_user：用户主表，包含角色字段（1患者、2医生、3管理员），也放账号密码、姓名、手机号。
• department：科室表，字段有科室名称、简介、位置。
• doctor：医生表，关联sys_user（一对一）和department（多对一），额外放职称、擅长方向、简介。
• schedule：排班表，关联doctor，记录日期、时段（上午/下午）、总号源数、剩余号数。
• registration：挂号记录表，关联patient（即sys_user）、schedule，记录挂号时间、状态（待就诊/已完成/已取消）、就诊时间。
• medical_record：病历表，关联registration和doctor，记录主诉、现病史、诊断结果、处理意见。
• prescription：处方表，关联medical_record，一条病历可能对应一个处方单。
• prescription_item：处方明细表，关联prescription和drug，记录药品名、数量、用法用量。
• drug：药品表，记录药品名称、规格、库存、价格。
• check_report：检查报告表，关联registration，记录报告标题、检查内容、检查结果、报告时间。

几个容易踩坑的设计点我单独提一下。第一，不要在sys_user里塞太多角色专属字段，比如医生的职称放sys_user里就很别扭，单独拆doctor表才是规范做法。第二，状态字段一定用int或varchar存枚举值，别用中文直接存，后面前端枚举映射和条件查询都好处理。第三，外键在开发阶段可以建立物理外键，但上线前建议去掉，只保留逻辑外键，避免高并发写入时外键检查的性能损耗——这个点你在答辩时主动提出来，评委反而会觉得你想过生产问题。

2.3 关键业务逻辑设计的坑

挂号流程的状态流转是整个系统的灵魂。schedule表里剩余号数要实时递减，但高并发下直接UPDATE剩余号数会出现超卖问题。毕设阶段不追求极致的分布式锁方案，但用数据库乐观锁实现是加分项：在schedule表加version字段，更新时带上version做条件判断，更新行数为0就提示"号源已被抢完"。

权限隔离也要注意。患者只能查自己的挂号、病历、报告，接口层面必须强制带当前登录用户ID做条件过滤，不能写死"传什么查什么"。医生只能看接诊范围内患者的信息，管理员不参与具体业务数据的读写。这些规则用Spring Security的权限注解加Service层判断双重控制，别只依赖前端按钮隐藏。

3. 实操过程与关键环节实现

3.1 项目搭建与目录结构

创建项目推荐直接用Spring Initializr（IDEA自带或者网站生成都行），勾选Web、Security、MySQL Driver、MyBatis Plus（手动添加依赖就行，Initializr上不一定有）。依赖版本建议锁定，我常用的核心依赖如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </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-security</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> </dependencies>

目录结构严格分层，controller层只做参数接收和结果封装，service层写业务逻辑，mapper层负责数据访问，entity层对应数据库表字段。然后加common包放统一响应类、异常处理、工具类，config包放Security配置、MyBatis Plus配置。

统一响应类我写的是Result ，包含了code、message、data三个字段。这个类虽简单，但整个项目所有接口统一返回格式，前端联调时省事太多。

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.code = 500; result.message = message; return result; } }

3.2 用户认证与权限控制

认证这块直接上Spring Security + JWT，流程图不画了，文字讲清链路。用户提交账号密码到登录接口，Service层校验通过后用JWT生成令牌返回前端。前端每次请求在Header里带Authorization: Bearer token，后端的OncePerRequestFilter从Header取令牌、解析出用户ID和角色，放入SecurityContext。

JWT工具类负责生成和解析，我习惯把过期时间设为7天。密钥写死在配置文件中还是环境变量都行，毕设无所谓，但答辩时可以提一句"生产环境会放到配置中心或密钥管理服务"。这里贴一个生成Token的核心逻辑：

public String generateToken(Long userId, Integer role) { Date now = new Date(); Date expireDate = new Date(now.getTime() + EXPIRATION_TIME); return Jwts.builder() .setSubject(userId.toString()) .claim("role", role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS512, SECRET_KEY) .compact(); }

SecurityConfig里需要注意几个细节。放行路径要包括登录接口、注册接口，以及前端的静态资源路径；其余接口要认证后才能访问。还有几个必备组件：密码加密用BCryptPasswordEncoder，不允许明文存储密码；无权限访问时统一返回JSON格式的提示，不要返回Spring Security默认的403页面。

3.3 核心接口实现示例

挂号接口的完整逻辑要包含三步：校验排班是否存在和剩余号数是否大于0、扣减剩余号数并创建挂号记录、返回挂号成功信息和待就诊状态。代码如下：

@PostMapping("/register") public Result<String> register(@RequestBody RegisterRequest request, @AuthenticationPrincipal UserDetails userDetails) { Long patientId = getCurrentUserId(userDetails); Schedule schedule = scheduleService.getById(request.getScheduleId()); if (schedule == null) { return Result.error("排班不存在"); } if (schedule.getRemaining() <= 0) { return Result.error("该时段号源已约满"); } boolean success = scheduleService.decreaseRemaining( schedule.getId(), schedule.getVersion()); if (!success) { return Result.error("号源已被抢完，请刷新查看其他时段"); } Registration registration = new Registration(); registration.setPatientId(patientId); registration.setScheduleId(schedule.getId()); registration.setStatus(0); // 待就诊 registration.setCreateTime(LocalDateTime.now()); registrationService.save(registration); return Result.success("预约成功"); }

医生开处方的接口要注意事务。一次开处方操作涉及病历表、处方表、处方明细表，三张表要么都成功要么都失败，所以Service方法上必须加@Transactional注解，这一点在答辩时我会主动讲，评委很吃这一套。

查询报告接口则要强调数据归属校验：先拿到挂号记录，判断当前登录用户是否是这条挂号记录对应的患者，不是就直接抛异常，不给查。

3.4 前端页面与接口联调

前端我用Vue 2 + Element UI搭管理后台风格的单页应用。路由用vue-router，菜单按角色动态生成：患者登录只显示患者相关菜单，医生登录只显示接诊相关菜单。登录态存localStorage，Axios请求拦截器里统一追加Authorization头，响应拦截器里统一处理401跳转登录页。

联调阶段最烦的是跨域问题。开发环境下前端口是8080，后端口是9090（我在application.yml里把server.port配成了9090避免和前端冲突），跨域用后端CorsFilter统一解决。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

这里有个容易踩的坑：Spring Security和CorsFilter的执行顺序问题。如果自己定义了CorsFilter，必须在SecurityConfig里用http.cors().and()启用它，否则安全过滤链会先拦截跨域预检请求，导致前端疯狂报CORS错误。这个问题我帮人排查过不下五次，每次最后都是这里没配。

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

4.1 页面白屏、首屏加载慢

先检查浏览器控制台是否报JS错误，重点排查路由配置component路径写错、Element UI按需引入是否完整、接口跨域是否报错。首屏慢的优化点：路由懒加载，即component写成() => import('@/views/xxx.vue')，能把首屏JS包拆小一大截。

4.2 数据库连不上、Navicat报错

最常见原因是MySQL 8.0的加密方式和旧驱动不兼容。解决方式就是把驱动换成上述配置里的mysql-connector-java 8.0.33，并确认url里带useSSL=false和serverTimezone=Asia/Shanghai。还有很多人会忘记在application.yml里写时区参数，导致时间字段偏8小时，排查时先看这两个配置。

4.3 Spring Security登录放行后仍然被拦截

确认SecurityConfig里放行规则是不是写在authorizeRequests之前。另外用antMatchers匹配时，路径要从根开始写全，比如/api/auth/login，不要只写一个/login。还有一个隐蔽问题：JWT过滤器必须继承OncePerRequestFilter而不是普通Filter，否则在转发请求时会被执行多次，导致重复认证。

4.4 MyBatis Plus分页查询无效

分页插件必须配置到config里，不配置的话调用selectPage时只返回了全部数据，然后分页全是本地内存分页。绕开这个坑的代码很简单：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

4.5 时间字段返回格式不对

LocalDateTime默认序列化出来是一串数组，前端根本没法用。在application.yml里全局配置：

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

这一行就够，不用每个字段加注解。

4.6 答辩前必做的自测清单

再来一份答辩前的自测清单，全部跑通了再上台：用患者账号走一遍挂号到查看病历的完整流程；用医生账号开一个处方，再去患者端确认能查到；用管理员账号新建一个科室和医生并排班，再去患者端尝试挂这个医生的号；退出登录后直接访问需要认证的接口，确认返回未授权JSON而不是跳转页面；销毁本地数据库再重新执行初始化SQL，确认能一键拉起所有表数据和默认账号。

我废话不多说，这六项自测全部通过，答辩基本稳了。

5. 答辩讲解与演示准备

5.1 演示时先跑主流程再跑亮点

答辩的演示顺序很重要，我的习惯是"登录页 → 患者端预约挂号 → 医生端接诊开处方 → 患者端查看病历报告"，先让评委看到完整业务闭环。跑完主流程后，再演示一两个亮点功能，比如排班号源控制、JWT过期重新登录、管理员数据统计面板。

中途演示如果出Bug，不要慌，也不要当场改代码。你可以说"这个问题在我本地环境是有验证过的，可能现场环境的影响，我们跳过这步看下一个功能"。提前把核心演示步骤的数据准备好非常关键，比如提前建好几个患者的挂号记录，不要在答辩现场现注册现挂号。

5.2 答辩常见问题的准备思路

评委必问的三类问题，提前准备好答案。第一类是"你这个系统的核心表有哪些、关系是什么"，把2.2节里的表结构说出来就行。第二类是"权限是怎么控制的"，从JWT携带角色到Security注解鉴权，一口气讲下来。第三类是"系统的难点和你认为的亮点是什么"，难点推荐说并发挂号下的防超卖和权限隔离，亮点说你的统一异常处理、乐观锁、代码分层规范。

如果评委问到一个你完全不会的点，诚实说"这块我目前还了解不深，但后续我想往这个方向深入"，好过硬着头皮编。我在答辩现场见过不少因为硬答被追问到崩溃的案例，诚实反而能保住印象分。

5.3 源码整理与文档规范

源码这块的重要性一点不亚于运行效果。包路径不要留无用的测试代码，注释不要出现网上下载的痕迹，README里把项目简介、技术栈、运行步骤、默认账号写清楚。数据库脚本单独放一个sql目录，确保用Navicat执行一遍完整脚本就能生成全部库表数据。

论文里放架构图、流程图、E-R图时，别直接用网上找的图，要么画自己的，要么基于自己的截图重绘。我用的是ProcessOn画流程图，Draw.io画E-R关系图，风格统一后插进论文很加分。

5.4 最后再分享一个小技巧

代码仓库里多建一个docs目录，把开发过程中的每周进度、遇到的问题和解决方式随手记下来。这不只是为了给导师看，答辩时被问到"你项目做了多久、遇到最大困难是什么"的时候，你随口就能说出真实细节，特别加印象分。带过的学弟用这招，被评委点名夸过"过程管理很规范"。

医疗服务平台这个题目，做得好不好，关键在你的业务链路是否通、设计是否合理、踩坑经验能否讲清楚。这套东西做完，Spring Boot的绝大多数核心用法你也都亲手过了一遍。剩下的路，就看你拿着这个项目能走到哪一步了。