这两年找我咨询毕业设计的人里十个里有六七个都是做管理系统管理系统里“医院门诊”又是出现频率最高的一类。这个题倒不是因为它有多新奇而是它的业务链条足够完整从患者建档、预约挂号到医生接诊、开具处方再到收费结算、药房发药每一个环节都有清晰的数据流和状态流转。把这条链路放在SpringBoot体系下实现既能体现JavaWeb的基础功底又能展示数据库建模、事务处理、权限控制这些硬技能作为毕业设计来说性价比极高。今天要聊的这套项目标题信息很明确基于SpringBoot的智慧门诊综合服务平台面向中小型医院的门诊业务一体化系统。说白了就是围绕门诊全流程把挂号、看诊、收费、发药、库存这些事全部塞进一个Web系统里统一管理。下面这篇内容我会从需求拆解、技术选型、数据库建模、核心业务流程实现一直讲到常见坑点和排查思路。目标是让有Java基础的同学既能完整复现这套系统又能在答辩的时候把每个设计决策都讲透。愿意花十几分钟看完这篇大概率能帮你省下至少两周的返工时间。1. 先拆需求门诊业务到底在跑什么做系统最忌讳一上来就建表写代码。门诊信息管理系统看着功能多实际上核心就是一条主流程加若干个支撑流程。把这层窗纸捅破整个项目的功能边界、表结构、接口设计就全清楚了。1.1 五个核心角色一条主线业务先捋一下用户角色。任何医院门诊系统都逃不过这五个角色患者、医生、收费员、药房药师、系统管理员。患者是服务的起点他需要注册建档、预约挂号、查看挂号记录、接收检查结果如果做了检查模块的话。医生是业务中枢要查看排班、接诊患者、写病历、开处方、开检查申请单。收费员处理挂号收费、处方收费、退费退号。药房药师负责库存管理、处方审核、发药出库。系统管理员维护科室、医生排班、药品目录、系统参数和用户权限。五个角色串起来就是一条主线患者建档 - 预约或当天挂号 - 分诊候诊 - 医生接诊 - 开处方/检查单 - 收费确认 - 药房发药 - 诊疗结束。这个流程走完整个系统的核心业务就闭环了。我见过不少同学把精力全花在花哨的统计报表上结果主流程反而跑不通。这个项目想拿高分主流程的完整性比任何锦上添花的功能都重要。因为主流程承载的是典型业务逻辑挂号涉及并发防重收费涉及金额计算和事务发药涉及库存扣减退费涉及反向流程这些全是大厂面试里会被反复追问的东西放在毕业设计里就是妥妥的加分点。1.2 中小型医院和大型三甲的系统差异标题里特意强调了“面向中小型医院”这个定位不是随便写的。中小型医院、社区卫生院和大型三甲医院的信息化需求有本质差别。大型三甲医院用的通常是以HIS为核心的重型系统模块几十上百个与医保、LIS检验、PACS影像、电子病历深度集成实施周期按年来算数据库并发和灾备要求极高。而中小型医院或私立诊所核心诉求是轻量、够用、能落地。患者量没那么大并发压力不高但业务流程必须完整覆盖界面要简单操作要直观最好一个普通收费员经过十分钟培训就能上手。明白这个差异你的技术决策就顺理成章了不需要分布式微服务不需要消息队列不需要复杂的高可用集群。单体SpringBoot应用够用且稳妥数据库选MySQL前端根据自己基础选Vue或模板渲染服务端只需要考虑好事务边界和并发控制。这套组合资源占用小部署简单一台普通服务器就能扛起日常业务跟中小型门诊的信息化需求天然匹配。2. 技术方案为什么是这套组合技术选型是答辩时老师必问的部分。能说清楚“为什么选它”和“为什么不选它”比罗列一堆技术名词更有说服力。2.1 SpringBoot在门诊场景下的优势服务端选SpringBoot几乎是这类项目的最优解。SpringBoot的核心价值在于自动配置和开箱即用把以前Spring时代大量的XML配置收进约定里让你能把主要精力放在业务代码上。具体到门诊系统SpringBoot带来的好处很实在。第一内嵌Tomcat打包成jar直接启动部署成本极低。对中小型门诊来说IT人员可能就一两个没时间维护复杂的中间件环境一个java -jar就能启动的系统很友好。第二生态成熟和MyBatis-Plus、Spring Data JPA、Redis、Spring Security配合都有现成方案不需要造轮子。第三监控和运维插件多Actuator、Druid监控都能直接集成。第四当前Java岗位招聘里SpringBoot几乎是标配做这个题目的经历在找工作时可以直接写进简历。我在实际带毕业设计时经常说一句话技术选型要考虑“项目需要什么”而不是“什么技术看起来更炫”。门诊系统最核心的是稳定、清晰、数据一致SpringBoot的稳定性和低复杂度正好匹配。用Spring Cloud微服务化这个系统属于典型的大炮打蚊子还容易在毕业设计阶段把自己绕晕。2.2 MyBatis-Plus为什么是省心之选持久层框架我已经连续几年推荐MyBatis-Plus尤其在毕业设计项目里。理由很直接CRUD效率高查询条件构造器好用同时还能保留手写SQL的能力。MyBatis-Plus内置的BaseMapper提供了insert、deleteById、selectById、updateById这些单表CRUD十张表左右的业务少写几百行重复的XML。它的查询条件构造器LambdaQueryWrapper对多条件组合查询非常友好比如门诊系统里“按科室查今天的挂号单”“按药品名称模糊搜药品”“按状态查待收费处方”一行代码就能拼出条件查询。最实用的是分页插件。门诊系统的列表页基本都有分页需求MyBatis-Plus的PaginationInnerInterceptor配置一下Page对象传进去就能完成物理分页不用自己拼LIMIT。还有一点它的逻辑删除功能很适合门诊系统的档案管理场景比如患者删除操作用逻辑删除打标记既保留历史数据又避免关联表的外键报错。建议把基础CRUD交给MyBatis-Plus挂号并发扣减、库存扣减这类写复杂SQL或需要锁定行的地方直接注解手写SQL。框架和手写结合既有效率又有掌控感。2.3 前端方案Thymeleaf还是前后端分离前端选型常见的有两种Thymeleaf模板渲染或者Vue Axios的前后端分离。如果你想尽可能把精力集中在后端和答辩讲解上选Thymeleaf加Bootstrap。服务端使用Spring MVC的Controller返回视图数据通过Model传过去在HTML里用简单语法渲染列表、循环、拼接URL。优点是一套工程搞定不用为跨域烦恼也不用部署两套环境。对没有系统学过前端、只掌握基础HTML/CSS的同学来说这个方案最友好。如果你的重点是展示现代Web工程能力和前后端协作可以选Vue Spring Boot前后端分离。把后端做成纯RESTful API前端单独用Vite或Vue CLI搭建。这样做的好处是界面交互体验更好也贴近真实工作场景但前期准备工作多一截跨域处理、Token传递、前端环境搭建、打包部署。我的建议很实际按自己擅长的来。如果时间紧、后端吃紧果断用Thymeleaf如果对Vue有一定基础愿意多花两周调前端那可以走前后端分离答辩时也确实多一个可展示的亮点。3. 数据库设计先把表结构画明白门诊系统能不能跑得顺数据库设计占七成。表建错了后面接口怎么写都别扭。这块我会把核心表拆开讲附带关键的字段设计思路这些都是可以直接抄作业的。3.1 核心表清单与关系按主流程拆核心业务表我习惯分成五组基础档案sys_user登录账号、sys_role角色、sys_user_role用户角色关联、sys_dept科室、doctor_info医生信息、patient_info患者档案排班预约doctor_schedule医生排班、registration挂号单诊疗处方medical_record病历、prescription处方主表、prescription_item处方明细收费药房charge_record收费记录、refund_record退费记录、drug_info药品目录、drug_stock药品库存辅助扩展sys_log操作日志、schedule_config系统参数表之间关系也清晰。patient_info与registration是一对多一个患者可以有多次挂号。doctor_schedule与registration也是一对多一个排班格子会被多次挂号但需要限制挂号数量。registration与prescription是一对一或一对多一次就诊可能开出一张主处方加多个明细项。charge_record关联挂号单或处方一份账单对应一张处方。drug_info与drug_stock是一对一药品基础信息和库存数量分开管理。设计时要注意一个原则主表加明细表的模式在处方模块里最优。prescription记录就诊ID、医生ID、患者ID、总金额、开单时间、状态prescription_item记录每条药品的药品ID、数量、单价、单项金额。这么做的好处是打印处方时按主表信息显示头部按明细表逐行显示药品统计科室用药量也直接对明细表聚合。3.2 关键字段设计的门道很多同学建表很随意字段意思不够明确类型长度拍脑袋。这里我挑几个容易踩坑的字段细说。第一个是金额字段。处方金额、收费金额、退费金额一律用DECIMAL(10, 2)Java对应BigDecimal。严禁使用Double或Float存储金额二进制浮点数在加减运算时会出现0.1加0.2不等于0.3这类精度问题门诊每天几百笔收费金额对不上账非常麻烦。数据库用DECIMAL传参用BigDecimal计算过程更不允许随手转成double。第二个是状态字段。挂号单状态、处方状态、收费状态、退费状态建议用TINYINT存数字不要用字符串存中文。比如挂号单状态定义0已预约 1已挂号 2已接诊 3已结账 4已退号 5已爽约处方状态定义0待收费 1已收费 2已发药 3已退费。数字状态的好处是数据库索引效率更高后端用枚举类统一维护不容易出现“已缴交”和“已缴费”这种同一含义两种写法的问题。第三个是时间字段。预约时间、就诊时间、收费时间、发药时间统一用datetime类型Java端用LocalDateTime。特别注意前端传时间字符串时后端要用DateTimeFormat(pattern yyyy-MM-dd HH:mm:ss)或JsonFormat统一指定格式否则早晚遇到LocalDateTime反序列化报错问题这个在本地能跑、部署后报错的概率极高。第四个是患者主索引字段。门诊系统的患者信息身份证号是天然的关联标识但存在身份证号缺失或填写错误的情况。我的建议是设计一个patient_no字段作为患者唯一编号由系统生成业务上主键仍然用自增ID但整个业务查询优先走patient_no。这样即使同一个患者信息被录入了两次通过patient_no也能快速合并。3.3 排班表与号源控制的建模思路医生排班是挂号系统的前置依赖。排班表我设计成按时间段拆行而不是一张表硬塞一周的安排。doctor_schedule字段包括doctor_id、dept_id冗余科室方便查询、schedule_date出诊日期、period_type时间段如上午、下午、period_time具体起止时间可选、total_number总号数、used_number已约号数、status0正常 1停诊 2已满。有的同学喜欢把一周七天分七个字段存查询容易写但排班调整极其麻烦我建议还是拆行一行就是一个可售卖的号源批次逻辑清晰控制号源就变成了对schedule表做更新。排班与挂号之间的关联挂号时先校验排班状态再校验已约号数小于总号数然后进行扣减。这里的并发控制我会在后续模块实现里详细说但核心思路就是利用数据库行级锁或乐观锁避免两个患者同时挂到最后一张号。4. 核心链路从挂号到发药怎么串起来功能列表写在需求文档里是一回事在代码里把数据流转串起来又是另一回事。这一章我就按主流程一关一关过每关点出最关键的技术问题。4.1 挂号预约防重复提交是头号工程挂号接口是整个系统中并发最敏感的部分。尤其是针对热门科室几个患者同时挂同一医生的剩余号源后端处理不好就会出现超挂。我们设计挂号的业务逻辑首先是检查排班可用号数。使用排班表的已用号和总号数判断当前是否可挂。如果前端的用户同时点了两次提交后端若只是先select再update两次请求都会读到used_number8总数10于是都执行更新数据库里的used_number被覆盖成9但实际生成了两张挂号单。解决这个问题推荐两种方式我更建议两种结合使用。方式一数据库乐观锁。更新排班表时使用条件更新UPDATE doctor_schedule SET used_number used_number 1 WHERE schedule_id ? AND used_number total_number。这条SQL本身是原子操作MySQL的UPDATE会锁住对应行只有满足used_number小于total_number才更新成功。受影响行数为0说明号源已满直接返回提示。方式二业务层幂等校验。在registration表上建立唯一索引patient_id、schedule_id、registration_date或者用Redis的SETNX记录“某患者今天已挂号某排班”的标记。数据库唯一索引靠谱且无需额外组件用Redis更灵活。我实测下来把这两者结合最稳。业务方法加Transactional确保挂号单插入和排班更新在同一事务里任何一个失败都回滚。再配合事务加WHERE条件更新基本杜绝了超挂。提示不要只做“前端按钮置灰”就以为安全了。前端防重只是体验优化真正的防线在后端的唯一约束和行锁。4.2 医生接诊与处方生成患者挂号之后进入候诊列表医生在医生工作台看到待接诊患者。接诊动作把挂号单状态从“已挂号”更新为“已接诊”然后填写病历再开处方。处方生成的核心逻辑是主表和明细表同时落库。为了防灾必须先compute每行单项金额、合计总金额再一次性完成插入。这里有个细节药品单价要从drug_info表读取禁止前端传单价进来。原因是药品调价是常见操作如果单价由前端传入存在篡改或传递脏数据的风险。后端根据药品ID查目录单价然后计算金额前端只负责展示。同时注意处方状态机的推进刚创建为待收费收费成功后置为已收费药房发药后置为已发药。每一步都在Service层封装成独立方法并且更新状态时带上“当前状态”条件防止乱序更新。开处方的事务边界先写处方主表和明细表再更新接诊状态。假如先更新接诊状态再写处方处方失败时接诊状态已经变了患者就再也进不了接诊列表了。事务要么全成功要么全回滚状态的一致性靠这个保证。4.3 收费与库存的联动收费窗口拿到处方后操作员点“收费”后端要做的事不止是记录收费流水还要关联处方状态、余额台账和药房库存。首先校验处方状态为“待收费”防止重复收费。重复点击“收费”按钮是真实门诊环境里常见的误操作没做防重会出现一笔处方被扣两次钱。线上线下我都遇过这种案例加一个charge_record表的唯一索引prescription_id就能挡住。校验通过后创建收费记录处方状态改为“已收费”。这里要说明一点我建议收费时不管库存而是发药时扣库存这更符合药店业务真实逻辑。收费只是资金结算发药才是实物出库。收费后如果药房库存不足系统需要提示库存不足引导线下想解决方案或退费处理。所以收费逻辑不复杂核心是状态校验和金额记录。真正复杂一点的是发药扣库存。发药动作要“删除”对应库存SQL写成原子更新UPDATE drug_stock SET stock_number stock_number - #{num} WHERE drug_id #{drugId} AND stock_number #{num}。受影响行数为0说明库存不足本次发药失败。关联处方明细循环执行这些UPDATE同样用事务包裹。4.4 退号退费反向流程的设计细节正向流程谁都会写反向流程才能真正体现考虑是否周全。门诊系统的退号退费其实是两个关联但不能混为一谈的操作。退号患者挂号后未就诊之前可以取消挂号。操作链路是挂号单状态变为“已退号”排班表的used_number减一号源释放。这里务必注意一定要先校验挂号单状态是否为“已挂号”或“已预约”已经接诊的挂号单是不能退号的否则医生的病历数据会失去业务载体。退费处方已经收费但未发药时可以退费发药后原则上只退药不退费走退药流程。退费操作要创建一笔退费记录金额应该从原收费记录中冲减不是直接删掉原收费记录这是对账需求决定的。有点抽象我举例子如果一笔处方收费200元后来退了其中一盒药这里就出现部分退费必须保留原收费记录的200元新增退费记录返回40元最后结算报表才能认账。退费流程务必加状态机校验已发药的处方不允许直接退费。很多同学败在这里因为只写了退费接口没有写状态校验测试时正常一对接真实药房流程就出现负数库存。5. 权限模型与系统安全设计门诊系统是业务系统涉及患者隐私和收费数据权限和安全不是可有可无的功能。这块设计好了答辩的时候也能主动说说老师会眼前一亮。5.1 JWT登录态与用户认证登录方案我推荐JWT理由是无状态、适合前后端分离、不需要额外的Session存储。Spring Boot Spring Security或者Sa-Token做权限框架都可以我这边更倾向于Sa-Token因为上手简单文档清晰不用像Spring Security那样写一堆配置类。JWT的核心流程是这样用户提交用户名和密码后端从sys_user表中校验密码。密码建议用BCrypt加密存储不要明文存、不要MD5存。校验成功后生成包含用户ID、用户名、角色标识的token过期时间建议12小时或24小时。前端每次请求把token放在Authorization请求头中后端用一个拦截器解析token解析失败或过期则返回401未认证。这里我踩过一个坑JWT生成时如果把用户信息全部塞进载荷里一旦用户改了资料token里的信息还是旧的。稳妥做法是token里只放user_id和登录时间需要其他用户信息时拿着user_id去数据库重新查。多个Redis存储在线token也有助于主动踢人下线但在毕业设计阶段JWT加拦截器已经足够了。5.2 基于角色的访问控制RBACRole-Based Access Control是权限控制的经典模型门诊系统里非常适用。不同角色执行不同操作医生能看患者的挂号单、病历、开处方不能看到收费金额明细医生不需要接触钱收费员能查处方、收费退费但看不到医生写的病历诊断内容药房药师能看到处方明细、库存但不能修改药品价格系统管理员做基础配置但不参与任何诊疗和收费操作。具体实现上后端在每个接口上定义权限标识比如RequiresRole(doctor)或RequiresPermissions(charge:pay)加在Controller方法上。拦截器或过滤器会对请求进行角色校验。注意一点前端菜单只是隐藏按钮后端接口必须做权限校验。只做前端隐藏不做后端校验等同于把保险柜的门画在了墙上。5.3 关键数据的操作留痕门诊数据敏感尤其是收费、退费、发药这类涉及钱和货的操作一定要做操作日志。别小看这个模块需求方很可能明确要求。我的做法是设计一张sys_log表字段包括operator_id、operator_name、operation_type登录、挂号、收费、退费、发药、修改药品、删除档案、target_type操作对象类别、target_id对象ID、detail操作前后的关键信息摘要、operation_time。可以使用Spring AOP配合自定义注解一个OperationLog注解标在方法上切面自动记录调用者、参数、耗时实现无侵入式日志采集。实际操作里还有一件事容易被忘患者隐私数据展示时要脱敏。比如列表页手机号显示138****1234身份证号显示前三位后四位详情页根据角色权限决定是否展示完整信息。这个可以做在服务端返回前的脱敏方法里或者后端做序列化时的脱敏。这属于安全细节大多数毕业设计都会漏你做了就是差异化亮点。6. 高频问题与排查实录这个系统我前后见过不少人复现也亲手调过不少问题。把最常见的高频问题整理成一份排查速查如下面两张表问题现象排查思路解决方案挂号重复提交生成两条挂号单前端按钮只禁用了一次后端没防重registration表加唯一索引排班更新用原子UPDATE本地跑得好好的部署到服务器上时间差8小时没配置JVM时区MySQL时区不一致连接串加serverTimezoneAsia/ShanghaiJVM启动参数加-Duser.timezoneGMT08收费金额出现一堆小数位对不上账用了Double/Float计算金额全面改BigDecimal数据库改DECIMAL(10,2)事务方法没生效数据写到一半同类内部方法调用Transactional被自调用绕过把方法拆分到独立Service或者用AspectJ代理方式处理分页查询的数据重复MyBatis-Plus分页插件未正常配置正确添加PaginationInnerInterceptor并注册为Bean患者退费后药房库存变了负数发药状态校验缺失退费不校验是否已发药增加状态机校验已发药禁止直接退费必须走退药流程前端跨域无法请求后端未配置CORS写全局CorsFilter或Spring CORS配置类6.1 挂号并发场景下的重复提交这个是真现场最常翻车的点我多展开说一说细节。并发重复提交有几种情况一个是同一个患者重复点挂号按钮另一个是多个患者同时抢最后一个号源。它们本质上都可能导致同一排班被超挂。我推荐的组合方案是数据库唯一约束兜底 原子更新控制号源。具体这样设计registration表加唯一索引uk_patient_schedule_datepatient_id, schedule_id, registration_date挂号Service方法上加Transactional先执行原子上限UPDATE受影响行数大于0才继续插入挂号单插入挂号单时如果唯一键冲突抛出DuplicateKeyException由全局异常处理器捕获并提示“该患者当天已挂过此科室请勿重复挂号”。这个方案的好处是即使遇到并发数据库的锁和唯一约束会保证决策一致性不会出现“两人都成功挂到最后一张号”的离谱问题。我实测并发200线程压过这个方案数据一致性是可靠的。6.2 事务不生效的类型与规避事务问题太典型了。症状一般是一条数据插进去了另一张表更新失败但数据没有回滚。排查时优先检查这几个位置。类上有没有加Service方法有没有加Transactional这两个条件少一个都不行。还需要检查方法是否是public权限。protected或private方法Spring AOP代理根本调用不到事务自然失效。还要看异常有没有被吞掉。很多同学喜欢在Service方法里try-catch一把梭把异常捕获了事务看到的是正常返回就不会回滚。最容易犯的自调用问题pairedService内部方法A调用方法BB上面有Transactional但A调用B是通过this调用的没走代理对象事务完全失效。解决方法是把B拆到独立的Service类中然后注入调用或者在类里注入自身代理对象来调用。但拆Service更干净也符合单一职责。对了注意事项Transactional默认只回滚运行时异常如果需要回滚CheckedException要显式设置rollbackForException.class。6.3 金额精度和前后端传参金额相关的坑我一共总结出三条。第一条存储必须用DECIMAL代码用BigDecimal这个前面反复强调过。第二条前端输入框允许输入小数但用户输的金额字符串后端要用new BigDecimal(str)构造不要用Double.parseDouble转避免又走一遍浮点数误差。第三条涉及金额的查询和统计报表求和用SUM函数们不要先在Java里遍历求和再转字符串数据库SUM对DECIMAL的处理是精确的。也有同学遇到前端收到金额变成科学计数法。这种情况下后端返回的JSON序列化器需要配置BigDecimal使用toPlainString输出或者统一格式化为两位小数返回给前端。配好之后传参和显示都干净。6.4 LocalDateTime解析和时区问题用LocalDateTime替代Date是一种进步但带来了前后端格式处理的成本。如果后端返回的LocalDateTime字段前端直接显示会是一串带T的ISO字符串不符合界面展示习惯。解决办法分两层一是后端序列化配置注册Jackson的JavaTimeModule并设置日期格式为yyyy-MM-dd HH:mm:ss二是每个接收时间参数的DTO字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。如果用了MyBatis-Plus插入时对LocalDateTime的处理也需要在application.yml里开启MapUnderscoreToCamelCase这类常规配置。时区问题刚才速查表里提过再强调一下数据库连接串必须显式指定serverTimezoneAsia/ShanghaiJVM如果跑在默认时区不对的服务器上还要加-Duser.timezoneAsia/Shanghai。两侧都定死时区就不会出现测试时正常、部署后时间差8小时的诡异现象。7. 我的一些实际操作体会文章最后聊几件我在开发过程中感触最深的事。这算不上什么标准答案但都是真金白银换来的经验供你参考。第一件事无论需求多着急先把状态流转图画出来再动手。我在做模拟项目X的时候就是先把挂号单、处方、收费记录几张核心表的状态机画在纸上从初始到终态每条线都标出来后面写接口基本不犹豫。状态都不清就开始写代码改一个流程就要连带改三张表耗时至少翻倍。第二件事测试数据一定要贴近真实情况。往里塞假数据的时候别用“张三李四王五”这种要做一批类似“姓名张三身份证110101199001011234挂号科室内科就诊时间2025-05-20 09:30”这样格式完整的数据。这样能提前发现时间格式问题、身份证字段长度不够的问题、日期区间查询的边界问题。这些如果在验收演示时突然报错非常破坏印象分。第三件事合理的模块拆分能救命。系统虽然小但Controller、Service、Mapper、Entity、DTO、VO这样的分层一定要清晰。答辩时老师让你讲讲某段代码你如果指着三层嵌套的业务逻辑说不出所以然那印象分明显受影响。分层清楚也代表你有工程习惯这本身就是加分项。最后再说一句掏心窝的话门诊系统这类题目的价值不仅在于“完成一个系统”更在于让你体验一次真实的业务闭环。从需求分析到数据库设计从前端交互到并发控制每跨过一次坑你学到的都比单纯背八股文要多得多。复现这套系统之后如果还有余力可以考虑把检查申请、科室库存预警、数据看板这几个扩展点加进去这就是一个能拿去实习面试里讲完整故事的智慧门诊综合服务平台了。