蝨孨槑黽毕业设计选医院门诊信息管理系统的人，十个里面得占四五个。原因很简单：业务够熟、场景够全、体量适中，而且拿Spring Boot来做这个题目，几乎成了计设圈的默认配置。我最近也帮几个朋友把这个题目从头到尾捋过一遍，所以这篇文章就从一个实际能跑通的角度，把系统从技术选型、数据库设计、核心接口实现到后端高频踩坑点，一条线讲透。你如果是拿这个题做毕设，或者想快速搭一套门诊管理后台，可以直接把这里面的表结构和代码思路当参考底稿。
1. 项目落地的第一步：业务边界和技术选型怎么定
1.1 门诊系统到底要管哪些事
很多人在做这个题目时，第一反应是上去就建Spring Boot项目、写Controller。这个顺序其实是错的。做管理类系统，第一件事是把业务边界划清楚，否则代码写一半你会发现需求越来越模糊，表结构改来改去，最后全乱套。
医院门诊的业务流其实是一条非常典型的“主线+支线”模型。主链路就是：患者建档、挂号、医生看诊、开处方、缴费、药房发药。这个流程在真实医院里每天重复几千遍，逻辑非常成熟，搬到系统里就是一张张状态流转的数据库记录。支线则是围绕主链路服务的基础数据，包括科室管理、医生排班、号源维护、药品字典、收费退费、统计报表，还有登录认证和角色权限。
按角色拆一下更清楚：前台护士负责建档和挂号收费，医生负责看诊和开方，药房人员负责发药和库存管理，系统管理员维护基础数据和账号权限。这样拆完之后，模块边界就非常明确了，后端Controller层级也可以按此划分，每个角色对应一组独立接口，互不干扰。
1.2 为什么这套技术栈是毕业设计里的“标准答案”
技术选型这件事，每年都有同学纠结。我的建议很直接：
- Spring Boot版本：选2.7.x，不要追新。3.x系列要求JDK 17，很多毕设用的还是JDK 1.8环境，2.7.x依然是兼容性最稳的选择。网上资料、公司里用的、学长写过的代码，全是2.x的语法，遇到问题搜索一下就能解决，这个优势非常实际。
- 持久层框架：MyBatis-Plus是主流，内置BaseMapper把单表CRUD都做完了，分页插件也顺手，能省掉大量重复的XML和SQL。如果你愿意用JPA也行，但多表关联查询和复杂统计报表写起来没有MyBatis-Plus顺手。
- 前端部分：Vue + Element UI是“毕业设计三件套”，学习曲线低、组件丰富，后台管理系统页面一天能搭完。前后端分离的好处是答辩的时候可以拆开演示，后端接口、前端页面各自独立，也方便后面扩展。
- 接口文档与鉴权：接口文档用knife4j（Swagger的增强版），登录认证用JWT，再配一个拦截器做白名单放行，这几个组合在毕设里很成熟，网上案例一抓一大把。
这套组合选型下来，核心是“稳”。毕设最怕的不是技术不够新，而是项目推不下去、答辩出了问题无法解释。在就业市场上，Spring Boot+MyBatis+Vue也是后端初级岗位的通用要求，做这个等于顺带把面试基础语法刷了一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计：先理清这10张核心表再动手
2.1 主业务表的划分与关联关系
数据库设计是整个项目的地基。表设计如果合理，后面的Service代码会写得非常顺；表设计不合理，写到一个模块就要回头加字段、改关联，心态很容易崩。
我按照门诊主链路把核心表整理成了这份清单，可以直接参考着搭建：
| 序号 | 表名 | 业务作用 | 关键字段 |
|---|---|---|---|
| 1 | department | 科室表 | id、科室名称、位置、简介 |
| 2 | doctor | 医生表 | id、姓名、科室id、职称、简介 |
| 3 | schedule | 排班表 | id、医生id、日期、时段、总号源、剩余号源、挂号费 |
| 4 | patient | 患者表 | id、姓名、身份证、手机号、性别、出生日期 |
| 5 | registration | 挂号记录表 | id、患者id、排班id、医生id、挂号日期、状态 |
| 6 | diagnosis | 诊断记录表 | id、挂号id、患者id、主诉、诊断结论、建议 |
| 7 | prescription | 处方单表 | id、诊断id、患者id、医生id、开方时间、状态 |
| 8 | prescription_item | 处方明细表 | id、处方id、药品id、药品名快照、数量、单价、用法 |
| 9 | drug | 药品表 | id、药品名、规格、库存、单价、厂家 |
| 10 | fee_record | 收费记录表 | id、业务类型、业务单号、应收金额、实收金额、支付状态 |
| 11 | sys_user | 系统用户表 | id、用户名、密码、姓名、角色、状态 |
这几张表之间的关联也不复杂：doctor通过department_id挂到科室；schedule通过doctor_id关联医生；registration同时关联患者、排班和医生；diagnosis关联挂号记录；prescription关联诊断记录，再由prescription_item把处方和药品关联起来。收费记录用一个“业务类型+业务单号”的通用字段设计，可以同时承接挂号费和药品费。
2.2 号源扣减和患者去重怎么在表设计上打底
两个业务细节必须在建表阶段就想清楚，不然后面写代码会非常痛苦。
第一个是号源扣减。排班表里的“总号源数”和“剩余号源数”这两个字段是必须有的。挂号的时候，先查剩余号源是否大于0，再执行扣减，不能只在前端做判断。真实医院里专家号几秒钟就被挂完，系统如果不在数据库层面限制住，必然出现超号。后面代码部分我会专门讲怎么用行锁来处理。
第二个是患者去重。患者的id_card（身份证号）字段要建唯一索引。前台录入患者信息时，先按身份证查一下是否已建档，如果已存在就直接复用，避免一个患者建出三条档案，统计数据全部失真。这个字段设计层面加唯一约束，哪怕代码漏了判断，数据库也能兜底。
再补充一个建表习