Spring Boot医院管理系统实战：从数据库设计到部署上线全解析

做了几年的医疗信息化项目，大大小小的医院管理系统也经手过好几套。从早期用JSP+Servlet手撸的笨重老系统，到后来基于Spring Boot的轻量级微服务架构，中间踩过的坑、重构掉的代码，说多了都是泪。今天这篇没什么高大上的概念，就是把一套基于Spring Boot的医院管理系统从零到落地写的源码、数据库设计、配套文档整个链路完整拆开讲一遍。不管你是毕业设计选了这个题目，还是公司项目需要快速搭一套内部HIS原型，又或者纯粹想了解医疗系统到底有哪些躲不开的业务细节，这篇文章都能给你省下大量查资料和试错的时间。

先说清楚这套系统做了什么：面向中小型医院和诊所，涵盖门诊挂号、医生工作站（开立医嘱）、收费结算、药房药库、住院病区管理等核心流程，同时预留了系统管理、权限角色、操作日志等基础能力。整个项目基于Spring Boot 2.x + MyBatis Plus + MySQL 8.0，前端采用Layui + Thymeleaf（没错，选这个组合不是因为炫酷，而是因为医院这类传统行业的信息科真的不待见花里胡哨的SPA，直接模板渲染反而活得好）。源码结构清晰，数据库备份文件、初始化脚本和完整的部署文档一应俱全，拿到手改改配置就能跑。

接下来我会按照实际开发顺序来拆解这套系统的方方面面，重点讲清楚每个模块为什么这样设计、对应的表结构和核心代码怎么落地、部署上线时最容易出问题的几个环节分别是什么。

1. 医院管理系统的核心业务需求拆解：别一上来就写代码

做医疗系统最忌讳的事情，就是拿到需求后直接开表建字段。医院业务流程环环相扣，挂号、看诊、开药、收费、发药，中间任何一环漏了状态流转，后面全乱。

1.1 最小可行闭环：从挂号到收费结算

我在梳理这套系统的需求时，首先画了一条主业务链路：

患者到院 -> 挂号（选择科室/医生，生成挂号记录） -> 医生接诊（查看患者信息、录入诊断、开具处方） -> 患者去收费窗口缴费（根据处方明细计算费用） -> 药房发药（核销处方状态） -> 患者离院或转入住院。

这套闭环里涉及到的最核心实体包括：患者、科室、医生、挂号单、处方、处方明细、收费单、药品库存、操作员（员工）。系统设计的第一步，就是把这张链路图变成数据库里的表关系。

1.2 扩展需求：住院和药库管理

小型诊所可能只需要门诊流程，但既然做的是“医院管理系统”，住院环节早晚要接进来。本系统的住院模块我采用了相对精简的方案：登记入院 -> 分配病床 -> 记录每日医嘱 -> 出院结算，不做复杂的护士排班和护理记录，毕竟那部分需要独立的NIS系统来支撑，硬塞进来反而四不像。

药库管理这块，我做了两个层级：药房库存和药库采购。药房管的是日常发药库存，药库管的是采购入库、供应商和批号效期。门诊发药直接从药房扣减库存，药房库存不足时发起向药库的领药申请，简单实用，不会过度设计。

1.3 非功能性需求同样重要

除了业务流程，医院系统还有一个特色要求：操作留痕。谁在什么时间修改了哪条数据，必须能追溯，否则出了医疗纠纷谁都说不清。所以这套系统从设计第一天就加了操作日志表和登录日志表，所有关键业务表的增删改都要求记录日志。

权限方面，我采用了经典的后台RBAC模型：用户-角色-菜单（权限）三层结构，医生、护士、收费员、药房药师、系统管理员各归其位，不越权操作。

2. 技术选型和架构设计逻辑：为什么是Spring Boot + MyBatis Plus

技术选型这件事，很多初学者容易陷入“什么新用什么”的误区。但医院信息科或者说甲方真正关心的是三件事：稳定、易维护、便宜（好招人）。这正是我选择Spring Boot生态的原因。

2.1 后端框架的取舍对比

先放一张我当时做选型对比时整理的表格，比较直观：

