基于Spring Boot的医药管理系统：从选题到答辩完整实战指南

最近后台收到不少私信，都在问毕业设计怎么选题、怎么落地。Java方向的同学，十个里有六个绕不开“管理系统”这三个字。今天挑一个非常典型、也非常能出成果的题目来拆——基于Spring Boot的医药管理系统。这个题目属于“进销存+权限+统计”的综合型业务系统，比单纯的学生信息管理、图书管理上了一个档次，又没复杂到像电商平台那样需要分布式、消息队列、高并发。对Java后端方向的毕业生来说，是一个性价比极高的选题。

我当年带模拟项目X的时候，好几个学生都是拿这个方向做基础，然后各加各的功能：有的加了药品批次效期管理，有的加了出库自动扣减库存的逻辑，有的做了简单销售趋势图。整体下来，既能充分展示Spring Boot的核心能力，又能让答辩评委看到完整的业务闭环。这篇文章我会从选题思路、技术选型、数据库设计、核心功能实现、调试运行到最后答辩文档，完整过一遍。内容不绕弯，直接照着能落地写。

1. 为什么选这个题目：从选题到需求整理的完整思路

不少同学选毕设题目时容易走两个极端：要么选太简单，比如单表的增删改查，工作量撑不起一次答辩；要么选太难，比如“基于微服务的医疗服务平台”，结果一个人搞不定。医药管理系统恰好卡在一个非常合适的位置上——业务逻辑不复杂，但功能链路长，能体现完整的技术应用能力。

1.1 医药管理系统到底在解决什么问题

管理系统的本质，是把线下纸质记录、Excel表格里的信息流转，搬到线上变成可查询、可追溯、可统计的数据流。医药管理系统的特殊之处在于两点：

第一，药品有库存、批次、供应商和有效期。药店或者小型医疗机构进货时，要记录是哪家供应商送来的，生产批号是多少，保质期到什么时候，进价多少，售价多少。这些信息缺一不可，直接决定系统要有多少张表和多少条关联关系。

第二，业务场景是“进销存”的完整闭环。采购入库，库存增加；销售出库，库存减少；到期药品需要预警；库存低于某个阈值需要提示补货。分析清楚这个业务闭环，系统的功能边界就非常明确了。

1.2 需求分层：别把毕设做成“大而全”

做毕设最容易犯的一个错误，就是“什么都想做”。我今天加了预警，明天想加药方管理，后天又想加图表分析，最后一个月过去了，代码写了一堆，但没有一个模块是完整能跑的。正确做法是把功能分三个等级：

第一等级是核心功能，不做就没法交差，包括用户登录注册、药品信息管理、供应商管理、采购入库、销售出库、库存查询。第二等级是加分功能，包括库存预警、销售统计图表、操作日志、密码修改。第三等级是探索功能，包括药品批号效期追踪、会员积分、多角色工作台联动。建议精力分配是核心功能70%，加分功能25%，探索功能看剩余时间再决定。

需求整理完成后，最好画一份简单的功能清单。不用特别正式，但要让自己的思路清晰，也让导师或者评委一眼能看出你对业务的理解深度。

1.3 预估工作量与技术难点

从零开始做这个项目，一个处于中等水平的同学，每天投入四五个小时，大概需要三到四周。时间分布大概是：第一周做环境搭建、数据库设计、项目框架搭建，第二周做用户权限和药品基础信息管理，第三周做采购、销售、库存流水，第四周做统计和答辩材料。

技术难点其实不在某个单点功能上，而在于“业务状态流转的完整性”。举个例子，销售出库时，不仅要插入一条销售记录，还要更新库存表中的数量，还要写一条库存流水。这三个动作必须在一个事务里完成，否则就会出现“钱收了但库存没减”这种数据不一致问题。这个点被很多人忽略，却是答辩时最容易出彩的地方。

2. 技术选型分析：Spring Boot + 什么组合最稳妥

技术选型的核心原则只有一条：在能满足功能需求的前提下，优先选择自己最熟悉、资料最多、排查问题最容易的方案。毕设答辩不是技术选型大赛，评委不会因为你用了冷门框架就给你加分，反而会因为框架太冷门、你答不上来原理而扣分。

2.1 后端选型：Spring Boot版本怎么选

Spring Boot的版本，建议选择稳定版本中用户量最大的一批。别追最新版本，因为新版本有时候伴随依赖兼容性问题，网上排查帖子和教学案例相对较少，调试时一旦报错容易卡住。相反，选择使用量大的版本，你在网上搜任何一个报错信息，基本都能找到现成的解决方案。

