SpringBoot医疗管理系统毕设：核心代码与踩坑全解析

我用 SpringBoot 把医疗管理系统卷成了毕设模板，核心代码和踩坑都在这里

每年到了毕业季，总有一批人卡在选题上：既要难度适中能独立完成，又不能太水让答辩老师一眼看穿，还得有实际业务场景可以讲故事。我的建议是，医疗管理系统这个方向至今依然能打——不是因为它多拔尖，而是它天然包含挂号、门诊、收费、药品、病床、统计报表一整套真实业务闭环，做出来就是一个完整的 Web 工程，而不是几个 CRUD 页面拼凑的玩具。

这篇文章就是拿我最近梳理的一套 Java + SpringBoot 医疗管理系统作为主线，把从需求拆解到环境部署的完整链路讲透。你不一定非要照抄这个项目，但里面的设计思路、表结构、权限方案、代码组织方式和部署细节，都是能直接迁移到同类管理系统上的。

1. 先把需求拆清楚：毕设系统不是功能越多越好

1.1 核心需求解析：医疗管理系统的业务边界

很多人一听到“医疗管理系统”就觉得要做成 HIS（Hospital Information System）。醒醒，那是几千张表、几十个微服务的工程，一个人半年都未必能啃完。毕业设计要的是业务闭环完整、技术亮点清晰、工作量适中，所以需求边界必须自己划。

我建议按“患者在医院走一圈”这个逻辑来圈功能：患者来医院先挂号，挂完号到科室就诊，医生开处方后患者去药房取药，药房扣库存，收费处结账，最后住院的患者办理入出院并占床。围绕这条主线路，再加上系统管理、医生排班、数据统计，就是一套五脏俱全的医疗管理系统。

具体来说，核心模块可以拆成这样：

• 系统管理：用户、角色、菜单、权限分配
• 门诊管理：挂号、医生排班、接诊记录
• 医生工作站：病历录入、处方开具、诊断结论
• 药品管理：药品档案、库存出入库、效期预警
• 收费管理：门诊收费、住院预交金、退费处理
• 住院管理：入院登记、床位分配、出院结算
• 统计报表：门诊量、收入、药品消耗排行

注意，我特意没有把“排队叫号”“电子病历共享”“医保对接”这些放进去。原因很简单：功能越多，表越多，代码越庞杂，出错面就越大。毕设答辩的黄金标准是“深度够、逻辑严谨、技术有亮点”，而不是“功能列表比论文还长”。

1.2 角色与权限：三条命脉不能乱

医疗系统的核心不是界面多炫，而是权限清晰。这个系统里我认为必须保留三个角色：管理员、医生、收费员，如果时间充裕可以再加一个药房管理员。

• 管理员：管用户、管角色、管菜单，能看所有数据，但不能开处方
• 医生：只能看自己的患者，能写病历和处方，不能改价格
• 收费员：只能操作收费和退费，看不到诊断细节

权限模型的实现我推荐用 RBAC（基于角色的访问控制），用户表、角色表、菜单/权限表、用户角色关联表、角色菜单关联表这五张表打底。Spring Security 或者自定义拦截器做接口级权限校验，前端用 Vue 的路由守卫控制菜单显示，做到“后端不信任前端”就行。

我之前见过很多毕设项目把权限写死在代码里，比如if("admin".equals(username))，这种设计答辩时基本会被问死。RBAC 的扩展性是实打实的东西，往厂里一坐也照样适用。

1.3 划清主次：先做主流程，再补枝枝叶叶

我的实操建议是，第一版只做两条主流程：门诊就诊流程和药品出入库流程。把这两条跑通了，剩下的都是增删改查。很多人一上来就想做报表和图表，结果核心业务还没跑通，最后愁的就是前后端联调时间不够。

所以做需求的阶段，一定要用“角色在什么场景下做什么事”的叙事方式去定义每个功能。比如“医生登陆系统后在待诊列表里看到患者的挂号码，点击进入接诊页面，填写主诉、诊断、用药，提交后自动生成处方单”——这样写出来的需求，后端接口怎么设计、前端页面怎么组织、数据库字段怎么落，都会非常清晰。

2. 技术选型：SpringBoot 究竟该用哪个版本

2.1 版本选择背后的逻辑：SpringBoot 2.7.x 与 3.x 的取舍

先说个特别实际的建议：毕设项目优先选择 SpringBoot 2.7.x，而不是 3.x。

