Spring Boot宠物医院管理系统设计与开发全攻略

1. 宠物医院管理系统这个选题：为什么我推荐它做课设/毕设

做课程设计选题那会儿，我在几个备选方案里反复横跳：网上商城、图书管理系统、宿舍报修平台……最后定下宠物医院管理系统。原因很简单，它的业务场景足够具体，细节足够多，从预约挂号到诊疗开药再到会员充值，天然覆盖了一整套管理系统的常见功能，但规模又没有大到让人望而生畏。用Spring Boot做后端，配合MySQL数据库，加上一点前端页面，正好能撑起一个完整的、有故事线的项目，而不是那种纯粹CRUD的"玩具系统"。

宠物医院管理系统解决的核心问题，是把传统医院的"手写病历、电话预约、现金收费"搬到线上。很多同学做管理类系统容易陷入一个误区，觉得就是几个增删改查的页面拼在一起。宠物医院这个场景不是。它有主档数据（宠物、主人、医生）、动态业务数据（挂号、就诊、处方、收费）、还有状态流转（待就诊、已就诊、已缴费等）。这些数据之间相互关联，写代码之前必须把业务逻辑想清楚，这正是考察系统设计能力的地方。

如果你正在选课设或毕设方向，这个题目的价值在于：一方面它比"图书管理"更有辨识度，答辩时能讲的东西多；另一方面它又不依赖复杂算法，不要求人工智能、大数据那些高深知识，只要把Spring Boot用得扎实，就有机会拿一个不错的成绩。下面我会把这套系统的设计思路、核心模块、数据库方案以及我踩过的坑从头到尾捋一遍，你可以直接照着做，也可以在此基础上换汤不换药地扩展成健身房管理、美容院管理等等。

2. 需求梳理与功能边界：先把角色权限画清楚

2.1 四种角色的职责边界

动手写代码之前，我花了两天时间专门做需求分析。宠物医院和人类医院最大的区别在于"客户"和"患者"是两个人：宠物是患者，主人是客户。所以系统里至少要有以下几个角色：

• 管理员：管理员工账号、查看全院经营报表、维护基础数据（宠物种类、药品目录、服务项目）。
• 前台/收银员：办理宠物建档、接听预约电话或处理线上预约、挂号、收费、办理会员卡。
• 医生/兽医：查看当日挂号列表、填写电子病历、开检查单、开处方、诊断结果录入。
• 客户（宠物主人）：在小程序或网页上预约挂号、查看宠物病历、在线支付。

我在设计时没有把界面做得特别复杂，而是在后端用一个统一登录入口，登录成功后根据角色的权限配置返回不同的菜单和接口。这样做的好处是答辩时你可以清楚地讲出"基于角色的访问控制"，也就是RBAC模型，这是面试官和答辩老师比较看重的一个点。

2.2 功能模块清单，按业务线组织

我最终敲定的功能模块大致如下。这里没有刻意堆砌功能，每个模块都是真实业务里会用到的：

你可能会问"智能"体现在哪儿？在毕业设计的语境下，"智能"不需要做到AI诊断那么夸张。我实现了几处常见功能来呼应主题：一是预约冲突自动校验，同一时间段同一医生不允许重复预约；二是药品库存不足时自动预警，在开处方时提示；三是根据历史收费数据生成简单的日营收报表曲线。这三处功能做出来，系统就已经比普通的管理系统有"脑子"了，而且实现难度适中，不用担心做不完。

2.3 需求分析的输出物

建议你在文档里至少画三张图：一张用例图、一张实体关系图（ER图）、一张系统架构图。这个内容不仅是为了凑字数，更重要的是帮你理清逻辑。我记得我第一次画的ER图里，宠物和主人是多对一关系，但宠物本身没有唯一的身份标识，导致同一宠物在不同医院建档时数据会重复。后来加了"鼻纹编号"或"芯片编号"字段作为唯一标识，这个问题才解决。这种思考过程写在文档里，是很有分量的。

3. 技术选型的理由：Spring Boot为什么是首选

3.1 对比之下我还是选了Spring Boot

现在Java Web领域的课设主流无外乎Spring Boot、SSH（Struts2+Spring+Hibernate）、SSM（Spring+SpringMVC+MyBatis）和原生的Servlet。

• Servlet/JSP虽然简单，但开发效率太低，一个页面跳转要写一堆配置，做不出"系统"的感觉。
• SSH太老，很多新特性都用不上，查找资料还容易搜到过时内容。
• SSM虽然经典，但配置工作量大，光整合各种XML就够喝一壶。
• Spring Boot通过自动化配置和起步依赖，把那些繁琐的配置都干掉了，而且它默认内嵌Tomcat，打成的jar包可以直接运行，部署到答辩现场非常省事。

