Spring Boot宠物医院管理系统：从数据库设计到权限控制的Java毕设全攻略

1. 为什么宠物医院管理系统能成为Java毕设的“常青树”

每年到了毕业设计选题季，总有一批同学会在“新潮选题”和“稳妥选题”之间反复纠结。我的建议一直很明确：如果是Java方向，选一个业务完整、技术栈主流、数据关系清晰的系统，远比重金押注冷门框架要划算。宠物医院管理系统就是这么个“常青树”——它不像商城系统那样烂大街，又比图书管理、学生管理这类基础CRUD更有业务深度，更重要的是它天然具备一套完整的业务闭环。

我见过不少毕设翻车的案例，问题几乎都出在同一个地方：选题时只看了标题感觉“挺简单”，等到写开题报告才发现业务逻辑撑不起来，数据库表设计得七零八落。宠物医院管理系统恰好避开了这个坑。它的业务虽然多，但每块都是实际场景中真实存在的：宠物主人建档、宠物信息登记、分诊挂号、医生看诊、开具处方、药品划价、住院管理、疫苗提醒、营业统计……这些模块单拆出来都不复杂，但组合在一起就能形成一套完整的管理系统，正好适合用来展示你对Spring Boot生态的掌握程度。

还有一点很关键：这个题目的需求文档和目标用户非常清晰。评审老师一眼就能看懂“这个系统到底在管理什么”，不用你费劲解释业务背景。做毕设最怕的就是项目做完了，别人还要追问“这个系统解决什么问题”。宠物医院管理系统不存在这个尴尬，它面向的是宠物诊疗机构的日常运营场景，用户角色天然分为管理员、前台/护士、医生这几类，权限划分顺理成章，数据流转也有一条非常清晰的主线。

如果你正在纠结要不要选这个题，我的判断是：它特别适合Spring Boot体系基础扎实、想做出“完整项目感”而不仅仅是“功能堆砌”的同学。前端的复杂度可控，后端的业务有深度，数据库可设计出足够漂亮的ER图，这些恰好是答辩时最能加分的部分。

2. 核心需求拆解：先梳理业务闭环，再动手写代码

很多同学做毕设的习惯是拿到需求文档直接开始建表、写接口，跳过了最关键的环节——把业务到底怎么运转搞清楚。在宠物医院这个场景里，如果不先把流程理顺，你会不断陷入“这个字段放哪张表”“这个状态由谁更新”的纠结中。我习惯的做法是先画出一套业务闭环，再逐段拆解成模块。

整个系统的业务主线其实可以概括成一句话：**宠物主带宠物进店，前台挂号建立就诊档案，医生接诊开处方，药品划价收费后进入治疗或住院流程，最后离店并支持后续复诊随访。**这个主线上挂着几个信息核心：宠物档案、就诊记录、处方明细、药品库存、住院床位。所有功能模块都是在为这条主线服务。

围绕这条主线，我把系统的功能拆成六大块。

2.1 基础资料管理：宠物主、宠物档案和医生排班是地基

基础资料模块看着简单，实际上是整个系统的数据地基。宠物主信息除了常规的姓名、电话、地址，建议加上“常用就诊偏好”和“历史消费等级”这类字段，方便后续做会员管理。宠物档案更值得细做，品种、年龄、性别、绝育状态、疫苗记录、过敏史、既往病史，这些都是医生开处方时必须参考的信息。

特别提醒一下：过敏史一定要作为显眼字段单独放在宠物档案首页。我见过有系统的过敏史写进了备注字段里，结果开药时医生根本没注意到，这个问题在真实场景中是会闯祸的。虽然是毕设，但从设计上就要有这种“防错”意识，答辩时也是加分点。

医生排班管理也应该算进基础资料里。挂号时要选医生，那这个医生今天是否坐诊就必须有依据，不能写死在下拉框里。我建议做一个简单的排班表，按周一到周日配置坐诊医生，挂号时前端只展示当天的在班医生。这个设计不复杂，但体现出了“你对业务有完整思考”。

2.2 挂号与就诊主流程：状态流转是核心难点

挂号是整个业务主流程的起点。前台选择宠物主（没有的话先建档）、选择宠物、选择医生，然后生成挂号单。从这一刻起，这个挂号单就进入了一条状态链：已挂号 -> 等待就诊 -> 就诊中 -> 已完成 -> 已取消。

