每年毕设季，宠物医院管理系统几乎都是那几个“常青树”选题之一。这个题不算新，但年年有人选，自然有它的道理。SpringBoot + MySQL + MyBatis这套组合，覆盖了一个完整业务系统的所有核心环节：数据建模、接口设计、权限控制、前后端联调、部署上线。做完这一套，你对“一个系统是怎么从零搭起来的”基本就有完整认知了。这篇就从选题、技术选型到核心设计与避坑，一条线讲清楚。
顺便说一句，网上大量资源打着“附源码、数据库、万字文档”的旗号，但拿到手之后跑不起来、文档胡编、数据库表都对不上号的情况真心不少。所以我这篇不光拆解系统本身，也会把“拿到一套毕设代码之后怎么跑起来、怎么改、别人问起来怎么答”这些实操经验一并写了，争取让我踩过的坑你不要再踩一遍。
1. 选题定位与需求拆解：宠物医院管理系统到底在做什么
1.1 这个选题为什么“香”
很多人觉得宠物医院系统烂大街、没新意，但从毕设选题的角度来看，它几乎是完美的。
第一，业务规模适中。宠物医院是典型的“小体量、多角色、全流程”场景，既不像进销存系统那样纯做数据管理，也不像电商系统那样要面对高并发和复杂支付，但整个业务链路非常完整：客户建档、宠物档案、挂号预约、医生就诊、病历处方、药品开单、商品销售、收费结算，这一套往下走，几乎覆盖了传统MIS系统（管理信息系统）的所有核心功能模块。
第二，角色权限天然清晰。系统里有管理员、前台、医生，可能还要一个客户视角。这样权限管理模块就能落到实处，而权限控制又是答辩时最容易被追问的点。你要是做的是一个没有角色区分的“普通管理系统”，老师的兴趣会低很多。
第三，技术栈适配性强。SpringBoot + MySQL这套组合，既能体现你对主流企业级开发框架的掌握，又不会因为技术太偏门而给自己挖坑。后期想加分，还能往上加Redis缓存、JWT登录、微信小程序端、ECharts统计报表——这些都是有现成方案的，扩展空间够大。
第四，数据量级好控制。宠物医院的病历、挂号、处方数据不会像电商订单那样动辄几十万条，所以不需要搞分布式事务、消息队列这些重型方案，一个单体SpringBoot应用加几张设计合理的表，完全能撑住全部业务。这跟毕设的体量要求刚好匹配。
1.2 业务痛点与模块划分：先想清楚再写代码
很多同学拿到题目直接开写，写到一半发现表结构设计得乱七八糟，到处加字段打补丁。我建议做任何管理系统之前，先站在使用者角度把痛点摸清。
传统宠物医院的信息管理痛点有三个最明显的地方：一是宠物档案和病历靠纸质本子，宠物换医院之后之前的病历全丢；二是挂号排队靠前台人工喊，医生工作量不透明；三是药品库存和收费对不上，月底盘点的时候一片混乱。
所以一套合格的宠物医院管理系统，至少要包含这些模块：
- 系统登录与用户管理：管理员、前台、医生三种角色，不同角色看到不同菜单
- 客户与宠物档案管理：一个客户可以养多只宠物，宠物要有品种、年龄、体重、疫苗记录等基础信息
- 挂号与就诊管理：前台为宠物挂号，选择科室和医生，医生接诊后更新状态
- 病历与处方管理：医生写病历、开处方，处方关联药品和用量
- 药品库存管理：药品入库、出库、库存预警
- 收费与订单管理：前台根据处方或商品订单进行收费结算
- 统计看板：收入统计、挂号量统计、药品消耗统计（这个模块是老加分项）
模块之间是有依赖关系的：客户要先建档，宠物才能挂到客户名下；宠物要先挂号，医生才能写病历；病历里开了药，药店库存要扣减，前台才能收费。这个“数据流”走通了，系统的骨架就立住了。
我强烈建议在动手写代码之前，先把角色→功能→页面→数据表的映射关系画在一张纸上。哪怕画得丑，自己心里有数，后面写代码的速度比直接摸黑写快一倍不止。
2. 技术选型与工程结构：SpringBoot版本的坑与好方案
2.1 为什么是SpringBoot，以及版本怎么选
现在的毕设环境里，SSM（Spring MVC + Spring + MyBatis）已经基本退出历史舞台了，SpringBoot是绝对的主流。原因很实在：SpringBoot把配置从XML里解放了出来，内嵌Tomcat，Jar包一键启动，同时仍然保留了Spring生态的依赖注入特性。
但是SpringBoot版本选择是个大坑。我实测和各种群里得到的信息是，选SpringBoot 2.7.x配JDK 8，是答辩环境最稳的组合。
有同学看到官网已经出SpringBoot 3.x，觉得学就要学最新的。实话告诉你，SpringBoot 3.x要求JDK 17起步，很多学校的实验机器、机房环境、甚至有的同学自己电脑上装的都还是JDK 8，版本不符直接启动报错。另外一个很现实的问题是，网上大量现成的教程、视频、博客代码都是基于2.x写的，你用3.x去跑，一些底层API已经变了，报错的时候搜不到对应的解决方案，心态很容易崩。
如果你非要用高版本，也请务必先确认三件事：JDK版本满足要求、数据库驱动版本匹配、依赖坐标不要缺。但我的建议就一句话：毕设求稳不求新，2.7.x + JDK 8 + MySQL 8.0 就是这个项目的最优解。在文档的“技术选型”章节，你还能顺带写一段“为什么不用SSM而选择SpringBoot”，这也是加分点。
2.2 数据访问层：MyBatis-Plus是省心之选
数据访问层这个选择题很关键。原生MyBatis写起来太繁琐，每写一个查询都要配一堆XML；Spring Data JPA虽然全自动，但很多人学不明白它的方法名解析规则，复杂查询时SQL都不好控制。MyBatis-Plus在此基础上做了增强，单表CRUD几乎不用写SQL，自带分页插件，逻辑删除、自动填充这些功能也是开箱即用，空余时间还能让你把精力多放在业务逻辑上。
不过要注意，MyBatis-Plus的强项在单表操作，多表关联还是老老实实写自定义SQL。我在设计时有个经验原则：简单的增删改查交给BaseMapper内置方法，涉及报表统计、多表联查的，写@Select注解SQL或XML映射文件。这样既省代码，又能在答辩的时候跟老师讲清楚“我哪部分用了框架封装、哪部分是自己写的SQL，为什么这么取舍”。
另外提一下代码生成器。用MyBatis-Plus的AutoGenerator可以根据数据库表一键生成entity、mapper、service、controller，能省很多体力活。但建议生成的代码要再过一遍，因为自动生成的字段命名可能和业务语义对不上，生成器也不是每次都能准确把下划线转驼峰处理干净。毕设源码里如果带一套自己整理的、能说清楚来龙去脉的实体类，比纯自动生成要加分。
2.3 前后端方案：模板引擎够了，别给自己加戏
这个系统我推荐用Thymeleaf模板引擎做服务端渲染，配合AdminLTE或Layui这一类后台管理模板，就能做出很体面的管理界面。很多同学一上来就想搞前后端分离，Vue + Element UI + SpringBoot做接口。我理解这种“想展现完整技能栈”的心理，但如果你的核心目标是稳定通过答辩，模板引擎方案有明显的优势：
- 开发链路短，不用单独启动前端工程，不用处理跨域问题
- 页面结构直观，答辩演示的时候直接输地址就能看到完整页面
- 源码体积小，评审老师看起来也轻松
- 登录状态管理直接走Session，不用为了JWT而去处理Token过期、刷新这类额外问题
当然，如果你学有余力，或者导师明确建议用前后端分离，那也不拦着。只是到时候要多操心跨域配置、前端打包部署、接口鉴权这几件事，时间成本是实打实的。我这里讲的是大多数情况下更稳的方案：Thymeleaf渲染页面 + 简单的Session登录拦截器 + 统一返回Result对象给接口用。
一个常见的工程结构大概长这样：
src/main/java/com/pethospital/ ├── config/ // 配置类：拦截器、WebMvcConfig ├── controller/ // 控制层 ├── service/ // 业务层（接口 + 实现类） ├── mapper/ // 数据访问层 ├── entity/ // 实体类 ├── common/ // 通用返回结果、异常处理、常量 └── PetHospitalApplication.java src/main/resources/ ├── mapper/ // MyBatis XML文件 ├── templates/ // Thymeleaf页面 ├── static/ // 静态资源 └── application.yml // 核心配置这个包结构不是唯一的答案，但胜在清晰，每个文件放哪里都有明确规矩，后期查问题、加功能都很顺手。
3. 核心模块设计与实现思路：把业务讲成一条完整的线
3.1 数据库设计：表别乱建，先理关系
数据库是毕设项目里最容易被看“门道”的地方。表的数量、字段的设计、主外键关系，老师翻几眼就能判断你是认真设计了还是随便糊弄。宠物医院管理系统的核心表，我按业务主线给大家缕一缕：
- 客户表（owner）：客户ID、姓名、手机号、地址、备注
- 宠物表（pet）：宠物ID、客户ID（外键）、昵称、品种、性别、体重、年龄、疫苗信息、创建时间
- 用户表（sys_user）：用户ID、账号、密码（MD5加密）、真实姓名、角色（管理员/前台/医生）、科室
- 挂号表（appointment）：挂号ID、宠物ID、医生ID、预约时间段、状态（待就诊/已接诊/已完成/已取消）、症状描述
- 病历表（medical_record）：病历ID、挂号ID、宠物ID、诊断结果、病情描述、处理方案、创建时间
- 处方表（prescription）：处方ID、病历ID、药品ID、开药数量、用法用量、金额
- 药品表（drug）：药品ID、药品名称、规格、单位、库存量、进价、售价、预警阈值
- 商品表（product）：商品ID、名称、分类、售价、库存
- 订单表（sale_order）：订单ID、订单号、客户ID、总金额、订单状态、创建时间
- 订单明细表（sale_order_item）：明细ID、订单ID、商品ID、数量、单价、小计
这里每一张表的存在都是有业务依据的，并不是为了凑表数。一个特别关键的设计：宠物表为什么要单独建，而不直接塞在客户表里？因为一个客户可以养多只猫狗，如果设计成客户表里加一个“宠物名字”字段，那同一客户养三只宠物就要建三条客户记录，手机号地址全部冗余，这就在答辩时给老师递上了“数据结构设计能力不足”的把柄。一对多的关系，一拆，整个设计就合理了。
药品库存和订单明细这两个地方，我建议加个乐观锁字段。虽然毕设项目本身不会有高并发，但你用乐观锁去解决超卖问题，答辩被问的时候，讲出来的深度完全不一样。
3.2 挂号就诊流程：用状态字段把流程串起来
宠物医院系统里，最容易写成一团浆糊的就是挂号→就诊→病历→处方这一条流程。很多人把所有信息都堆到一张表里，前面选挂号、后面加病历，最后字段越来越多，逻辑越来越乱。
正确的做法是用挂号表的状态字段来控制流程流转：
- 前台创建挂号记录，状态为“待就诊”，同时记录宠物ID和医生ID
- 医生登录后看到分配给自己的待就诊列表，点击“接诊”，状态变为“已接诊”
- 医生填写病历和处方，操作完成后状态变为“已完成”
- 如果客户临时不来，前台可以做“取消”操作，状态变为“已取消”
状态不搞复杂设计，Int字段存状态码就行。比如0-待就诊、1-已接诊、2-已完成、3-已取消。前端根据状态码渲染不同的标签样式，后端在update的时候判断当前状态是否合法。比如已完成之后不允许再次置为待就诊，这就叫状态机校验。这套思路写进文档，再画一张简单的状态流转图，是答辩拿分点。
我建议你至少写一个Service层的单元测试或一个调试页面，去验证“正常就诊流程的五个步骤”是否能按顺序跑通。这个流程如果能完整走下来，整个系统就通了至少七成。
3.3 权限控制与常用业务逻辑
权限控制很多同学只写到“登录拦截器判断有没有session”，这远远不够。结合前面的设计，我建议按下面的颗粒度来做：
- 后端写一个登录拦截器，拦截所有需要登录的URL
- 在拦截器里判断当前用户角色，如果访问了超出角色的接口，直接返回403页面
- 前端菜单按角色动态渲染，比如医生看不到报表统计，前台看不到医生管理菜单
- 管理员拥有所有权限
SpringBoot的拦截器实现起来很简单，写一个HandlerInterceptor的实现类，在preHandle方法里从Session取用户，取不到就重定向到登录页，然后注册到WebMvcConfigurer里。只要把这个讲清楚，权限这块就过关了。
再讲一个实际写代码时的细节。药品扣库存的操作一定要放在事务里，并且先检查库存充足再扣减。伪代码大概是：
@Transactional public boolean createPrescription(MedicineOrderDTO dto) { Drug drug = drugMapper.selectById(dto.getDrugId()); if (drug.getStock() < dto.getQuantity()) { // 提示库存不足 return false; } drug.setStock(drug.getStock() - dto.getQuantity()); drugMapper.updateById(drug); // 插入处方记录 return true; }这里用@Transactional保证“扣减库存”和“新增处方记录”要么都成功，要么都失败，避免出现处方开了但库存没扣、或者库存扣了但处方没记上的数据不一致问题。这份代码逻辑看起来简单，但确确实实是很多同学会漏掉的。
完整可参考的表关系速查
| 主表 | 关联表 | 关系说明 |
|---|---|---|
| owner（客户） | pet（宠物） | 一对多 |
| pet（宠物） | appointment（挂号） | 一对多 |
| appointment（挂号） | medical_record（病历） | 一对一 |
| medical_record（病历） | prescription（处方） | 一对多 |
| drug（药品） | prescription（处方） | 多对多（通过处方明细表） |
| product（商品） | sale_order_item（订单明细） | 多对多（通过订单明细表） |
4. 从源码到运行：配置细节与部署实操
4.1 拿到代码之后，先看这几个文件
不管你是自己写的代码，还是从网上拿到的“附源码”项目，第一件事永远不是双击启动，而是先花十分钟过一遍这几个文件：
- pom.xml：看依赖版本是否冲突，尤其是MySQL驱动、MyBatis-Plus、Lombok这三个
- application.yml：看数据库连接地址、账号密码、端口号、Redis地址（如果有）是否对得上
- SQL脚本文件：看是初始化脚本还是完整备份，表名和实体类能不能对应上
- 前端模板的静态资源路径：确认没有引用本地不存在的JS/CSS文件
有一回我看到一个同学拿到的项目，数据库密码写在application.yml里是别人的服务器地址，本地根本连不上，日志一直报Connection refused。他花了半天折腾防火墙，最后发现只是配置文件里的IP没改。这类问题是毕设项目里最常见的拦路虎。你拿任何代码的第一步，就是把配置文件里的环境相关参数全部改成自己本机的。
4.2 本地跑通的完整步骤
我这里给出一套纯本地环境的完整跑通步骤，照着走基本不会卡住：
- 安装并启动MySQL 8.0，记住root密码
- 用Navicat或命令行执行项目里的数据库脚本，创建数据库和表，导入初始数据
- 用IDEA打开项目，等待Maven下载依赖（注意IDEA要配置JDK 8，Maven仓库用国内镜像，否则下载慢到怀疑人生）
- 修改application.yml里的数据库连接、账号、密码
- 运行主类上的main方法
- 浏览器访问 http://localhost:8080 ，看登录页是否正常
- 用系统里预置的管理员账号登录（脚本里一般会写初始账号，注意查看README或文档里有没有说密码是多少）
要特别说一句，网上很多项目里给出的初始密码可能是123456或admin，MD5加密之后存在数据库里，你直接看数据库也能反查出来，但如果用的是不可逆的加密算法，而文档里又没说初始密码，最简单的办法是用系统里的“注册”功能自己造一个管理员账号，或者直接在数据库的sys_user表里insert一条MD5加密过密码的记录。MD5在线工具生成一串，插进去就能登录。
4.3 部署到服务器：加分操作
如果你想把项目部署到云服务器上演示，或者导师要求提供线上访问地址，操作也很简单：
- 服务器装JDK 8和MySQL 8.0
- 把项目打成jar包：在项目根目录执行 mvn clean package -DskipTests
- 把jar包和SQL脚本上传到服务器
- 服务器上先导入SQL，再修改jar里的application.yml或在启动命令中指定外部配置
- 执行 java -jar pet-hospital.jar 启动服务
推荐用宝塔面板做环境管理和数据库导入，它对小白友好，而且自带进程守护，Java应用崩了能自动拉起。你甚至可以在文档里加一章“Linux环境部署”，这又是加分点。唯一要注意的是，云服务器的安全组必须放行8080端口，不然你本地访问不了。这个问题每年都有人踩：机器上服务起来了，防火墙没开，页面死活打不开，先自查端口。
4.4 application.yml关键配置速查
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/pet_hospital?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl几个关键点解释一下：
- serverTimezone=Asia/Shanghai 是解决MySQL 8.x时区报错的关键，不写的话启动时大概率会报 The server time zone value 'Öйú±ê׼ʱ¼ä' 的乱码错误
- useUnicode=true&characterEncoding=utf8 是为了保证中文数据不乱码
- map-underscore-to-camel-case 开启下划线转驼峰，数据库字段下单划线、实体类用驼峰，它们之间就能自动映射
5. 常见问题梳理与答辩经验：让你少走弯路的压箱底
5.1 环境与启动类问题速查
| 问题表现 | 常见原因 | 解决方案 |
|---|---|---|
| 启动时报程序包不存在或符号找不到 | Lombok插件没装 | IDEA安装Lombok插件，并开启Annotation Processing |
| Application run failed，端口被占用 | 8080端口被别的进程占用 | 改端口，或者杀掉占用进程 |
| 连不上数据库Connection refused | MySQL没启动或IP/端口写错 | 确认MySQL是running状态，检查配置的IP和端口 |
| 中文乱码 | 连接URL没设置编码 | 确保URL里有characterEncoding=utf8，且数据库和表都是utf8mb4编码 |
| Maven依赖下载慢或失败 | 直连中央仓库太慢 | 在maven的settings.xml里配置阿里云镜像 |
| 页面白屏且控制台有404 | 静态资源路径配置不对 | 检查模板里的JS/CSS引用路径，注意上下文路径 |
这里面Lombok的问题特别常见。很多项目的实体类都用了@Data注解，如果你的IDEA没装Lombok插件，编译直接报错，看起来就像系统“缺了一堆类”，其实只要装个插件就能解决。
5.2 代码与数据库层面的经典坑
第一个经典坑是时间字段的默认值问题。MySQL的datetime字段如果设置了CURRENT_TIMESTAMP作为默认值，那你插入记录时可以不传时间字段。但如果你把实体类的时间字段设置为 null 去插入，数据库不会自动替换成当前时间，反而可能因为非空约束报错。解决方式是在插入前由Java代码set当前时间，或者用MyBatis-Plus的自动填充功能配置metaObjectHandler。
第二个经典坑是删除有外键关联的数据。比如你要删一个客户，但客户名下挂了三只宠物，宠物又有挂号记录，直接删会被外键约束拦下来。毕设项目里我建议删除操作统一做逻辑删除，也就是给表加一个deleted字段，删除时update这个字段的值而不是真的delete。这样既避免外键阻塞，又能保留历史数据做追溯。MyBatis-Plus的@TableLogic注解天生就是干这个的。
第三个坑是分页查不出数据。有人写了MyBatis-Plus的分页查询，却忘记配置分页插件（PaginationInnerInterceptor），导致查出来一直是全量数据或分页参数没生效。配置方法是在config里声明一个MybatisPlusInterceptor的Bean，加上PaginationInnerInterceptor。这个配置不写，你的Page对象就只是摆设。
5.3 答辩现场最容易被追问的问题
答辩的时候，老师通常不打代码，而是让你讲清楚“为什么这么设计”。我把高频问题整理了一下，你可以对着自己系统逐个梳理：
- 为什么选SpringBoot？相比传统SSM的优势在哪里？答：自动配置、内嵌Tomcat、起步依赖简化构建、结合Spring生态
- 登录鉴权是怎么做的？答：拦截器 + Session，区分角色权限；如果用了Spring Security或Sa-Token，也要能说清整体认证流程
- 数据库为什么这样设计？哪些表是一对多、哪些是多对多？答：结合客户-宠物、挂号-病历、病历-处方的关系来回答
- 如果客户一次给三只宠物挂号，业务上怎么处理？答：每只宠物单独生成一条挂号记录，通过pet_id区分
- 扣库存的时候并发问题怎么解决？答：乐观锁或事务，防止超卖
- 如果系统要扩展成连锁宠物医院，需要怎么改？答：增加医院表、员工表，业务数据增加医院ID字段，做数据隔离
这些问题都不用背标准答案，你要能结合自己的代码和表结构，用自己的话说明白。真正重要的不是“完美答案”，而是让老师觉得你确实理解了自己做的东西。
5.4 文档怎么写得既充实又不注水
万字的文档不是让你把代码抄进去凑篇幅的。一个合理的文档结构应该是这样的：选题背景与意义、需求分析、可行性分析、系统设计（架构、功能模块、数据库设计）、系统实现（重点模块的截图和核心代码讲解）、系统测试（测试用例和结果）、总结与展望。
其中系统实现部分不要贴整段大代码，而是挑核心的逻辑片段，配上页面截图，讲清楚“这段代码实现了什么功能、为什么这么写”。数据库设计部分一定要有E-R图和数据字典表，字段名、类型、约束、说明都要列清楚。测试部分要写真实的测试用例：输入什么数据、预期什么结果、实际什么结果，宁可写20条简单的也不能编5条虚假的。
文档里还有一个隐藏加分点：把项目的目录结构说明放在前面，让评审老师一目了然。很多老师看项目时是先翻文档再看代码，目录结构讲清楚了，印象分会好很多。我自己当年还把部署过程也写进了附录，老师照着文档就能在自己的电脑上把系统跑起来，这个做法后来被好几个学弟学妹抄走了，反馈都说答辩时老师态度明显不一样。
最后再多说几句实在话
一套毕设做完，最值钱的其实不是那个“优”的评分，而是你办事的经历。
我自己做完这个项目之后最大的体会是：真正花时间的不是写那些增删改查，而是想清楚模块边界在哪、数据怎么流动、每一条约束为什么要存在。比如你设计“挂号状态”的时候如果多花十分钟想一下状态之间的流转规则，后面写代码根本不会写出“已完成的挂号还能再改”这种逻辑漏洞。所以凡是能在纸面上想清楚的东西，尽量不要让代码替你去试错。
还有一个实用到离谱的建议：整个开发过程中要养成随手截图、随手记录的习惯。做了一版页面就截图存好，写完一个模块就写一段总结文字。等最后整理文档的时候，你会发现这些素材都是现成的，不需要在截止日期前三天熬夜编文档。写文档这件事，其实是从开发第一天就开始的。
最后再送一个小技巧：把系统里预置的演示账号密码打印在登录页的注释里，或者写进README根目录。答辩的时候输入账号密码那一下会非常流畅，老师也不会因为找不到初始密码而对你突然产生怀疑。别看这个细节小，实操起来，它能让整场答辩的开场顺很多。