原因很简单。SpringBoot 3.0 从 2022 年底发布，它的 Jakarta EE 9 命名空间变化导致很多传统教程的代码直接报错，比如javax.servlet要换成jakarta.servlet，SpringFox 的 Swagger 2 适配也有坑。更关键的是，很多国内企业在生产环境里其实还在用 SpringBoot 2.x，你写 2.7.x 不会被面试官挑刺，反而显得懂版本选型。

如果是为了毕业设计图省心，直接就是：

• JDK 1.8 或 JDK 8（别上 JDK 17，除非你确定要用 SpringBoot 3.x）
• Maven 3.6+
• SpringBoot 2.7.x（比 2.6.x 稳定，比 3.x 教程多）
• MyBatis-Plus 3.5.x（不要用纯 MyBatis，毕设时间耗不起手写 XML）
• MySQL 5.7 或 8.0
• Vue 3 + Element Plus（前端框架）
• Redis 可选（做验证码缓存和 Token 存储，算加分项）

2.2 为什么是 MyBatis-Plus 而不是 JPA

这个问题答辩老师大概率会问。我的回答逻辑是：

JPA 的强项是让你几乎不写 SQL，全用对象导航。但医疗系统里有很多多表关联查询和统计报表，比如“查出每个科室的本月挂号数量”，用 JPA 的 Specification 写起来绕来绕去，最后还是要写原生 SQL。MyBatis-Plus 保留了 SQL 控制权，同时提供了通用的BaseMapper，单表 CRUD 可以直接用内置方法完成，90% 的场景根本不需要自己写 SQL。

另外有一点很容易被忽略：MyBatis-Plus 可以对数据库实体类直接进行代码生成，可以根据 Java 实体的注解自动生成建表 SQL 语句，这个在文档写的阶段非常好用——你把实体类字段定义好，直接跑一个方法或者用 CodeGenerator 把表结构生成出来，不用手工去 MySQL 里敲一遍 DDL。具体在 4.2 里我会说怎么用。

2.3 前置环境准备清单

开发前的环境配置是很多人的第一道坎，我把它列成清单，照着弄就行：

• JDK 8：安装后一定要在命令行验证java -version
• Maven：配置settings.xml里的阿里云镜像，否则下载依赖能卡到你怀疑人生
• MySQL：建议 5.7 以上，创建数据库时统一utf8mb4字符集
• Node.js：Vue 前端需要 16 以上版本
• Navicat 或 DataGrip：数据库可视化工具，推荐 DataGrip，写复杂 SQL 有提示

提示：JDK 装完后记得配 JAVA_HOME 环境变量，否则 Maven 找不到 JDK。我之前见过有人 JDK 装了三遍，最后发现是 Path 里没有配。

3. 数据库设计：一张好表胜过十层代码

3.1 核心表结构：从患者到药品的完整链路

数据库是整个系统最重要的地基。表设计得好，后面代码写得顺；表设计得烂，改接口改到想哭。我直接分享一套简洁可靠的表设计，你可以直接抄：

用户与权限：

• sys_user：id、username、password（BCrypt 加密存储）、real_name、phone、status
• sys_role：id、role_code、role_name
• sys_menu：id、menu_name、parent_id、url、perms
• sys_user_role：user_id、role_id
• sys_role_menu：role_id、menu_id

患者与挂号：

• patient：id、patient_no（病历号）、name、gender、age、phone、id_card、addr
• registration：id、patient_id、doctor_id、reg_type（普通/专家）、reg_date、fee、status（待诊/已诊/已退）
• doctor_schedule：id、doctor_id、work_date、period（上午/下午）、dept_id、remaining

诊疗与处方：

• medical_record：id、registration_id、patient_id、doctor_id、chief_complaint、diagnosis、create_time
• prescription：id、medical_record_id、patient_id、total_amount、status
• prescription_item：id、prescription_id、drug_id、quantity、unit_price、subtotal

药品与库存：

• drug_info：id、drug_code、drug_name、specification、unit、manufacturer、price、stock_quantity、expire_date
• drug_stock_log：id、drug_id、change_type（入库/出库/盘点）、change_num、create_time

收费与住院：

• payment_record：id、patient_id、type（门诊/住院/药品）、amount、pay_method、status、create_time
• bed：id、dept_id、bed_no、status（空闲/占用）
• inpatient：id、patient_id、dept_id、bed_id、admit_date、discharge_date、status