这条状态链是整个系统最容易做乱的地方。我见过很多同学的实现是写一堆if else在控制层里判断状态允许不允许变更，最后代码越写越丑。正确做法是在Service层统一收敛状态流转逻辑，用一个状态机或者至少一组状态流转校验方法来管理，确保“已完成”的单子不能被直接改回“就诊中”，已经取消的单子没法继续开处方。

就诊环节医生端主要做两件事：记录诊断结果和开具处方。诊断结果包括主诉、检查项、诊断结论，处方则是这次就诊的核心产出，由药品明细（药品、剂量、频次、天数）和处置建议组成。开完处方后自动生成收费单，进入收费流程。

2.3 药品库存与收费划价：联动才是精华

药品管理和收费是绝大多数同学做得比较薄弱的环节。很多人做药品模块就只是增删改查，做收费模块也只是算个总价，两者之间没有联动，这在答辩时很容易被追问到哑口无言。

这里值得多花点功夫：药品库存包含入库批次、库存数量、预警阈值、售价、规格、生产日期和有效期。开处方选药品时要实时校验库存，库存不足直接阻断保存。收费时要根据处方明细计算总价，收费完成后要自动扣减库存，如果扣减后低于预警阈值要产生一条补充库存的提醒记录。这套联动逻辑做出来，你的系统就从一个“信息登记工具”升级成了真正的“管理系统”。

收费状态也需要单独设计。一张收费单对应一次就诊，状态分为未收费、已收费、已退费。退费的前提是药品库存要加回来，这一点很容易漏。做退费操作时一定要同步回补库存，否则跑一段时间库存就对不上了。

2.4 住院管理：最容易被低估的模块

宠物医院和人的医院一样，有需要留院观察或者住院治疗的情况。住院管理是很多同学容易忽略、但非常出彩的模块。

住院模块的核心是床位管理。床位分科室（内科、外科、住院护理区）和状态（空闲、占用、消毒中）。入院登记时选择床位，生成住院记录，之后每天医生可以录入查房记录、用药记录、护理记录。这些记录组合成了住院明细，出院时根据住院天数和用药明细统一结算。

这个模块能很好展示你对复杂业务的设计能力，因为一张住院单关联了患者档案、医生、床位、医嘱记录、费用明细多张表，接口设计稍不小心就会变成“一张大表塞所有字段”。如果能在这一块把关联查询和事务处理做好，项目整体的技术含量会上一个台阶。

3. 技术选型与项目结构：Spring Boot生态里挑最顺手的一套

技术选型是毕设开题时就要定下来的事，我见过太多同学在框架选择上耗费大量时间，今天想用这个ORM，明天想换那个权限框架，其实完全没必要。宠物医院管理系统这套业务，用Spring Boot 2.x/3.x配合一套稳定生态就足够了。

3.1 后端：Spring Boot + MyBatis-Plus是稳妥组合

后端核心自然是Spring Boot，这一点标题已经定了。ORM层我比较推荐MyBatis-Plus，理由很实在：单表CRUD几乎不用写SQL，内置的分页插件很好用，代码生成器还能一键生成实体和Mapper，能省下大量写重复代码的时间，让你把精力放在核心业务逻辑上。

权限认证用Spring Security或者Sa-Token都行。如果是新手，我反而更推荐Sa-Token，它的API设计更直观，登录、鉴权、退出登录就是几行代码的事，学习成本比Spring Security低不少。当然，如果导师明确要求Spring Security，那就用Spring Security，这也不是什么难事，核心是你要把“登录后才能访问”“不同角色看到不同菜单”这两件事跑通。

参数校验直接用Spring Boot内置的@Validated注解配合@NotBlank这类约束注解，比自己在控制层写一堆if判断干净得多。全局异常处理用一个@RestControllerAdvice统一拦截，返回统一格式的Result<T>，这属于必备基础，不做的话接口风格会非常凌乱。

3.2 前端：Vue 2/3 + Element UI是主流方案

前端技术选型上，绝大多数毕设用的是Vue搭配Element UI（Vue 3对应的是Element Plus）。这套组合最大的优势是组件齐全、文档丰富、示例随处可见，对于不专门做前端的Java方向同学来说是最快能出效果的方案。

页面结构建议这样组织：

• 登录页：独立的页面，登录后根据角色跳转到不同的首页布局。
• 管理端布局：左侧菜单栏按角色动态渲染，顶部是用户信息和退出按钮。
• 核心业务页面：宠物主管理、宠物档案、挂号单、就诊工作台、处方管理、收费管理、住院管理、药品库存、统计报表。