Java版本建议JAVA 8或者JAVA 11，这两个是学校机房和大多数教程的默认环境。如果电脑上装的是更新的JDK，也建议配置上兼容模式，避免启动时报各种莫名的兼容性错误。

2.2 ORM与数据库：MyBatis还是JPA

这是一个经常纠结的问题。我的建议很直接：如果对两者的熟练度差不多，优先选MyBatis，原因有三个。

第一，MyBatis的XML里写SQL，SQL是明晃晃的，报错的时候更容易定位是SQL问题还是Java问题。JPA虽然写起来更“自动”，但复杂查询一旦涉及多表关联、条件拼接，调试门槛明显提高。

第二，MyBatis在互联网公司的使用率极高，企业里很多老项目也是MyBatis体系的，做毕设的过程本身就相当于提前熟悉工作内容。

第三，MyBatis可以实现非常精确的SQL优化，比如分页的时候用LIMIT参数传递，连表查询的时候只查需要的字段，这些细节在答辩里讲出来，是很扎实的加分点。JPA不是不能选，只是对SQL掌握不熟练的同学来说，出问题之后会相对被动。

数据库方面只用MySQL就够了，版本5.7或者8.0都可以。5.7兼容性好，各种教程多；8.0的窗口函数等特性更强，但很多学校的教学环境还在用5.7。如果你本机装的是8.0，工程里注意连接驱动的版本和URL参数写法，具体细节后面调试部分会详细讲。

2.3 前端方案：Thymeleaf、Vue还是Bootstrap

前端方案决定了你的开发效率和答辩展示效果。这里分三种情况。

如果你的基础一般，时间紧张，建议直接用服务端渲染方案。Spring Boot自带模板引擎支持，页面写起来类似JSP但更简洁，可以直接在HTML里写循环、判断、拼接URL，后端把数据塞进Model里返回视图即可。这种方式的优势是不需要前后端分离，不涉及跨域问题，一个项目里搞定所有事情。

如果你平时用过Vue，也熟悉Axios请求，那就做前后端分离。后端提供JSON接口，前端用Vue脚手架搭建页面。这种做法的好处是代码结构更清晰，简历上也更好看，但代价是你要同时维护两个工程，部署时还要处理跨域、打包、合并的问题，工作量会比服务端渲染多不少。

如果你只是想要一个还不错的界面效果，又不想花太多精力，那就找一套漂亮的Bootstrap后台模板，把页面套进来，表单和表格组件直接用现成的。很多开源的免费后台模板页面都已经写好了样式和布局，你只需要填充自己的表格字段和接口调用即可。

2.4 为什么选这套技术栈

这套组合（Spring Boot + MyBatis + MySQL + Bootstrap后台模板）之所以被反复推荐，是因为它的“确定性”非常高。任何一个步骤报错，网上都能找到对应的解决方案。做毕设最重要的是在规定时间内稳定完成一个能跑通的系统，而不是去挑战不确定性。技术栈越主流，你的调试成本越低，答辩时评委也越容易理解你的系统架构。

提示：如果项目描述里包含“源码+文档+讲解”这类信息，说明选题方已经验证过这套技术组合的可行性。对应地，你自己做的时候也尽量不要选太冷门的技术组合，万一卡住，连个问的人都没有。

3. 数据库设计：医药系统最核心的一步

数据库设计是整个项目中工期最长、返工最痛苦的部分。只要库表设计合理，后面的Java代码写起来会非常顺；如果表结构设计错了，比如把金额字段设成整数导致无法统计，或者缺少库存流水表导致没法追溯，那就得返工重来。这里我直接给出一套完整可落地的表结构设计方案。

3.1 核心表结构：药品信息、分类、供应商

第一张表是系统用户表，字段包括主键ID、用户名、密码、昵称/姓名、角色、手机号、创建时间、更新时间。密码字段注意要存加密后的内容，千万不能明文入库。角色字段直接用一个字符串区分管理员和普通操作员，简单直接。

第二张表是药品分类表。字段：分类ID、分类名称、父分类ID、排序号、备注。这里加父分类ID是为了以后支持两级分类，比如“抗生素类”下面再分“头孢类”“青霉素类”，虽然毕设可能用不到，但字段预留好，方便后续扩展。

第三张表是药品信息表，这是整个系统的核心表。字段包括：药品ID、药品编码、名称、通用名、规格、单位、生产厂家、批准文号、分类ID、进价、售价、库存数量、预警阈值、保质期、生产批号、状态、备注、创建时间、更新时间。其中药品编码建议做成唯一索引，因为药房出入库扫描、统计报表都依赖这个字段来辨别具体药品。