这个表数量大概 15 到 20 张，对毕设来说刚刚好。核心思路就是：业务主表（registration、medical_record、prescription）做关联，字典表和类型字段用 int/varchar 表示，不在数据库里搞过度复杂的外键关系。

3.2 字段设计的原则：时间、金额、状态是做好的关键

我说几个设计陷阱，注意绕开：

金额字段全部用 decimal，不能 float。float 在 Java 里算钱会出现 0.1 + 0.2 != 0.3 的经典问题，虽然可以用 BigDecimal 弥补，但数据库层能规范就直接规范。

时间字段统一datetime，整体默认当前时间用DEFAULT CURRENT_TIMESTAMP。查询统计的时候会用GROUP BY DATE(create_time)。

状态字段不要用中文，用数字或者英文字母。比如挂号状态：0 待诊，1 已就诊，2 已退号，3 已过期。顺序写清楚，前端用枚举转换显示。

所有表加create_time和update_time两个通用字段，MyBatis-Plus 可以在插入和更新时自动填充，省很多事。

3.3 索引怎么加：别把索引神化，也别完全不用

如果数据量就几百条，加不加索引感知不强。但你写毕设的时候答辩老师可能会问“你在这张表上为什么加索引”。所以至少要在这几个字段设置索引：

• registration.patient_id、registration.doctor_id
• prescription.medical_record_id（外键查询频繁）
• drug_info.drug_code（药品编码唯一）
• payment_record.create_time（报表统计会按时间范围查）

主键统一用雪花算法生成的长整型 id，别用自增。虽然自增写起来简单，但分布式场景下会暴露业务量，为了讲出规范，建议直接用 MyBatis-Plus 的ASSIGN_ID策略。

4. 核心代码实现：从登录到报表的完整链路

4.1 后端工程结构：包路径就是你的项目说明书

工程结构是否清晰，答辩老师一眼就能看出来。我推荐的分包方式是这样：

com.hospital ├── config # 配置类（拦截器、异常处理、CORS） ├── controller # 接口层 ├── service # 业务逻辑层 ├── service.impl # 业务实现 ├── mapper # MyBatis-Plus Mapper ├── entity # 数据库实体 ├── dto # 请求/响应对象（VO 也可以） ├── common # 公共类（Result、常量、枚举） ├── utils # 工具类（JwtUtil、DateUtils） └── exception # 自定义异常

分层的好处是职责单一：Controller 只接收参数和返回结果，Service 只写业务逻辑，Mapper 只做数据访问。千万别把 SQL 写在 Controller 里，代码评审直接不过。

4.2 根据实体类自动生成建表 SQL：MyBatis-Plus 的隐藏用法

这算是一个比较实用的偷懒技巧。你在工程里定义好实体类后，可以利用 MyBatis-Plus 的DbScriptParser或者直接配置MybatisPlusProperties的dbFieldUnderline，再把实体类字段作为候选表结构，手动拼一个简单的生成 SQL 的测试类。

我举个直接的例子，实体类长这样：

@Data @TableName("drug_info") public class DrugInfo { @TableId(type = IdType.ASSIGN_ID) private Long id; private String drugCode; private String drugName; private String specification; private String unit; private BigDecimal price; private Integer stockQuantity; private LocalDate expireDate; }

然后在测试类里写一个方法，遍历 Entity 的字段，拼接CREATE TABLE语句：

public class SqlGenerator { public static void main(String[] args) { Field[] fields = DrugInfo.class.getDeclaredFields(); StringBuilder sql = new StringBuilder("CREATE TABLE `drug_info` (\n"); for (Field field : fields) { String column = camelToUnderline(field.getName()); String type = mapType(field.getType()); sql.append(" `").append(column).append("` ").append(type).append(",\n"); } sql.append(" PRIMARY KEY (`id`)\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;"); System.out.println(sql); } }

这样生成的 SQL 可以直接拿去跑。当然，生产环境里有 Flyway 这类工具，但毕设里用这种轻量方式生成建表 SQL，既省时间又能体现你对 ORM 机制的理解，答辩论起来也不虚。

4.3 登录认证：JWT + 拦截器是性价比最高的方案

日志系统用什么方案？毕业设计不建议用 Spring Security OAuth2，那个太重了。直接用 JWT 生成 Token + 自定义拦截器做校验，代码量少，逻辑直白，也够讲清楚。

登录流程：