可以看到，医院管理系统本质上是一个典型的企业级CRUD项目外加复杂业务状态流转，用MyBatis Plus能让我把SQL牢牢握在自己手里，遇到报表统计这类复杂查询时可以精准控制，不会被ORM的自动映射带到沟里去。

2.2 数据库选型：MySQL 8.0的理由

数据库这块，MySQL 8.0在中小型医院系统里绰绰有余。选8.0而不是5.7，主要看重三方面：一是窗口函数让统计报表SQL干净太多，比如计算科室月度营收排行，一条SQL搞定；二是JSON类型字段在某些灵活扩展场景下非常实用（比如患者过敏史，我直接用JSON数组存储）；三是默认字符集utf8mb4，避免遇到生僻字（比如患者姓名带冷僻字）出现乱码。

事务隔离级别我设置为默认的REPEATABLE READ，加上InnoDB引擎的MVCC，应付挂号并发（同一时刻多个窗口操作同一张就诊号表）完全够用。如果你要硬杠“医院系统应该用Oracle”，那对于这种量级的项目没有意义，MySQL成本低、运维简单、学的人多，才是现实选择。

2.3 整体架构分层

整个后端采用经典的四层架构，没有引入微服务和分布式中间件，因为单体架构在2000人以下规模的医院完全够用，引入了反而增加运维难度（小医院没有专职运维，出了问题电话打到开发这里，排查分布式链路远比单体痛苦）。

• Controller层负责参数接收和接口路由。
• Service层承载业务逻辑，事务边界控制在这里。
• Mapper（DAO）层负责数据库交互，通过MyBatis Plus进行单表CRUD，复杂联查走XML。
• Model（Entity/DTO/VO）层负责数据载体定义。

实际开发时我额外加了一个Common模块，统一放结果封装返回（Result类）、全局异常处理器、公共工具类，保证每个Controller的返回格式一致。前端页面通过Thymeleaf渲染时，需要的数据通过ModelAndView传递；如果未来要接小程序和App，则通过@RestController返回JSON。

这套设计最大的好处是：前期用模板引擎做后台管理页面非常快，后期扩展接口时，核心Service层逻辑完全复用，只需要新增Controller层的REST接口即可。

3. 数据库设计实战：核心表结构逐张拆解

数据库设计是一套系统的灵魂。我建库的时候遵循几个原则：主键统一用bigint自增（不用UUID做主键是因为索引性能和存储空间的考虑）；时间字段统一datetime；金额字段统一decimal(10,2)；状态字段统一tinyint并用注释标明含义；所有业务表都包含create_time、update_time、deleted逻辑删除字段。

3.1 系统管理域：用户、角色、菜单

系统管理域一共4张表，经典的RBAC模型。sso_user表存储登录账号，包含用户名、密码（BCrypt加密存储）、真实姓名、关联员工ID、状态。sso_role表存储角色，sso_menu表存储菜单和权限点，sso_user_role和sso_role_menu是两张关联表。

有个细节值得说：菜单表在开发时一定要设计成父子结构（parent_id字段），因为后台管理界面的侧边栏菜单需要无限级嵌套。权限点则通过menu_type字段区分（目录/菜单/按钮），按钮级别的权限点可以精确控制“某个角色能不能看到某个按钮”，这个在医院的收费和退费权限控制里很关键。

3.2 人员档案域：患者、员工、科室

• 科室表（his_department）：科室编码、科室名称、科室类型（门诊/住院/药房/行政/医技）、排序号、状态。
• 员工表（his_employee）：员工编号、姓名、性别、所属科室ID、职称、入职日期、联系电话。
• 患者档案表（his_patient）：这个表比普通系统的用户表复杂得多。就诊卡号（卡号也当成内部主键用，方便刷卡）、姓名、性别、出生日期、身份证号、联系电话、过敏史（JSON字段）、紧急联系人、登记时间。

患者档案有一个业务点要特别处理：身份证号不是必填项。很多老人来看病不带身份证，或者小孩子还没办身份证，你要是把身份证设为唯一非空索引，系统直接被真实的医院场景用废掉。解决方案是给身份证号设置允许重复（因为双胞胎出生日期和父母信息可能一样）、允许为空的唯一索引，实际唯一判断通过“姓名+身份证号”或者“姓名+电话”去做。