前端交互上有一个非常重要的点：权限控制不能只靠隐藏菜单。后端接口必须有对应的角色校验，前端隐藏菜单只是为了用户体验，真正防止越权操作靠的是后端。这个意识在答辩时提出来，是一个很不错的亮点。

3.3 项目结构怎么分包才显得专业

很多同学项目代码混乱的根源是分包不合理，一个Controller几百行，一个Service接口几百行，连自己都懒得维护。我建议的分包方式是按业务模块划分，而不是按技术类型划分：

com.example.pethospital ├── common # 公共类：统一返回、异常处理、常量 ├── config # 配置类：MyBatis-Plus、跨域、拦截器 ├── controller # 控制层，只做参数接收和结果分发 ├── service # 业务层，核心逻辑全部在这 ├── mapper # 数据访问层 ├── entity # 实体类 ├── dto # 前端交互对象 ├── vo # 视图对象，给前端返回的聚合数据 └── utils # 工具类

注意dto和vo的区别。很多同学从头到尾只用一个实体类，查询结果拼字段就加字段，最后实体类膨胀得不成样子。dto是前端传过来的参数对象，vo是你返回给前端的数据对象，实体类是数据库表的映射，三者各司其职，代码会清爽很多。

4. 数据库设计是成败关键：表结构、状态机与索引取舍

可以这么说：毕设答辩翻车的人里面，有一半是栽在数据库设计上。宠物医院管理系统这种多模块业务系统，数据库表如果设计得乱，后面所有代码都是在给混乱打补丁。

4.1 核心表清单与关系说明

我列举一下这套系统最核心的表，你可以对照检查自己的设计是否覆盖完整：

这里面关系最复杂的是住院相关的三张表。我建议住院记录拆成主表和明细表两张，主表记录哪个宠物住了哪张床、入院出院时间，明细表记录每天的查房记录、用药情况。这样查询住院总费用时按明细汇总即可，逻辑清晰。

4.2 状态字段用整型枚举还是字符串

状态字段的设计建议统一用整型或短字符串加注释，不要用无意义的数字裸奔。比如挂号单状态，我建议定义常量类或者枚举类：