所以我的建议是：如果你们学校没有强制要求SSM，那请直接选Spring Boot。它也是目前企业里用得最多的框架之一，做完之后写在简历上是能打的。

3.2 MyBatis-Plus与Spring Data JPA的选择

持久层框架我选了MyBatis-Plus，一个很重要的原因是它在MyBatis基础上做了大量增强，单表操作几乎不需要写SQL。比如宠物列表的分页查询，只需要调用selectPage(new Page<>(current, size), queryWrapper)即可，条件构造器用起来也非常顺手。

有的同学用的JPA，它也能做。两者的取舍我给个个人观点：JPA追求的是"对象与表的映射"，适合模型关系复杂、且你很熟悉Hibernate语义的情况，但遇到多表关联查询时，JPQL往往不如直接写SQL直观。MyBatis-Plus的SQL可以完全掌控在xml或注解里，优化起来更直接。课设系统里我会尽量用MyBatis-Plus，因为调试更透明，出了问题你能清楚地看到SQL长什么样。

3.3 中间件组件：Redis和定时任务要不要加

毕设系统的时间有限，我的原则是"非必要不上组件"。Redis我用来做了两件事：一是存储验证码，二是缓存当前登录用户的信息。这个理由足够在答辩时给你加分，但没有把整个业务都依赖在Redis上，避免分布式问题扰乱主业务。定时任务用了Spring自带的@Scheduled，用来每天凌晨生成前一天的营收日报表。这个功能不需要额外引入Quartz，除非你有复杂的任务调度需求。

对于文件上传，比如宠物照片、病历附件，我选择了本地磁盘存储，而不是FastDFS或OSS。理由很简单：开发环境和答辩环境都是在本机演示，本地存储最靠谱。如果有余力，可以写一个简单的虚拟路径映射，把上传目录映射成URL访问，这样前端页面就能直接显示图片了。

4. 数据库设计：把宠物档案和就诊记录串成一条线

4.1 核心表拆解

数据库设计是整个系统的地基。我建了大致如下的表：

• user：用户表，含username、password、role，客户、医生、管理员都在这张表里，通过role字段区分。
• pet：宠物表，含pet_name、species（猫/狗/兔子）、breed、birthday、master_id，关联user表中的客户。
• doctor_profile：医生信息扩展表，含doctor_id、department、title、introduction。
• appointment：预约挂号表，含pet_id、doctor_id、appointment_date、time_slot、status。
• medical_record：病历表，含appointment_id、pet_id、doctor_id、symptom、diagnosis、advice。
• prescription：处方表，关联病历，包含药品明细，可以拆成主表和明细表。
• drug：药品库存表，含drug_name、stock、price。
• charge_record：收费记录表，含record_no、pet_id、amount、pay_type。
• member_card：会员卡表，含card_no、balance、discount。
• operation_log：操作日志表。

这里有个设计细节值得强调：处方和检查项目我拆成了两张明细表。处方（prescription）和处方明细（prescription_item），因为一次就诊可能开出多种药品，如果不拆表，字段就得写"药品1、药品2、药品3"，那非常糟糕，数据不好统计，也无法支持"某种药卖了多少"这类查询。

4.2 挂号状态机的设计

预约挂号不是简单insert一条记录，它有一个状态流转的过程。我定义的状态枚举：

• CREATED：已预约，未到院
• CONFIRMED：前台已确认挂号（到院签到）
• IN_TREATMENT：就诊中
• COMPLETED：已看诊结束
• CANCELED：已取消

每次操作都要判断当前状态是否允许目标状态。比如：只有CREATED状态能取消，已经是COMPLETED的挂号不能再取消。这个逻辑我写在service层，用一个statusChange方法统一处理。答辩时可以重点讲这个状态机，因为它体现了你对业务流程的理解深度。

4.3 逻辑删除、外键和索引的实践

关于外键，我实际建表时没有加物理外键，只加了逻辑外键，也就是在实体关系里体现关联，但没有用FOREIGN KEY约束。原因有两点：一是物理外键在删除数据时容易引发行锁甚至死锁，且测试数据不方便清理；二是很多互联网公司开发规范里也禁用了物理外键，使用应用层保证数据一致性。当然，谈到这个点的时候要能自圆其说，建议在论文里写一句"通过应用层逻辑维护外键关系，兼顾性能与灵活性"。

逻辑删除也是必须的。我给每张业务表加了deleted字段，默认0，删除时执行update而非物理delete。这样做的好处是误删可恢复，更重要的是在查询时统一带上deleted = 0的过滤条件，避免脏数据。