3.3 门诊业务域：挂号、就诊、处方

挂号表（his_registration）核心字段：挂号单号（业务编号，格式：日期+流水号，如202412150001）、患者ID、科室ID、医生ID、挂号类型（普通/专家）、挂号费用、就诊序号（当天同一医生的第几号）、状态（已挂号/已就诊/已退号）、挂号时间、操作员ID。

就诊/诊断记录表（his_visit）在系统里承载每次患者和医生的交互。一个挂号单对应一条主就诊记录，医生在此记录下诊断结果和主诉，同时关联处方表。

处方表（his_prescription）和处方明细表（his_prescription_item）是一对多的关系。主表存处方单号、患者ID、医生ID、处方类型（西药/中成药/检查/检验）、总金额、状态（待收费/已收费/已发药/已退费）；明细表存药品ID/项目ID、药品名称、规格、单价、数量、用法用量（如“口服，每日三次，每次一片”）、金额小计。

这里要注意的是：处方明细不适合做成单纯的药品ID外键。因为处方一旦开立，药品名、单价这些信息理论上不能随药库价格的调整而变动——万一某药品改了价，已经开出去的处方显示的价格也得跟着变，那就乱了。所以明细表里冗余存储了药品名称、规格、单价快照，查询时直接读快照字段，避免JOIN药品表。

3.4 药品库存与收费结算

药品信息表（his_drug）：药品编码（院内编码）、通用名、商品名、规格、生产厂家、批准文号、零售单价、库存总量、预警下限。药品库存表（his_drug_stock）按批号和效期拆分行记录，一药多批次，发药时先进先出。

收费表（his_charge）用于结算所有费用：收费单号、患者ID、收费类型（门诊/住院）、关联单据类型（挂号/处方）、关联单据号、应收总金额、实收金额、支付方式（现金/刷卡/微信/支付宝）、收费员ID、收费时间、状态。

3.5 住院域：入院登记、病床分配、出院结算

住院模块我做了三个核心表：住院登记表（his_hospitalization）、病床表（his_bed）、住院收费明细表（his_hospital_charge_detail）。

住院登记表保存患者入院基本信息、入院科室、主治医生、入院诊断、入院时间、预计出院时间、状态（在院/已出院）。病床表按病区管理，字段包含床号、所属病区/科室、床位费（按天计算）、状态（空闲/占用/保洁）。住院结算采用“每日费用累计”模式，每天由护士在系统里录入当日的药品费用和护理费用，出院时汇总所有明细生成总账单，实现简单且够用。

4. 核心功能模块代码实现：关键片段与思路

光有表结构还不够，我来把几个核心模块的实现思路和关键代码片段展开聊聊。完整源码实现量很大，这里挑最有代表性的挂号模块和处方流转模块讲解。

4.1 挂号模块：并发控制与号源处理

挂号模块最容易出bug的地方就是并发挂号导致同一号源被抢。正常情况下上午的号源有限，两个窗口同时挂同一个医生的“第5号”，数据库层面如果处理不当就会超挂。

我的方案是给号源表加乐观锁：号源表（his_doctor_schedule）保存每天每个医生的号源总数和已挂数，更新已挂数时使用乐观锁版本号或者直接执行带条件更新。