第四张表是供应商表。字段包括：供应商ID、名称、联系人、联系电话、地址、证件编号、备注、录入时间。

3.2 业务表设计：采购入库、销售出库、库存变动记录

药品信息表只是记录了当前库存状态，但是“库存从100变为80”这个过程本身，需要单独的一张流水表来记录。这张表就叫库存变动流水表，字段包括：流水ID、药品ID、变动类型（入库/出库/盘点）、关联单据号、变动数量、变动前库存、变动后库存、操作人ID、变动时间、备注。

采购入库的时候，主表是采购入库单表，字段包括：入库单ID、入库单号、供应商ID、操作人ID、入库金额合计、入库数量合计、入库时间、状态。子表是入库单明细表，记录每一行药品对应的ID、数量、单价、金额。

销售出库同理，销售单表存储每次销售的整体信息，销售单明细表存储具体卖出去的药品明细。之所以要拆成主表和明细表，是因为一笔销售可能包含多种药品，把全部信息堆在一张表里会非常混乱，后期统计销售额、销售数量也难写SQL。

这套设计的核心思想是“主表管整体，明细表管个体，流水表管变化”。只有把这三层都做出来，才称得上是一个完整可追溯的系统。

3.3 表关系与主外键设计的避坑点

表关系设计时的常见错误是过度使用外键约束。在学习阶段，大家可能会习惯地在数据库层面用外键建立关联关系，但实际项目开发中，很多团队会刻意减少外键约束，原因在于：外键约束会影响写入性能，并且在业务复杂时容易因为关联校验导致数据操作失败。

正确的做法是，在设计层面明确逻辑外键，比如药品表里有分类ID字段，但不一定在数据库层面强制指定FOREIGN KEY。在Java代码里通过关联查询来保持一致。这样做的好处是建表简单、操作灵活，也不影响后端程序对数据的控制。这一点在答辩时如果被问到“为什么没有外键”，可以解释为：为了保证高并发场景下单表写入的独立性，同时避免级联删除误删数据，采用逻辑外键方案，由应用层控制数据一致性。这个回答是比较加分的。

3.4 设计规范：字段命名、时间戳、软删除

字段命名建议统一使用下划线风格，对应Java中的驼峰命名，并在MyBatis配置文件里开启驼峰映射。比如数据库字段create_time，Java实体属性写成createTime，这样MyBatis自动映射，不需要每个字段都写resultMap。

所有的业务表都应该带上创建时间和更新时间两个字段，方便排查数据问题。同时建议预留逻辑删除字段，比如deleted，0表示未删除，1表示已删除。注意，物理删除是直接把记录从表里删掉，逻辑删除只是改一个标记位。对于业务表来说，物理删除风险很高，比如把一条入库单主表记录删了，但它的明细记录还在，就会造成数据不完整。用逻辑删除能避免这类问题，后续统计也能保证数据的完整性。

建立时间字段的类型，建议使用datetime，Java侧用LocalDateTime接收，存和取都方便。金额字段建议使用DECIMAL(10,2)，千万别图省事用FLOAT或DOUBLE，浮点类型在累加和比较时存在精度问题，统计销售总额时算错1分钱都够折腾半天。

4. 核心功能实现与代码要点

数据库设计好之后，代码层就是把这些表映射成实体类、Mapper接口、Service服务、Controller接口，再做页面展示。这里需要特别注意的功能实现细节，下面展开讲。

4.1 通用CRUD与分页查询

分页查询是管理系统的标配功能，几乎每个列表页面都要用。MyBatis实现分页通常有两种做法。

一种是手写LIMIT实现，适合单表简单查询。另一种是直接使用PageHelper这个分页插件，用法是在查询前调用PageHelper.startPage(pageNum, pageSize)，紧接着执行的查询会自动拼接分页语句，返回结果用PageInfo封装，直接拿到总记录数和分页数据。

这里有一个特别容易踩的坑：PageHelper.startPage必须紧跟第一条查询语句，中间不能插入其他数据库操作。否则分页参数会失效，甚至导致后续所有查询都被错误地加上LIMIT条件。我见过有人在这个小问题上排查了两天。

前端的分页组件建议自己写一个简单的页码条，显示上一页、下一页、总页码数和总数。后端接口设计统一为：返回当前页数据列表、总数量、总页数、当前页码。后续统计报表等等都复用这套分页结构。

4.2 库存流水与预警