索引方面，主要的查询热点是：预约表按doctor_id和appointment_date联合查询、病历表按pet_id查询、用户表按username查询。所以这三处我建了联合索引或普通索引。不是每个字段都加索引，那反而降低写性能。

5. 核心功能实现手记：从登录到预约看诊

5.1 基于JWT的登录鉴权

登录功能我没有用传统的Session，而是用JWT。流程是：用户提交用户名密码，后端校验成功后生成一个token，包含用户id和角色信息，返回给前端。前端每次请求带上Authorization: Bearer <token>，后端通过拦截器解析token并把用户信息放入ThreadLocal。

有几个细节：

• 密码存储用了BCrypt加密，绝不存明文。你可以在资料包里看到工具类，BCryptPasswordEncoder。
• 设置了token过期时间，比如24小时。过期后需要重新登录。
• 拦截器放行了登录接口、静态资源和Swagger文档路径，其余接口都要校验。

这个方案的好处是前端无需维护Session状态，便于后续扩展小程序端。

5.2 预约挂号的并发冲突校验

这是整个系统里比较考验逻辑的模块。需求很简单：一个医生在某个时间段内只能有一个预约。如果没有并发控制，两个用户同时请求“10月1日上午10点到10点半”的同一医生，就可能都预约成功。

我采用的方案是：在appointment的doctor_id、appointment_date、time_slot上建唯一索引，然后在service里先用selectCount检查是否已存在，再执行insert。如果发生唯一键冲突异常，捕获后返回友好提示"该时间段已被预约"。

再进一步，为了支持"医生排班"，我建了一张schedule表，医生提前设置可预约日期和时间段。前端只展示schedule表中存在的时段。这样避免了用户选择一个医生根本没出诊的时间。

5.3 电子病历与处方生成

医生接诊后在病历页填写病史、症状，下拉选择检查项目，再开出药方。药方明细要实时更新库存：如果药品库存小于处方数量，直接提示"库存不足"。可以补一个事务控制，保存处方和扣减库存必须在一个事务里，失败则整体回滚。这里用的是@Transactional注解，注意某些情况下会失效，比如方法内部调用不走代理时，需要小心。

处方确认后，收费模块自动把检查费和药品费汇总，生成收费记录。这个联动逻辑我认为是你项目中最大的亮点，答辩时一定要讲清楚"数据一致性怎么保证"。

5.4 统计报表怎么实现

我做了两个统计功能：

• 当日营收：按charge_record.create_date分组，统计当日总收入、订单数。
• 科室就诊热度：根据medical_record关联doctor_profile的department字段，统计每个科室的就诊次数。

由于是中小型系统，我直接用MyBatis-Plus的queryWrapper做分组查询，没有用复杂的SQL。一次性加载几十条统计结果完全够用。如果你系统做成大数据量，可以改成定时任务把统计结果写入日报表，牺牲实时性换取性能。课设层面，实时查询即可。

6. 踩坑记录：这些坑我改了整整一晚

6.1 时间字段的时区问题

第一次部署时，发现前端传过来的时间格式与后端相差8小时。原因是MySQL JDBC连接串里没有配置serverTimezone=Asia/Shanghai，而且前端JavaScript里new Date()转换又引入了本地时区。后来统一规范为：所有日期时间传输格式用yyyy-MM-dd HH:mm:ss字符串；数据库的datetime字段存的是不带时区的时间；Java后端用LocalDateTime接收，不转date。这样全局统一就避免了时区陷阱。

6.2 金额字段用Double还是BigDecimal

讲到钱，必须用BigDecimal，不用double。因为double在计算时会丢失精度，比如19.9 + 0.1可能等于20.000000000000004。收费模块只要涉及金额累计、折扣计算，全都用BigDecimal。前端传到后端时用字符串接收，避免精度损失。这个坑在答辩时也经常被老师问到，说出来会显得你很专业。

6.3 FastJson序列化的无限递归

实体之间有多对一和一对多引用，比如Pet里引用了User主人，而User里又有List<Pet>。从数据库查出pet后直接转JSON输出，就会因为循环引用导致StackOverflowError。解决办法是在实体类的标注上使用@JsonIgnore，或者在返回前端时不要直接返回实体，而是返回VO对象。我更推荐返回VO，因为VO可以只留需要的字段，比如给前端返回宠物档案时，嵌入主人的姓名和电话，但不嵌入主人的所有宠物列表。

6.4 文件上传路径的坑