1. 前端提交用户名密码
2. 后端校验用户状态（是否禁用）
3. 用 BCrypt 比对密码（如果使用 MyBatis-Plus 的加密逻辑，需要先passwordEncoder.encode存库）
4. 生成 jwt，把用户 id 和角色放进 claim
5. 返回 token 给前端，前端存到 localStorage
6. 后续请求在 Header 里带Authorization: Bearer <token>

拦截器核心逻辑：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new UnauthorizedException("未登录"); } // 解析 token，校验签名 Claims claims = JwtUtil.parseToken(token.substring(7)); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } }

重点是：白名单路径要配置好，比如/api/auth/login、/api/captcha不拦截，其它/**都走拦截器。如果你用 Redis 做验证码，登录时会多一次缓存校验，这块我在后面问题排查里说。

4.4 通用 CRUD：Service 抽取 BaseService

写管理系统最怕的就是每个模块重复写一套 CRUD。MyBatis-Plus 官方提供了IService和ServiceImpl，我们直接继承就行：

public interface IBaseService<T> extends IService<T> { }

然后每个业务 Service 继承这个接口，Mapper 继承BaseMapper<T>。这样像page分页查询、saveOrUpdate保存更新这类通用操作开箱即用，省下来的时间全花在业务细节上。

分页查询是毕设的必考项，我用 MyBatis-Plus 的Page对象这么写：

Page<Registration> page = new Page<>(current, size); LambdaQueryWrapper<Registration> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StringUtils.hasText(patientName), Registration::getPatientId, patientId) .eq(Registration::getStatus, status) .orderByDesc(Registration::getCreateTime); registrationService.page(page, wrapper);

前端传current和size，后端返回total和records，这套模式可以通吃所有列表页。

4.5 报表统计：SQL 分组比内存计算靠谱

报表模块是技术亮点的重灾区。比如“统计最近七天的门诊收入”，SQL 写法：

SELECT DATE(create_time) AS day, SUM(amount) AS total FROM payment_record WHERE type = '门诊' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY day;

在 Mapper 里定义一个带@Select注解的方法就行，返回一个List<Map<String, Object>>。前端拿到后直接用 ECharts 画折线图，视觉效果好，答辩演示很讨喜。

但这里有个细节：如果某一天没有收入，SQL 分组会直接跳过这一天，前端画图就会缺日期。处理办法是在 Java 层做补零，遍历日期区间把缺失的填成 0。这种业务边界想得越全，老师越觉得你有工程经验。

4.6 PDF 打印：处方单和病历的导出方案

很多系统需要把电子处方打印成纸质单，所以 Web 页面 PDF 打印也算一个点。纯前端方案最讨巧——用浏览器的window.print()打印当前页面区域，配合 CSS 里定义@media print的打印样式，比如隐藏导航栏、只显示处方内容、统一纸张大小。这个方法零依赖，够用。

如果需要生成 PDF 文件，后端可以用iText或者OpenPDF，套个模板把数据填进去输出 PDF。但毕设不建议在这上面耗太多时间，展示“页面直接打印”的效果已经足够。

5. 前端联动：Vue3 + Element Plus 的管理后台

5.1 页面结构设计

前端我用 Vue3 + Vite + Element Plus + Pinia + Vue Router。后台管理的布局基本是经典的三段式：左侧菜单栏、顶部用户栏、中间内容区。

主导航按角色动态渲染：管理员看到的是全部菜单，医生只看到接诊和病历，收费员只看到收费和退费。具体做法是登录成功后，后端返回该用户的菜单列表，前端生成路由和侧边栏。这种动态菜单效果演示起来很加分。

5.2 接口请求封装

统一封装 axios 实例，设置 Base URL：

const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) service.interceptors.response.use( response => response.data, error => { if (error.response.status === 401) { router.push('/login') } ElMessage.error(error.response.data.message || '服务器异常') return Promise.reject(error) } )

这里有个前后端联调细节：前端访问后端接口时会有跨域问题。最简单的方案是在后端加一个全局 CORS 配置，或者用 Vite 的 proxy 代理把/api转发到localhost:8080。推荐用 Vite proxy，这样生产环境也能灵活切换地址。

5.3 表单校验与数据回显

医疗系统里表单特别多，尤其是开处方这种动态添加药品明细的场景。Element Plus 的el-form配合rules做校验，动态行用v-for加prop下标绑定。注意药品数量和单价必须前端先算好小计，提交时后端再校验一遍总价，防篡改的意识要有。

6. 配置文件与部署上线：从能跑到能演示的关键几步

6.1 application.yml 核心配置

这个文件是后端能不能跑起来的第一道关。我贴一个常见配置：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hospital_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: assign_id

注意serverTimezone一定要配，否则本地 MySQL 和 JDBC 时区不一致会直接报错。map-underscore-to-camel-case是自动把下划线字段映射为驼峰属性，写实体类的时候必须开启。

6.2 打包与部署：本地能跑是基础，服务器能跑是加分

后端打包用 Maven：

mvn clean package -DskipTests

生成的 jar 包在target/下，直接在服务器上：

java -jar hospital-system.jar --spring.profiles.active=prod

前端构建：

npm run build

dist 目录就是静态文件，把 dist 里的文件丢到 Nginx 的 html 目录，再配一个反向代理：

server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里有个典型的坑：Vue 的 Router 如果是 history 模式，刷新某个子路径会直接 404。配置里的try_files $uri $uri/ /index.html;正是解决这个问题的。这是我被问过无数次的经典问题。

免费部署平台方面，如果想找免费的 Web 服务器网站或者云服务做演示环境，可以用 Vercel（只适合前端）、Railway、Render 这类平台，但要注意免费套餐的冷启动和地域限制。如果只是演示给老师看，本地跑通再加一个内网穿透工具就足够。

7. 常见问题排查与答辩避坑指南

7.1 项目启动失败：大概率是依赖和版本问题

“springboot 版本太高”是很多人卡壳的原因。比如你本地 JDK 是 8，但项目引的是 SpringBoot 3.x，启动时会直接报UnsupportedClassVersionError，因为 3.x 要求 JDK 17 以上。

排查步骤建议：

1. 先看 Maven 的依赖树：mvn dependency:tree
2. 重点看 spring-boot-starter-parent 版本和 JDK 是否匹配
3. 把 IDEA 的 Project Structure 里 Project SDK 改成对应 JDK 版本
4. Maven 的 JDK 配置也要同步改：settings.xml或者 IDE 里的 Maven Runner JRE

还有一类问题是 MySQL 连不上，报Access denied for user 'root'@'localhost'，这时别急着改代码，先到命令行用mysql -u root -p试一遍，排除密码或权限问题。

7.2 前后端联调报 404：先分清是路由问题还是接口问题

前后端分离项目，404 的来源有三个：后端接口不存在、前端请求地址拼错、Nginx 配置把前端路由吞了。我在联调时会先看 Network 面板，如果请求发出的地址是/api/xxx，而后端 Controller 映射是/api/xxx，那就看后端控制台有没有报错。没有报错就是白名单或拦截器把请求挡了。

如果是页面刷新 404，基本就是 Nginx 的try_files缺失，我上面已给了配置，直接抄。

另外一个常见问题是验证码或二维码加载不出来。排查顺序：后端接口是否可访问？返回 Base64 还是图片流？前端 img src 是否正确拼接了 data URI？八成是 Base64 前缀缺失。

7.3 答辩演示的应急技巧：手动数据比页面好看更重要

答辩当天，最坏的情况是某个模块突然点不了。我的建议是准备一组“演示剧本”数据：固定的测试账号、固定的患者编号、固定的处方模板。演示时按剧本走，而不是现场随机输入。比如先登录管理员查看统计图表，再切换医生账号接诊一个提前造好的患者，处方开完去收费员账号点收费，全程一气呵成，给老师的流畅感非常加分。

另外我强烈建议在本地把 MySQL 数据导出一个备份 SQL，如果演示前误删数据，直接导入恢复，比现场修数据库快一百倍。

7.4 常见异常速查表

8. 最后想说的一点个人体会

做毕设这些年总结下来，医疗管理系统这类题目的核心价值不在“代码量”，而在于你是否有把真实业务流程落成软件系统的能力。从挂号到收费再到入库出库，每一个表字段背后的设计选择，都能在答辩时变成你讲故事的素材。与其追求炫技，不如把主流程做扎实，把权限和安全意识做到位，再选一两个细节（比如 JWT、MyBatis-Plus 的动态 SQL 生成、ECharts 报表）讲得有深度，就已经能稳稳拿下。

最后再分享一个小技巧：源码里一定要留足够的注释，尤其在后端跨模块调用的地方。很多同学写完代码放一周再看就完全不认识了，这很正常，所以边写边注释才是真正的省时间。如果你从这篇文章开始动手，我建议先不要碰代码，花一晚上把表结构和角色流程画清楚，磨刀不误砍柴工。