库存预警的实现思路是在药品信息表中设置最低库存阈值字段，每次查询药品列表时，根据“当前库存数量小于等于预警阈值”这个条件来筛选出需要预警的记录，在页面中用高亮颜色标记出来。

真正关键的是“出库时同步扣减库存”的完整流程。比如用户在前端提交了一个销售单，后端Controller收到数据后，Service层需要在一个事务里执行四步操作：

第一步，生成销售单主表记录，状态设置为“已出库”。第二步，遍历销售明细，对每个药品执行库存扣减，检查当前库存是否足够，不够则抛出异常回滚事务。第三步，为每个药品插入库存流水记录，内容包括变动前的数量、变动后的数量、关联单据号，并注明变动类型为“出库”。第四步，回写销售单的总金额和总数量。

用@Transactional注解给这个业务方法加事务，只要任何一步出现异常，数据库就自动回滚，不会出现销售记录已经生成了，库存却没扣减的脏数据场景。这个实现逻辑是答辩时最值得拿出来讲的一段代码。

4.3 权限与登录

登录认证的方案直接建议使用Spring Security框架。Spring Security是Spring体系自带的安全框架，集成简单，毕业设计这个量级的功能完全够用。当然，如果觉得Spring Security配置繁琐，也可以直接用一个拦截器来实现简单的登录校验：拦截所有请求，判断Session中是否存在用户信息，没有则跳转登录页。这种方式实现快，代码量少，缺点是灵活性和安全性不如专门的安全框架。

我的建议是量力而行。如果对安全框架比较熟，就上Spring Security；如果不熟，就用Session加拦截器的方案，功能上足够应付教学场景。提前判断好自己能否在三小时之内把Spring Security配置跑通，跑不通就放弃，学会选择也是工程师必备的能力。

4.4 销售统计与图表

图表统计模块是很多评分表里的加分项。实现思路是先写统计SQL，比如统计近七天的日销售额，SQL按天分组，汇总金额；再写一个接口返回分组结果；前端用图表插件，如ECharts，展示柱状图或折线图。

这个模块的难点不在图表库的使用，而在SQL的日期分组处理。MySQL里可以用DATE_FORMAT(create_time, '%Y-%m-%d')来格式化时间字段并按天分组。需要注意处理“某天没有销售数据”的情况，如果用LEFT JOIN补零，会稍复杂一些。对于毕设来说，直接按查询结果渲染图即可，空的天数不显示也不会影响评分。

4.5 导入导出与操作日志

导入导出通常用EasyExcel或者POI做，实现思路是：后端使用EasyExcel的ExcelReader读取上传文件，一行一行解析成实体对象，校验字段合法性后批量插入数据库；导出则从数据库查询结果集，用ExcelWriter写入Excel文件流并响应给前端下载。导出功能强烈建议做，因为答辩时“一键导出报表”是个非常直观的演示点。

操作日志建议用一个简单的AOP切面实现，标注一个自定义注解，在需要记录日志的方法上加上注解，AOP拦截到方法调用后记录操作人和操作内容。这个功能放在系统里不占多少资源，但在答辩时对系统完整性的加分很明显。

5. 环境搭建与调试运行

很多学生拿到的毕设项目，代码本身没有问题，问题出在自己的电脑上跑不起来。环境搭建虽然不难，但坑非常多。这里按顺序把每一步应该注意的细节说清楚。

5.1 开发环境与版本组合

推荐的环境组合是：IDEA（或者Eclipse）、JDK 1.8、Maven 3.6以上、MySQL 5.7或8.0。如果是用IDEA，社区版完全够用，不需要破解商业版。Maven本地仓库建议提前配置好国内镜像，否则第一次导入项目时下载依赖会慢到让你怀疑人生。

导入项目的操作注意一点：使用IDEA导入Maven项目时，要选择以Maven项目方式导入，而不是简单地把文件夹打开。具体操作是：File -> New -> Project from Existing Sources -> 选择pom.xml文件，这样IDEA才会把Maven结构识别出来并自动下载依赖。

5.2 导入项目与配置数据库

第一次启动前，需要先创建数据库并执行SQL脚本。SQL文件位置一般在项目的sql或者doc目录下。执行时选择正确的数据库，避免脚本报错。执行完脚本后，检查数据表是否完整创建，尤其关注有没有初始化数据，比如管理员账号。

连接数据库的配置在application.yml或application.properties里，关键配置项为数据库地址、端口、库名、用户名和密码。特别提醒MySQL 8.0的驱动类名和URL参数与5.7不同，8.0的驱动名是com.mysql.cj.jdbc.Driver，URL里需要加serverTimezone=Asia/Shanghai，否则可能出现时区相关的报错。