上传宠物照片的时候，我一开始用绝对路径E:/upload，结果换到其他电脑上项目就跑不起来了。后来改成系统属性user.dir拼接相对路径，并且通过自定义静态资源映射，把/upload/**映射到上传目录。代码中不要写死路径，用配置项管理，同时给上传文件加上UUID前缀，防止文件名重复导致覆盖。

6.5 分页查询的常见误区

在MyBatis-Plus中分页需要配置分页插件MybatisPlusInterceptor，不配置的话selectPage只返回所有记录，但total不对。很多新手在这里浪费时间。一定要记得注册分页插件，还要在实体上配置@TableName和@TableId(type = IdType.AUTO)，让主键自增。这些小配置看起来不起眼，少了哪一个都会让功能异常。

7. 关于源码、数据库和文档：怎样把交付物做得更漂亮

7.1 代码目录结构建议

我建议遵循Spring Boot的标准分层：

com.example.pethospital ├── controller // 接收请求，不做业务处理 ├── service // 业务接口 ├── service.impl // 业务实现 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 实体类 ├── vo // 视图对象 ├── config // 配置类 ├── common // 通用返回结果、异常、常量 ├── utils // 工具类

各层职责清晰之后，答辩时老师看代码不会费劲。common里的Result统一封装返回体，包含code、msg、data。所有controller都返回这个格式，让前端处理起来非常舒服。

7.2 数据库文件怎么提供

交付时一定要包含三样：建表SQL、初始数据SQL、数据库设计文档。建表SQL按模块顺序创建，初始数据包括管理员账号、测试医生账号、演示用的客户账号。你可以在资料包里放一个sql目录，用init.sql一次性搞定。初始数据尽量丰富，别只放几条，不然答辩演示时页面空荡荡没说服力。我准备了50多条预约记录、8个医生、20种药品，演示任何页面都有数据支撑。

7.3 万字文档的写作思路

文档结构可以参考：

1. 绪论（背景、意义、国内外现状）。
2. 相关技术介绍（Spring Boot、MyBatis-Plus、Vue等）。
3. 需求分析（用例图、功能需求、非功能需求）。
4. 总体设计（架构图、模块划分、技术架构）。
5. 数据库设计（ER图、表结构）。
6. 详细设计与实现（每个模块的流程图、核心代码、运行截图）。
7. 系统测试（功能测试用例表、性能测试）。
8. 总结与展望。

很多同学在写"详细设计与实现"时喜欢贴大段代码，这是错误做法。正确做法是：先描述业务逻辑，再用一段关键代码解释核心实现，最后贴运行截图说明效果。每章字数均匀，避免头重脚轻。

8. 答辩常见提问与应对思路

答辩老师最喜欢追问的就是"为什么这么设计"，所以你在准备时要把每个设计决定都想好理由。以下是我被问到过或者预料到的问题：

1. 为什么用JWT不用Session？

JWT无状态，适合前后端分离，也方便移动端调用。缺点是token在服务端无法主动失效，所以我在用户修改密码或退出登录时会加入黑名单机制，或者缩短token有效期。你把这个补充说出来，老师会认为你考虑得很周全。

2. 预约冲突怎么处理？

一个是数据库唯一索引兜底，另一个是事务里先查后插。同时说明时间片划分是半小时一个，排班表由医生维护。

3. 数据量大了怎么办？

课程设计通常不会遇到数据量大的场景，但你要能说出思路：分页查询、索引优化、读写分离、缓存热点数据。提几个关键词就行，不要求真实部署。

4. 安全性上做了什么？

BCrypt加密、JWT鉴权、拦截器放行控制、防止SQL注入（MyBatis-Plus的预编译）、上传文件类型校验（只允许图片格式）、日志记录操作行为。能讲出三四点就足够。

5. 如果宠物主人同时有两只宠物来就诊，系统怎么区分病历？

通过pet_id来区分，每次预约都必须选择具体的宠物，挂号单上会显示宠物昵称和主人联系方式。病历记录也挂在宠物名下，主人在小程序里可以切换宠物查看对应历史病历。

我自己在准备答辩时，把这些问题写成了一份两页的提纲，反复熟悉，不用死记硬背，只要把逻辑连通就行。如果你能真的把这套系统从头到尾写一遍，而不只是下载源码跑起来，这些提问基本难不住你。

写在最后的一点个人体会

这套宠物医院管理系统我从需求分析到最终答辩用了大约三周，真正写代码的时间其实两周不到，剩下的时间都在改bug和写文档。最大的收获是：把"看似简单的管理系统"做出深度，靠的不是多加几个页面，而是把数据关系和业务规则想透。比如处方和库存的联动、预约的唯一约束、状态机的流转、金额的精度控制，这些才是体现工程师思维的地方。你在课程设计或毕业设计里拿到的源码和文档都只是起跑线，自己把它跑通、拆开、改一改，才能把这份经验真正变成自己的。哪怕你未来不做Java开发，这种从需求出发、设计数据模型、实现功能、最后交付文档的完整链路，也是任何岗位都用得到的底层能力。