@Override @Transactional(rollbackFor = Exception.class) public RegistrationResult register(RegisterRequest request) { // 1. 查询号源，锁定行 DoctorSchedule schedule = doctorScheduleMapper.selectByDoctorAndDate( request.getDoctorId(), request.getRegisterDate()); if (schedule == null) { throw new BizException("该医生当天暂无排班"); } // 2. 乐观锁更新已挂号数量：version字段防止并发覆盖 int updated = doctorScheduleMapper.increaseRegisteredCount( schedule.getId(), schedule.getVersion()); if (updated == 0) { throw new BizException("号源已被抢光，请选择其他医生或时间"); } // 3. 生成挂号记录，业务单号使用Redis自增或数据库流水号 Registration reg = new Registration(); // ... registrationMapper.insert(reg); // 4. 更新患者档案（如果新患者则建档） // ... return RegistrationResult.success(reg); }

increaseRegisteredCount对应的SQL核心逻辑：

UPDATE his_doctor_schedule SET registered_count = registered_count + 1, version = version + 1 WHERE id = #{id} AND version = #{oldVersion} AND registered_count < total_count

这条SQL通过版本号保证了并发安全。如果你的项目没有Redis也没关系，流水号用数据库表last_number方式也能做，扛到一天几千挂号的量级没有问题。

4.2 就诊与处方开立：事务边界在哪里

医生开立处方是一个多表写入操作：更新挂号状态、插入诊断记录、插入处方主表、插入处方明细。所有这些必须在一个事务内完成，否则会出现诊断写了但处方没写进去的脏数据。

@Override @Transactional(rollbackFor = Exception.class) public void savePrescription(PrescriptionDTO dto) { // 1. 校验挂号状态必须是“已就诊”状态，防止重复开方 Registration reg = registrationMapper.selectById(dto.getRegistrationId()); if (!"2".equals(reg.getStatus())) { // 2=已就诊 throw new BizException("当前挂号记录状态不可开立处方"); } // 2. 插入诊断记录 Visit visit = new Visit(); BeanUtils.copyProperties(dto.getVisitInfo(), visit); visitMapper.insert(visit); // 3. 插入处方主表，计算总金额 Prescription pres = new Prescription(); pres.setPrescriptionNo(generatePrescriptionNo()); BigDecimal totalAmount = dto.getItems().stream() .map(item -> item.getPrice().multiply(new BigDecimal(item.getQuantity()))) .reduce(BigDecimal.ZERO, BigDecimal::add); pres.setTotalAmount(totalAmount); pres.setStatus("0"); // 0=待收费 prescriptionMapper.insert(pres); // 4. 批量插入处方明细 for (PrescriptionItemDTO item : dto.getItems()) { PrescriptionItem detail = new PrescriptionItem(); // 快照字段：药品名、单价、规格 detail.setDrugName(item.getDrugName()); detail.setPrice(item.getPrice()); detail.setQuantity(item.getQuantity()); detail.setPrescriptionId(pres.getId()); prescriptionItemMapper.insert(detail); } // 5. 更新挂号状态为“已开方待收费” reg.setStatus("3"); registrationMapper.updateById(reg); }

事务的粒度尤其要注意。很多初学者喜欢在Service层一个方法里写好几个分段事务“先插这里、再插那里”，然后自己用try-catch包住，部分成功部分失败也不回滚，最后数据乱得没法查账。有经验的开发都会刻意控制事务边界，通常一个完整的业务动作对应一个事务方法，内部不要塞无关的远程调用。

4.3 收费与发药联动：状态机思维

收费、发药、退费的流程我设计成一个简单的状态机，核心状态在处方主表上流转：

0 待收费 -> 1 已收费（待发药） -> 2 已发药 0 待收费 -> 9 已退费 1 已收费 -> 9 已退费

收费动作触发时，同时更新处方状态和药品库存（扣减对应批次的库存）。这里注意不是直接在drug_stock表UPDATE数量，而是先插入一条库存流水表（his_drug_stock_log），然后更新库存表的剩余量。库存流水的好处是：后续退费时，可以根据流水逆向回补库存，同时能追溯每次库存变动的操作人、操作时间、关联单据号，这是医院药房管理的硬需求。

发药时药师还需要核对处方状态是否为“已收费”，如果不是，说明患者没有缴费，绝对不能发药。

@Override @Transactional(rollbackFor = Exception.class) public void dispenseDrug(String prescriptionNo, Long operatorId) { // 1. 锁定处方记录，校验状态 Prescription pres = prescriptionMapper.selectByNoForUpdate(prescriptionNo); if (pres == null || !"1".equals(pres.getStatus())) { throw new BizException("处方不存在或未完成缴费，禁止发药"); } // 2. 逐条扣减库存：先查批次（先进先出），写流水，再更新库存 List<PrescriptionItem> items = prescriptionItemMapper.selectList( new LambdaQueryWrapper<PrescriptionItem>() .eq(PrescriptionItem::getPrescriptionId, pres.getId())); for (PrescriptionItem item : items) { int stockRemain = drugStockMapper.deductStock(item.getDrugId(), item.getQuantity()); if (stockRemain < 0) { throw new BizException("药品[" + item.getDrugName() + "]库存不足"); } // 写库存流水... } // 3. 更新处方状态为已发药 pres.setStatus("2"); prescriptionMapper.updateById(pres); }

selectByNoForUpdate里的FOR UPDATE是行级锁，防止两个药师同时操作同一张处方的极端场景。虽然实际中一个处方不太可能被两个窗口同时操作，但这种防御性编程可以避免极难排查的并发脏读。

4.4 权限拦截：过滤器链与自定义注解

为了不做每个接口都写权限校验这种蠢事，我实现了基于Spring AOP的自定义权限注解。

@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface RequirePermission { String value(); // 权限编码，如 "charge:add" }

在Controller方法上标注@RequirePermission("registration:add")，然后通过AOP切面在前置通知中获取当前登录用户的角色，再查询角色拥有的权限编码集合，如果包含该权限编码则放行，否则抛出无权限异常。这样做的好处是权限逻辑和业务代码完全解耦，后期新增接口时只需要标个注解，不需要在Controller里重复写if判断。

登录认证采用JWT还是Session？这个我在系统里做了双方案：管理后台页面用Session（配合拦截器判断登录状态），因为浏览器端的页面跳转和会话管理天然适合Session；如果后续要出小程序端，可以加一个面向接口的JWT登录通道。文档里我两种方案的对接示例都写了，方便扩展。

5. 项目工程结构与部署发布：直接拿来用的落地配置

源码拿到手里，最关心的就是怎么跑起来。我这套项目使用Maven进行多模块管理，目录结构如下：

hospital-system/ ├── pom.xml // 父POM，统一依赖版本管理 ├── hospital-common/ // 公共模块：统一返回、异常、工具类 ├── hospital-system/ // 系统管理模块（用户/角色/菜单/日志） ├── hospital-registration/ // 门诊挂号模块 ├── hospital-outpatient/ // 医生工作站模块（接诊/处方） ├── hospital-pharmacy/ // 药房药库模块 ├── hospital-inpatient/ // 住院管理模块 ├── hospital-admin/ // Web入口模块，启动类+配置+静态资源 └── sql/ ├── hospital_init.sql // 建库建表+初始化数据 └── hospital_sample_data.sql // 示例业务数据（科室、医生、药品）

这种多模块拆分适合多人协作开发，每个开发负责一个业务域，互不干扰。如果你是自己做毕设或小团队合作，也可以把所有代码放一个模块里，更省事。

5.1 核心配置文件

开发环境和生产环境我拆分了两个配置文件：application-dev.yml和application-prod.yml，通过spring.profiles.active切换。开发环境用本机MySQL，生产环境用独立的数据库服务器，其他配置基本一致。

server: port: 8090 servlet: context-path: /hos spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hospital_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 hikari: maximum-pool-size: 20 minimum-idle: 5 redis: host: localhost port: 6379 database: 0 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.hospital.**.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

注意serverTimezone=Asia/Shanghai这个参数，如果你漏了，连MySQL 8.0时会报时区错误。allowPublicKeyRetrieval=true则用于解决MySQL 8.0 caching_sha2_password认证插件带来的连接报错，这两个坑几乎每个人都会踩一次。

5.2 部署发布：单体JAR包与Docker两种方式

单体阶段部署我推荐直接打包成可执行JAR。

# 打包（跳过测试） mvn clean package -DskipTests # 后台启动，指定生产环境配置 nohup java -jar hospital-admin.jar --spring.profiles.active=prod > logs/hospital.log 2>&1 & # 查看日志 tail -f logs/hospital.log

如果服务器环境支持Docker，我也提供了简单的Dockerfile和docker-compose.yml，一条命令拉起MySQL+Redis+应用容器。但这里要提醒一句：医院内网环境很多不让用Docker，服务器安全策略极严，可能连外网Maven仓库都访问不了。遇到这种情况，预先在本地用mvn package把JAR包和相关依赖都下好，然后通过内网传输部署即可。在文档里我专门写了一个“离线部署”的小节，把Maven本地仓库打包、内网传输、数据库脚本导入的步骤都列了，照着操作就行。

5.3 数据库初始化

拿到源码后，执行数据库脚本的顺序很重要：

1. 创建数据库：CREATE DATABASE hospital_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
2. 导入初始化脚本：mysql -uroot -p hospital_db < hospital_init.sql
3. 导入示例数据：mysql -uroot -p hospital_db < hospital_sample_data.sql

初始化脚本中包含默认管理员账号（admin / admin123，首次登录强制要求修改密码）和一套默认菜单权限数据。示例数据里有大约20个科室、50位医生、200种常用药品和1万条模拟患者档案，方便直接演示业务流程。

6. 部署上线后的实战踩坑记录：这些问题你多半也会遇到

在这套系统的开发、测试、交付过程中，有几类问题反复出现，我挑典型的写下来，希望帮你省掉排查的时间。

6.1 MyBatis Plus字段自动填充失效

项目中create_time和update_time我原计划用MyBatis Plus的自动填充功能（@TableField(fill = FieldFill.INSERT)），配置了MetaObjectHandler实现类后，却发现批量插入时create_time没被填充。排查后发现原因：批量插入用的是自定义的XML SQL，不是MyBatis Plus内置的insert方法，自动填充只对内置方法生效。

解决方案有两种选择：要么统一走MP内置方法，要么在XML里不写create_time字段，交给数据库的DEFAULT CURRENT_TIMESTAMP自动处理。我在项目里采用的是双保险：实体字段保留自动填充注解，同时数据库字段也设置了默认值，避免哪边漏了导致插入失败。

6.2 金额精度丢失

收费模块出现过一次诡异bug：某张处方三样药品金额分别是0.1、0.2、0.3，合计显示0.6000000000000001。原因很经典：Java的double和float无法精确表示小数，而药品单价、数量、折扣这些乘法运算频繁。

解决方式很粗暴也很有效：所有金额字段从数据库到Java实体、再到运算中间量，全部使用BigDecimal，并且统一用字符串构造函数new BigDecimal("0.1")而不是new BigDecimal(0.1)。数据库端直接decimal(10,2)，从根源上杜绝精度问题。这是金额处理的基本素养，但在CS模式下很多人还是会踩中double的坑。

6.3 医院内网电脑的浏览器兼容问题

这个坑属于实践经验了。给医院交付时发现，很多科室一线电脑还是老旧Windows 7 + IE 11内核的浏览器。Layui的很多组件（比如日期选择器）在IE下的表现并不完美，后来我在前端模板里统一引入了polyfill.io兼容脚本，并且把项目所依赖的渲染方式做了降级处理。如果你用的是Vue等现代框架，这个问题会更头疼，务必在需求阶段先确认客户现场的浏览器环境，别等到上线被一通电话叫回去加班改兼容。

6.4 数据库备份策略

医院的数据安全要求很高。我在文档里补充了数据库自动备份方案：使用Linux的crontab定时任务，每天凌晨2点执行mysqldump导出全量备份，保留最近7天备份文件，同时定期把备份文件异地拷贝到另一台内网服务器。SQL脚本可以直接拿来用，只需要根据实际路径和账号密码略作调整。

#!/bin/bash # 每日凌晨备份数据库，保留7天 BACKUP_DIR=/data/mysql_backup DATE=$(date +%Y%m%d%H%M) mysqldump -uroot -p'password' --single-transaction --routines --triggers hospital_db > ${BACKUP_DIR}/hospital_db_${DATE}.sql find ${BACKUP_DIR} -name "hospital_db_*.sql" -mtime +7 -delete

--single-transaction参数可以保证备份期间不锁表，医院白天业务高峰期也能执行备份，这是生产环境必须用到的参数。

7. 从这套源码基础上还能扩展什么：使用者的下一步建议

如果你拿到这套源码是用于毕业设计，建议你在跑通基础流程后，选一两个方向深化，给答辩增加亮点。这里我根据自己的经验提供几个低成本但效果明显的扩展方向。

7.1 数据可视化：运营统计大屏

医院管理者最关注的是门诊量、营收、科室排行、药品消耗趋势。这个系统目前的统计报表模块虽然能出基础表格，但缺少直观的图表展示。你可以集成ECharts，在管理后台单独做一个“运营分析”页面：今天各科室挂号数量柱状图、近30天营收折线图、药品消耗Top20横向条形图。实现难度不大，前端引入ECharts，后端维护几个统计查询SQL，但对项目观感提升非常明显。

推荐优先实现的SQL优化点：使用MySQL 8.0的窗口函数RANK() OVER (PARTITION BY ...)计算科室营收排行，比传统的分组统计再排序简洁得多。

7.2 线上预约挂号渠道

如果你希望这套系统不止停留在院内局域网，可以扩展一个面向患者的线上预约功能：患者通过微信/支付宝H5页面选择科室、医生和时段进行预约，预约数据入库，院内系统实时展示。这个扩展点在当前医疗场景中非常实用，也契合“互联网+医疗”的大趋势。

接口设计上建议采用前后端分离方式，单独开发一套预约前端，后端复用系统中的科室查询、医生排班查询、号源占用等Service层方法，只需新增符合移动端调用的REST接口即可。注意权限认证方式从Session切换为JWT，并设置合理的有效期。

7.3 消息提醒与待办推送

医院场景里有不少“待办”需求：医生有待处理的住院申请、药房有待审核的领药单、收费处有待退费的申请。这套系统目前这些待办的呈现方式是页面列表。后续可以增加一个消息中心表（his_message），在业务状态变更时向相关角色发送站内信，并在页面顶部展示未读消息数。再进一步可以集成WebSocket实时推送，让用户不用刷新页面就能看到新消息。这个扩展不复杂，但能在实际使用时显著提升用户体验。

8. 项目文档怎么写才不踩坑：源码配套文档的实用主义写法

最后聊聊配套文档。很多人写项目文档喜欢堆模板大段复制官方文档内容，写了跟没写一样。我这里分享下这套系统配套文档的实际组织思路，拿到源码的读者可以对照着快速理解。

文档我拆成三份：

1. 系统设计说明书：包括需求概述、业务流程图（用PlantUML或Visio画的，不是手画草图）、数据库ER图、模块接口设计。重点要画清楚“挂号-就诊-收费-发药”这条主流程的时序图，这是理解整套系统的钥匙。
2. 环境搭建与部署手册：从JDK 1.8、Maven 3.6、MySQL 8.0的安装开始，到IDE导入项目、修改配置文件、启动步骤、常见报错解决（比如端口被占用、数据库连接失败、依赖下载超时等）。目标是让一个从未接触过Spring Boot的人，按照手册最多一小时能把系统跑起来。
3. 测试用例与验收报告：针对核心业务功能的测试用例表，包含用例编号、前置条件、操作步骤、预期结果、实际结果。这个对毕业设计答辩特别重要，能直接证明系统的可用性。

文档写作上有一条忠告：数据库设计说明书里的ER图和表结构说明一定不要只贴SQL建表语句，要为关键字段加上字段含义、取值范围、业务约束的解释。比如状态字段的每个可能值（0表示待收费，1表示已收费等）必须列成枚举表格，否则接手的人很难理解一套业务状态流转逻辑。

我自己写文档的习惯是“每个关键业务动作都配一段文字说明加一个小表”，文字说明解释为什么这么做，小表列出涉及的字段和状态变化。真正有经验的开发都知道，写清楚“为什么”比写“是什么”要重要十倍。

整套系统的源码和数据库在真实项目中的交付形态，就是“源码 + 初始化脚本 + 文档”三者齐备。源码让人看得懂业务实现，数据库脚本让人一键重建环境，文档让人快速上手和二次开发。三者缺一，项目都算不上完整交付。这篇文章把这些关键点都梳理了一遍，希望不论你是毕业设计还是实际项目，都能少走一些我当年走过的弯路。