5.3 启动调试与遇到的第一批坑

项目启动后，看到“Started Application in xx seconds”就代表启动成功，然后浏览器访问项目端口即可。如果启动报错，绝大多数情况下是以下原因导致。

端口被占用是最常见的报错之一，处理方式是找到占用此端口的进程并结束它，或者修改server.port配置为其他端口。数据库连接失败则检查数据库服务是否启动、账号密码是否正确、库名是否存在。依赖缺失则是Maven没有把依赖库下全，先看网络和镜像配置，然后点击IDEA的刷新Maven按钮重新下载。

值得注意的一个细节是，很多新人会忽略数据库的时区问题。连接成功却在查询所有带时间字段的表时报错，比如“The server time zone value”，处理办法很简单，在数据库连接URL里增加时区参数即可。这类问题非常典型，记住一次，以后做别的项目也能秒解决。

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

这部分直接整理成速查表，方便遇到问题时逐条对照。以下是我带项目过程中见到频率最高的问题和对应的排查思路。

以上这些坑，你在自己做项目时大概率都会碰到几个。别紧张，每遇到一个就把它记录下来，这本身就是很好的答辩素材。被问“做项目过程中遇到过什么问题”时，能清晰讲出来龙去脉和解决方式，是很大的加分项。

7. 毕设答辩与文档撰写的补充经验

代码能跑只是最低标准，答辩能讲明白才是真正决定成绩上限的因素。这一块很多人会忽视，但其实用对方法，一周时间就能把答辩准备得很充分。

7.1 文档该怎么写

文档的核心不是“写得越长越好”，而是“让评委看到你对整个软件生命周期都有控制力”。建议按照需求分析、系统设计、数据库设计、系统实现、系统测试、总结展望这样的经典结构来组织内容。

需求分析部分要写明系统角色划分和功能列表，尽量用功能模块图辅助说明。系统设计部分写清楚技术架构和分层结构，重点说明Controller、Service、Mapper三层的职责边界。数据库设计部分是重点，至少包含实体关系图、核心表结构说明、字段含义解释。

测试部分除了写功能性测试用例之外，再加一小段“异常情况测试”，比如库存不足时的回滚验证，这个比较容易体现专业度。总结部分别写哲学感想，写清楚“这个系统哪些地方做得比较稳，哪些地方还有提升空间”，诚恳朴实一点，评委印象反而更好。

7.2 答辩陈述怎么说

答辩陈述建议遵循“总分总”的讲法：先花30秒说明这个系统是什么、面向什么场景，也就是整体定位；再花三到五分钟按模块讲解核心功能和采用的技术方案；最后用一分钟讲一下自己做项目时踩过的最有代表性的坑，再展示一遍核心功能演示。

演示环节要特别准备，演示用的数据要提前造好，别现场录数据。把登录页、药品列表、入库操作、出库操作、库存预警、统计图表，这几个关键页面按顺序准备好截图，同时把系统跑通。避免在答辩现场出现网络问题、数据库没启动等低级状况。

7.3 讲解直播与远程调试时的注意事项

不少同学会选择一边讲解项目一边演示调试，这里有个特别重要的技巧：提前把浏览器收藏夹里放好关键页面，调整好窗口大小，并把命令行工具提前打开。演示时别从启动项目开始演示，因为等待时间太长会让所有人失去耐心。直接从已运行状态开始，按业务流转的顺序来演示，效率最高，观感也最好。

讲代码的时候，可以按“登录 -> 权限校验 -> 业务处理 -> 数据落库”这个顺序展开。这样别人听起来会觉得你很有条理，而不是东讲一块西讲一块。

最后再分享一个小技巧

做这类管理系统类的毕设，有一个非常容易被低估的加分动作：在项目里加一个“批量导入药品”的功能。这个功能代码量不大，逻辑也不复杂，但演示效果极好。答辩时一键上传Excel、看着表格数据刷进系统里、列表页瞬间出现几十条新数据，这个视觉冲击力比讲任何技术原理都直接。

另外，如果条件允许，把项目部署到云服务器上跑一遍，哪怕只是部署成功、页面能访问，也值得写进文档。很多同学毕业以后发现，学校里的项目和真实工作场景差距不小，而提前经历过部署这个环节，在你后续学习和求职时都会比别人更快进入状态。项目本身不难，难的是踏踏实实把每个环节都走通的感觉，这种感觉一旦建立起来，后面很多东西都会顺很多。