public class RegistrationStatus { public static final int REGISTERED = 0; // 已挂号 public static final int WAITING = 1; // 等待就诊 public static final int IN_TREATMENT = 2; // 就诊中 public static final int COMPLETED = 3; // 已完成 public static final int CANCELLED = 4; // 已取消 }

另外强烈建议在数据库设计文档里为每个状态字段画一张状态流转图（用文字描述流转规则也可以），说明哪些状态能变成哪些状态。这不仅是开发时的依据，也是写系统设计文档时的核心素材。答辩老师问“这个状态机怎么设计的”，你答得越清楚，印象分越高。

4.3 常用查询字段的索引设计

索引不需要多，但关键的不能缺。外键字段（如宠物ID、医生ID、挂号单ID）应该加普通索引，因为几乎所有业务查询都是按这些字段关联的。挂号单建议加(doctor_id, status)联合索引，因为医生端的待就诊列表是高频查询。药品库存表给stock_quantity加普通索引意义不大，按名称模糊搜索的场景和索引关系也不大，不用过度设计。

每月账单、周报这类统计查询，如果数据量大，可以考虑在表里冗余一个“统计月份”字段，用定时任务或者手动触发的方式生成汇总记录。毕设体量下数据量通常不大，直接SQL聚合就行，不必上复杂方案。

4.4 最容易被忽略的“逻辑删除”

毕设里的删除操作几乎不该有物理DELETE，尤其在核心业务表上。想想看：挂号单被删了，那这个宠物来过医院的就诊痕迹就没了；用户被删了，他的日志记录怎么追溯？

我建议所有核心业务表都加上deleted字段，用MyBatis-Plus的@TableLogic注解实现逻辑删除。删除操作只是把deleted从0变成1，查询时自动过滤。这个设计既保持了接口的直观性，又保证了数据可追溯，是生产系统的基本素养。

5. 关键功能实现与踩坑记录：编号生成、状态流转、权限控制、异步提醒

到了真正动手写代码的阶段，你会发现大部分增删改查都没什么难度，真正花时间的是几个“看起来不起眼、做起来容易翻车”的细节。我把这几块单独拿出来讲。

5.1 编号自动生成：不要只用自增主键糊弄用户

挂号单号、住院单号、收费单号要给用户展示可读性强的业务编号，不能直接展示自增ID。我建议的生成规则是“日期+业务代码+流水号”，比如挂号单号生成规则是REG20250601001，含义是2025年6月1日第一笔挂号。

实现时要注意并发问题。如果直接用“查最大编号+1”的方式，在高并发下会重复。更稳妥的做法是借助数据库的唯一约束：生成编号时带时间戳到秒，理论上同一秒内并发生成时会撞号。实际毕设场景并发量很小，这个方案基本可接受，但更讲究一点的做法是在编号表里记录当天最大流水号，配合事务更新。推荐后者，因为原理和你讲系统设计时有话题聊：

public String generateRegistrationNo() { String datePrefix = LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE); // 从编号流水表获取当天的当前值，并自增1 int seq = sequenceService.nextValue("REG", datePrefix); return "REG" + datePrefix + String.format("%03d", seq); }

5.2 状态流转校验一定要有“守卫”

前面讲过挂号单的状态流转，这里强调代码层面的实现：不要在Controller里判断状态能怎么变。Controller只负责接收参数，调用Service方法，而Service内部要先查询当前状态，再校验目标状态是否合法，不合法直接抛业务异常。

以就诊状态为例：

public void completeDiagnosis(Long registrationId) { Registration reg = registrationMapper.selectById(registrationId); // 只有“就诊中”状态才能变更为“已完成” if (!RegistrationStatus.IN_TREATMENT.equals(reg.getStatus())) { throw new BusinessException("当前状态不可完成就诊"); } // 变更状态并保存 }

这个写法保证每个状态入口都是“有守门员”的，不会出现谁都能改数据的情况。住院状态的推演也是同样逻辑：入院后不能再重复入院，出院后不能继续录入用药记录。

5.3 权限控制：后端校验永远不要偷懒

前端隐藏菜单只是画皮，后端必须做真正的校验。我的做法是定义一个自定义注解，比如@RequireRole("doctor")加到Controller方法上，然后用Spring MVC的拦截器或AOP做统一校验。这样每个接口只要一行注解就能完成权限控制，整洁。

如果用的是Sa-Token框架，它内置了@SaCheckRole注解，直接在接口上标注即可。示例：

@SaCheckRole("doctor") @PostMapping("/diagnosis") public Result<?> createDiagnosis(...) { ... }

这里有个细节：角色名建议用常量定义，别在注解里写字符串裸奔。写错了排查起来很痛苦，统一用常量引用能避免很多低级bug。

5.4 简易的疫苗/复诊提醒

宠物医院系统天然有“提醒”业务场景：疫苗到期提醒、定期复诊提醒。做日历式的复杂提醒调度对毕设来说超纲了，我建议用“被动触发式”实现：在系统首页设置一个待办提醒面板，登录后自动查询未来7天内需要接种疫苗或复诊的宠物列表并展示出来。

实现原理很简单：宠物档案表有“下次疫苗日期”字段，挂号单有“建议复诊日期”字段，查询时用BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 7 DAY)过滤。不需要定时任务，不需要消息队列，但效果直观，用户一打开系统就能看到。答辩如果被问到“提醒功能是怎么做的”，你可以坦然说这是轻量级提醒方案，并且说出它的适用场景和局限，这比背一堆消息中间件名词但没有任何实际代码要可信得多。

5.5 我在调试中踩过的坑

有几个坑是很多人都会踩的，特意列出来，你要是遇到了能少走弯路：

第一个坑是事务不生效。Spring Boot里事务最常见的问题是自调用绕过代理：同一个类里的方法A调方法B，B加了@Transactional但没生效，因为事务代理没介入。解决方法是把需要事务的方法拆到另一个Service类里，或者用AopContext.currentProxy()。出现这个bug的表象是：收费完成后扣库存，如果扣库存抛异常，收费记录居然也已经提交了，数据就脏了。

第二个坑是日期传参格式化。前端传2025-06-01 08:30:00这种字符串，后端用LocalDateTime接收时如果没配置全局日期格式，会直接报反序列化错误。在application.yml里配置好全局格式转换器，或者在前端统一用时间戳传参，二选一，别混用。

第三个坑是跨域问题。前后端分离部署时，后端必须配置跨域。Spring Boot里一个CorsFilter就能解决，但不配的话前端调试会一直报CORS错误，非常打击心态。

6. 调试、部署与答辩准备：让系统真正“跑起来”并撑得住追问

很多同学代码写完了，结果卡在最后一步——本地跑不起来，或者部署到服务器上一堆环境问题。系统能稳定跑起来，是拿高分的基础；系统能经得起追问，是拿高分的保障。这两件事都要提前准备。

6.1 本地调试建议：先把“最小闭环”跑通

我不建议把所有功能开发完再统一自测。最好的节奏是：每完成一个模块，就从数据库到接口到前端页面串一遍最小流程。比如挂号模块做完，就把“新增宠物主 -> 新增宠物 -> 挂号 -> 查看挂号列表”整条链路跑通，再进入下一个模块。

自测时尽量用Postman或Apifox把接口测一遍。注意几个高频返回错误：404是路由写错，500要看全局异常日志，参数校验失败会返回400或自定义的校验错误信息。每一步测试通过后再继续，最后整个系统联调时你会轻松很多。

6.2 部署发布：服务器上跑Spring Boot其实不复杂

有条件的话，建议把系统部署到一台云服务器上，答辩时直接展示线上地址，加分不少。实际上部署Spring Boot后端非常简单：

# 1. 打包（跳过测试可以节省时间） mvn clean package -DskipTests # 2. 上传jar包到服务器 # 3. 后台启动 nohup java -jar pet-hospital-0.0.1.jar --spring.profiles.active=prod > out.log 2>&1 &

MySQL也装在服务器上，导入SQL脚本即可。前端如果也是Vue项目，执行npm run build生成dist目录，用Nginx托管，同时配置反向代理把/api前缀转发到后端的8080端口。

这里有一个毕设同学特别容易忽略的点：文档里的接口地址、数据库连接配置要和线上环境一致。我见过一个同学演示的时候，代码里连的还是本地数据库，演示时一登录就报错，场面非常尴尬。如果上线了，就把配置文件里的数据库连接改成服务器地址，并确保线上库导入了完整测试数据。

6.3 答辩前的自检清单

答辩前建议按下面这份清单过一遍：

• 整个流程能完整走通吗？从新增客户、挂号、看诊开药、收费扣库存，到住院出院、统计报表，每个环节都点一遍。
• 权限控制验证了吗？用医生账号访问管理员的删除接口，确认会被拦截。
• 异常路径验证了吗？比如挂号单重复点击提交会怎么样，库存不足时开处方能不能被阻断。
• 界面是否有基本的美观度，菜单名称是否规整，没有“测试”“aaa”这种临时数据残留。
• 数据库里的演示数据是否足够丰富，最好有几十条宠物档案、药品、挂号单，数据太少演示起来显得很空。

6.4 那些答辩经常被追问的问题

提前想清楚这几个问题的答案，比背诵项目代码有用得多：

“为什么选Spring Boot？”答案不是“大家都用”，而是“简化配置、内嵌容器、生态成熟、快速构建独立应用”。如果再被追问对比SSM，你要能说出Spring Boot在自动配置和起步依赖上的区别。

“这个系统怎么保证数据一致性？”把收费扣库存、退费回补库存这两个场景说清楚，说明白事务机制，就足够有说服力了。

“如果上线了，你觉得哪里还能优化？”准备好一两个真实可行的优化方向，比如引入Redis做验证码缓存、用定时任务做疫苗到期主动通知、分页查询改为按日期范围分区。注意一定要说“我确实想过”，而不是“我觉得哪里都行”。

我和一位同学合作时聊到过这个问题，他当时想了想说“想给医生端加一个移动端页面”，虽然实现很粗糙但至少证明他思考过扩展方向。这种表达比什么都答不上来好得多。

7. 结语：这个项目的价值不只在于“能答辩”

每次有同学问我毕设到底应该怎么选，我都会说同样的观点：选题的决定你开发体验的上限，也决定答辩分数的下限。宠物医院管理系统这个题目，最舒服的地方在于它的业务复杂度恰好落在“有挑战但不至于失控”的区间——你既能展示Spring Boot全家桶的运用能力，又能展示数据库设计、权限控制、业务状态机这些真实项目里才用得上的设计能力，而这些恰恰是评审老师最想看到的东西。

我建议拿到源码之后不要直接下载、把目录丢进编译器就跑。多花两天时间把每张表、每个接口、每条状态流转都过一遍，把项目“变成自己的”，甚至动手改一两个功能：比如给挂号模块加一个挂号上限人数限制，或者给药品模块加一个批号管理。这种改动不仅是给答辩加分——它帮你建立的是完整的业务理解链路，等你真正出去实习、进项目组的时候，会发现这些经验直接就能复用。

别把毕设当任务应付。做一套能跑、好看、有想法的系统，你收获的远不止一个分数。