做宠物医院管理系统这个选题，我是真的有点话想说。每年毕业季都有不少同学来问我："学长，Spring Boot做管理系统还能做出什么新花样？"直到我上手了萌宠宠物医院系统这个项目，才发现医疗业务系统跟普通的CRUD管理系统完全不是一个量级的难度。它不只是挂号、开药那么简单，里面藏着预约调度、病历管理、药品库存联动、多角色权限边界这类硬骨头。这篇就从一个完整项目的角度，把Spring Boot宠物医院系统的设计与实现过程拆开讲清楚，覆盖需求拆解、技术选型、核心模块设计、数据库落地方案，以及我实际开发过程中踩过的坑和总结的经验。
1. 宠物医院管理系统要解决的问题：从需求分析到功能边界确定
1.1 为什么选"宠物医院"这个场景来做系统设计
宠物医院这个场景，天然比超市管理系统、图书馆管理系统复杂几个量级。超市管的是商品和库存，宠物医院管的是一条条活生生的生命。客户带着生病的小猫小狗进门，前台要快速登记，医生要调取历史病历，护士要安排输液留观，药房要根据处方发药，收银台要结算检查费和药费，这一串流程单靠Excel和纸质病历根本跑不起来。
我做了前期调研之后列了一张"痛点清单"，发现很多宠物医院还是半手工状态：病历本用纸质的，查个档案要翻半天柜子；挂号排班靠手写板；药品库存库房管理员自己记，经常出现药架上写着有货、实际库房已经空瓶的情况。宠物主人对就诊流程也不满意，不知道前面还有几个号，也不知道检查报告什么时候出来。
这些痛点翻译成系统需求，就是三条主线：预约与挂号流转、诊疗信息沉淀、药品与收费闭环。系统不需要做得多花哨，但必须让这几个环节的数据在同一条链路里跑通。
1.2 功能边界怎么圈定：不同角色的核心诉求
做毕设最容易犯的错误就是一上来就想着"功能越多越好"，结果做到中期发现业务逻辑互相纠缠，自己都理不清。我的做法是先画角色地图，再把每个角色最关心的操作列出来。
| 角色 | 核心诉求 | 对应功能 |
|---|---|---|
| 管理员 | 管人管数据管配置 | 员工账号管理、基础数据维护、统计报表查看 |
| 前台 | 快速接诊、少出错 | 宠物主人建档、挂号登记、预约排班、收银结算 |
| 医生/护士 | 录入病历快、查病史方便 | 接诊开方、病历管理、检查检验录入、住院留观管理 |
| 宠物主人 | 随时知道宠物情况 | 线上预约、档案查询、费用明细、回访记录 |
功能边界确定之后，我反而砍掉了两个一开始很冲动的想法：一个是即时聊天功能，因为消息推送会引入WebSocket和消息持久化，对毕设周期来说性价比不高；另一个是复杂的会员卡充值体系，这个涉及储值账户、支付渠道对账，复杂度直接爆炸。留下来的核心功能，要能自洽地讲完"从预约到回访"的完整故事。
1.3 业务流程梳理：一条猫瘟诊疗链路引发的思考
把业务流程跑通，我用了一个非常具体的例子来推演：一只3个月大的小猫被主人抱进来，疑似猫瘟。
完整链路是这样的：主人在小程序/公众号上预约 → 前台确认预约并建档（如果没有档案）→ 医生接诊并做猫瘟试纸检测 → 开出止吐针、消炎药和输液方案 → 护士在系统中领药、安排住院笼位 → 前台根据处方单收取费用 → 三天后系统提示进行回访记录。
这个流程走下来，系统需要支撑的核心数据实体就很清晰了：宠物主人、宠物档案、预约单、挂号单、病历、处方单、药品库存单、收费单。每个实体之间都有明确的流转关系。我在设计数据库表的时候，就是照着这个链条一张表一张表推出来的。
2. 技术选型与核心架构：为什么是Spring Boot + MyBatis-Plus
2.1 技术栈的取舍逻辑
关于框架选型，网上争论很多，但我有自己的判断角度：毕设和真实项目不一样，核心目标是"在规定周期内交付一个逻辑完整、可演示、能讲清楚的项目"。Spring Boot在这个场景下几乎是唯一解——生态太成熟了，遇到问题随便一搜都有答案，而且自带Tomcat，打包成jar就能跑，部署演示环境没有那么多幺蛾子。
版本组合我用了Spring Boot 2.7系列（内置Tomcat 9）、MyBatis-Plus 3.5.x、MySQL 8.0，前端用Vue 2 + Element UI来做管理后台。选MyBatis-Plus而不是原生MyBatis，是因为单表CRUD真的不用手写XML，分页插件也开箱即用，能省下大量重复编码时间。
注意：如果有人建议你上Spring Cloud微服务，先冷静想一下。宠物医院系统的业务体量根本不需要拆服务，引入Nacos、Feign、Gateway只会徒增部署复杂度，答辩的时候还容易被追问"服务拆分的依据是什么"，答不上来反而扣分。
2.2 后端工程的包结构与职责划分
工程结构我按照经典的分层架构来组织，但包名做了一点调整，力求"一眼看懂业务归属"：
com.pethospital ├── controller（接口层，只做参数接收和结果封装） ├── service（业务层，处理核心业务逻辑与事务） ├── mapper（数据访问层，MyBatis-Plus的BaseMapper） ├── entity（数据库实体类，与表字段一一对应） ├── dto（数据传输对象，接收前端参数和组装返回数据） ├── vo（视图对象，给前端展示的数据结构） ├── common（全局异常、统一返回体、常量） ├── config（跨域配置、MyBatis-Plus配置、拦截器注册） └── utils（JWT工具、日期工具等）这里有个细节值得展开说：entity、dto、vo三层分离。很多新手图省事，直接用entity接收前端参数，结果发现密码字段暴露、表结构变更牵连接口出问题。我给宠物主人查询接口单独写了VO，只暴露宠物名字、品种、年龄、免疫状态这些必要的字段，敏感数据全部挡住。
2.3 统一返回体与全局异常处理的设计思路
一个管理系统的接口少说也有几十个，如果每个接口都各自为战返回数据，前端联调的时候会疯掉。我封装了一个统一的返回结构：
public class Result<T> implements Serializable { private Integer code; // 200成功，非200为各类异常 private String msg; // 提示信息 private T data; // 数据负载 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String msg) { Result<T> result = new Result<>(); result.setCode(500); result.setMsg(msg); return result; } }全局异常处理用@RestControllerAdvice统一拦截，业务异常、参数校验异常、数据库异常分别映射到不同的code。这样前端只需要判断code是否为200即可，不用每个接口都做一次异常分支处理。这个设计虽然看起来简单，但是"规范性"的影子很浓，在答辩时是一个很不错的加分点。
3. 核心功能模块的落地细节与数据库设计要点
3.1 七张核心业务表的设计思路
数据库设计是管理系统项目的灵魂。我把核心表拆成"三主表 + 四业务表"的结构：
- 主数据表：宠物主人表、宠物档案表、员工表
- 业务流转表：预约挂号表、诊疗病历表、处方明细表、收费记录表
- 支撑辅助表：药品库存表、库存流水表、回访记录表、系统公告表、轮播图表
宠物档案表是核心中的核心。我给它设计了这些字段：宠物名称、品种、性别、绝育状态、生日、毛色、体重、疫苗记录（用JSON字符串存储，因为接种针次不固定）、过敏史、建档时间。疫苗记录用JSON而不是单独建表，是权衡之后的结果，因为毕设阶段不需要按"某种疫苗"做统计检索，这样设计能少一张关联表和一个维护界面。
这里重点提一下逻辑外键。我不建议在物理层面加外键约束，理由是：MyBatis-Plus做联表查询用业务代码关联足够，物理外键在删除数据时容易被约束卡住，演示环境里清理脏数据会非常痛苦。逻辑上保持字段语义清晰（比如doctor_id字段存的是员工表主键），程序里保证引用关系，即可满足需求。
3.2 预约挂号模块的并发陷阱与状态机设计
预约挂号是医疗系统里最容易出问题的模块，因为它涉及到"号源数量"这个临界资源。举个实际例子：某个早上医生排了20个号，如果两个宠物主同时提交预约申请，程序会不会把第21个号也发出去？
我处理方式是两张表联动：排班表（doctor_schedule）记录医生某天可接诊的总号和已用号数，预约表存储预约记录。预约接口的执行顺序设计如下：
- 根据医生id和日期查询排班记录，判断已约数量是否小于总号数
- 如果可约，先更新排班表的已约数量加1（这一步放在事务里）
- 再插入预约记录
这里的关键是第二步和第三步必须放在同一个事务里，并且用乐观锁思想检查更新行数。MyBatis-Plus的UpdateById默认不带条件更新，我直接写了自定义SQL：
<update id="increaseBookedCount"> UPDATE doctor_schedule SET booked_count = booked_count + 1 WHERE id = #{scheduleId} AND booked_count < total_count </update>如果update返回0，说明号已经被抢完了，直接抛业务异常"该时段已约满"。这种方式比先select再update更安全，因为数据库层面的行锁天然保证了并发下不会超卖。做完这个模块，我可以很自信地说"在单应用部署场景下，这个方案是扛得住并发冲击的"。
3.3 病历与处方模块：复杂业务的分步落库
病历模块是医生端每天都要用的功能，录入体验直接决定系统会不会被真正使用。处方单设计成了主从结构：主表记录就诊基本信息（宠物、医生、诊断结果、病情描述），从表记录药物明细（药品id、单次剂量、频次、天数、数量、用法说明）。
提交处方时，我用@Transactional来保证原子性，并且在事务里同时扣减药品库存。这里的核心逻辑是：库存表要同时满足"发药时扣减库存"和"退药时回补库存"两个方向的操作，所以库存变动我单独建了一张流水表，每次扣减都插入一条version记录。这样如果药品数据对不上，可以通过流水表追溯到每一次操作。
关于药品信息，常见药品（猫三联疫苗、体内驱虫药、消炎药、止吐针剂等）我用枚举维护了默认用法和剂量参考，医生开方的时候可以一键带入，再按实际情况微调。这个设计是某宠物医院的前辈给的灵感——系统不要给医生增加负担，能默认的就默认，能少打字就少打字。
3.4 权限体系设计：管理员、医生、护士、前台的最小化权限
宠物医院系统的角色权限比一般系统更细，因为医疗数据属于敏感信息，前台不应该能修改病历，护士也不应该能改药品价格。我使用Spring Security + JWT的组合，但没用Spring Security那套复杂的过滤器链配置，只取了它的核心能力来做登录认证和接口鉴权。
具体实现上，自定义了一个JwtAuthenticationFilter，放在Spring Security过滤器链中。每个登录用户携带token请求时，过滤器解析出userId和角色，放进SecurityContextHolder。在需要限制角色的接口或者方法上，我使用@PreAuthorize("hasRole('ADMIN')")这类注解来控制访问。
@PostMapping("/medical-record") @PreAuthorize("hasAnyRole('DOCTOR', 'ADMIN')") public Result<Void> saveMedicalRecord(@RequestBody MedicalRecordDTO dto) { // 只有医生和管理员能写病历，护士和前台只读 medicalRecordService.saveRecord(dto); return Result.success(null); }前端渲染时再根据登录用户角色，动态控制菜单和按钮的展示。双端校验是必须的——只做前端控制等于没设防，懂技术的人直接调接口就能绕过。
3.5 数据统计模块：用图表把业务故事讲完整
毕设项目如果能有一块数据可视化的仪表盘，整体观感会提升一个档次。我做了四个维度的统计：本周预约趋势（折线图）、各科室接诊占比（饼图）、药品消耗排行（柱状图）、月度营业额趋势（折线图）。
统计接口的核心不是前端图表库选什么，而是SQL怎么聚合。举个例子，月度营业额需要按天GROUP BY，但订单表的支付时间存的是datetime格式，需要先用DATE_FORMAT格式化再分组：
SELECT DATE_FORMAT(pay_time, '%Y-%m-%d') AS day, SUM(amount) AS total_amount FROM payment_order WHERE pay_time BETWEEN #{startTime} AND #{endTime} GROUP BY DATE_FORMAT(pay_time, '%Y-%m-%d') ORDER BY day服务端只返回聚合好的数据，前端用ECharts渲染。这里不建议前端拿到明细数据自己聚合，一方面数据量大时接口响应慢，另一方面SQL聚合的写法在答辩时也是一个能拿出来讲的"专业细节"。
4. 开发联调中的关键配置与踩坑实录
4.1 MyBatis-Plus的逻辑删除：一个容易忽视的坑
我在设计时给大部分业务表都加了逻辑删除字段（deleted），用MyBatis-Plus的@TableLogic注解来管理。这个方案很优雅，删除操作自动变成update，不用每次手动拼条件。但踩了一个坑：如果表里有业务字段的唯一约束（比如员工的手机号），逻辑删除后再次插入相同手机号的记录，数据库会报唯一键冲突。
原因是逻辑删除的记录依然占着唯一索引的位置。解决办法就是把这个唯一约束从"单字段唯一"改成"字段+deleted联合唯一"，但这样又会导致同一手机号被多次逻辑删除后无法再次插入。我最终的处理方式是在插入之前先检查是否存在未删除的同名记录，如果存在未删除的同一条直接返回提示，存在已删除的就先物理清除那条逻辑删除的记录再插入。这是很"脏"的解决办法，但胜在落地有效。
4.2 跨域、时间格式、金额精度：三个零碎但致命的问题
这三个问题每一个都能卡掉半天开发时间，而且初学者经常踩。
跨域问题：前端跑在8080端口，后端跑在9090端口，不同端口就是跨域。我在config包下写了一个全局跨域配置类，实现了WebMvcConfigurer的addCorsMappings方法：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }时间格式：A端（医院后台）用的LocalDateTime在Java端的默认序列化格式是"2025-06-12T10:30:00"，但前端Element UI组件需要的是"2025-06-12 10:30:00"。统一处理方案是写一个Jackson配置类，全局定义LocalDateTime的序列化格式。千万不要在每个VO的日期字段上单独加注解，那是治标不治本。
金额精度：涉及钱的数据一律用BigDecimal，不用double和float。double计算0.1+0.2会变成0.30000000000000004，这种错误出现在医疗收费场景是不可接受的。MyBatis-Plus映射BigDecimal到MySQL的DECIMAL(10,2)字段类型，配合前端输入框限制两位小数，基本能杜绝精度问题。
4.3 JWT登录失效与拦截器放行资源的不当配置
我在做拦截器的时候曾经犯过一个很蠢的错：把所有静态资源路径都拦截了，结果前端登录页的CSS和JS都加载不出来，白屏半天排查不出原因。后来才想起Spring Boot的默认静态资源路径是/static/**下的文件，这些请求路径要直接放行。
JWT还有一个容易忽略的细节：用户改了密码之后，旧的token仍然有效，因为JWT本身是无状态认证，服务端没有存储token的状态。解决思路是在用户表加一个tokenVersion字段，每次修改密码或管理员封禁账号时都自增版本号，生成JWT时把版本号作为claim之一，每次请求校验时对比版本号是否一致。这个方案不完美但实用，比引入Redis存储token过期状态简单得多。
4.4 文件上传的本地存储与访问映射
宠物档案可以上传头像，检查报告可以传PDF。文件上传看似简单，但有两个点很容易踩：一是保存路径必须是绝对路径，二是前端要通过URL访问到这些文件。我的处理是在application.yml中配置上传路径变量：
pethospital: upload-path: /data/pethospital/upload/然后写一个WebMvcConfigurer把本地上传目录映射成虚拟路径/userfiles/**，这样前端就能直接通过http://ip:9090/userfiles/xxx.jpg访问图片。虽然这只是开发环境方案，生产会换OSS对象存储，但毕设阶段完全够用了。
5. 开发过程中的排期规划、演示准备与设计文档的最后一公里
5.1 五周完成项目的时间分配建议
很多同学做毕设拖到最后一个月才上线，根因在于排期规划不合理。根据我实际的开发节奏，建议按这个比例分配时间：
| 阶段 | 时间占比 | 核心任务 |
|---|---|---|
| 需求梳理与数据库设计 | 15% | 画用例图、业务流程图，确定表结构 |
| 后端基础框架搭建 | 15% | Spring Boot工程初始化、统一返回体、全局异常、JWT登录 |
| 核心业务模块开发 | 40% | 预约、挂号、病历、处方、药品、收费逐模块实现 |
| 前端页面联调 | 20% | Vue页面开发，与后端接口联调 |
| 测试、演示数据、设计文档 | 10% | 功能测试、模拟数据生成、论文/说明书写作 |
我实际走下来，最容易被低估的是"造演示数据"这件事。空数据库跑出来的系统，表格全是空的，图表也没有曲线，演示效果非常干瘪。建议把演示数据覆盖到3个医生、5个前台/护士、8个宠物主人、15只宠物、超过30条就诊记录，这样无论从哪个入口点进去，界面都是满的、有故事的。
5.2 演示环境的部署优化：从本机到服务器的移植
演示环境是答辩当天最容易翻车的环节，我建议提前把系统部署到一台服务器上（阿里云/腾讯云的学生机即可），不要依赖本机演示。部署步骤整理一下：
- 打包后端项目：
mvn clean package -DskipTests，生成jar包 - 安装JDK 8/11和MySQL 8.0，用
scp把jar和SQL初始化脚本传到服务器 - 导入数据库：
mysql -u root -p < init.sql - 后台运行jar：
nohup java -jar pethospital.jar --spring.profiles.active=prod &
这里有一个坑是服务器内存。学生机一般2G内存，Java应用加MySQL很容易内存吃紧。我调整了JVM参数来适配：
nohup java -Xms256m -Xmx512m -jar pethospital.jar同时MySQL配置里把innodb_buffer_pool_size调小到64M，两者加起来才能稳定运行。前端打包之后用Nginx托管，并配置反向代理把/api开头的请求转发到后端服务的9090端口。
5.3 设计文档写作的干货：不只是项目的说明书
毕设的设计文档不能写成"系统功能介绍"，要有技术深度。我的写作思路是"问题驱动"：每章先提出一个项目经历中的真实问题，再给出解决方案和对比分析。
比如在架构设计章节，我写了"为什么选择单体架构而非微服务架构"的分析对比；在数据库设计章节，我详细描述了"排班并发扣减号源的方案选择"，并且对比了悲观锁和乐观锁的异同。这些内容不需要多高大上，只要展示出你是真的思考过、比较过，就有区分度。
答辩常被问的几个问题，提前准备好回答思路：项目最大的难点是什么、如果用户量变成100倍怎么扩展、某张表的设计依据是什么、为什么选择这个技术栈。这些问题的答案其实都已经包含在开发过程里了，重要的是能不能用清晰的逻辑串出来。
5.4 项目未来功能的扩展思考与优化方向
如果项目后续要继续完善，或者被问到"系统如何进一步提升"，有几个方向是可以讲的：
- 引入消息队列（比如RabbitMQ）来做预约成功的短信通知，削峰填谷，防止高并发下短信API被频繁调用
- 引入Redis缓存热点数据，比如医生排班信息、药品库存数量，减少数据库压力
- 引入定时任务框架，实现"超过24小时未到诊自动取消预约"和"库存低量自动提醒采购"
- 增加电子处方签名功能，让医生手写板签名保存到处方单上，更贴近实际业务场景
这些扩展方向不需要全部实现，但准备在文档的总结章节，能体现你对自己项目的完整思考。
做完整个项目，我最大的感触是：毕设项目真正考验的不是技术炫技，而是能不能把需求梳理清楚、把流程跑通、把细节做好。你花在业务流程图上的时间，最终都会在开发效率上还给你；你提前想清楚的每一个状态流转，都会让你在联调阶段少掉一大把头发。如果你也正要动手做一个Spring Boot管理系统项目，希望这篇拆解能给你一张清晰的地图。按着模块一步步走，会发现宠物医院系统远比你想象的更有意思——毕竟每一条就诊记录背后，都是一只努力撒娇的小生命。
