SpringBoot医院管理系统全栈实战：从架构设计到部署上线

SpringBoot医院管理系统这类项目，说实话在开发者圈子里已经不算新鲜了，但每次看到类似标题我反而会多留意几眼。原因很简单——医院管理系统几乎是SpringBoot全栈开发里最典型的“教科书级”业务场景，它把权限管理、复杂关联查询、事务处理、报表统计这些后端核心知识点全部串在了一起。标题里提到的“1526t”，我理解应该是一套带编号的项目版本或者教学工程标识，具体的版本号意义不用太纠结，重点是这套系统本身覆盖的内容是否完整、代码是否规范、数据库设计是否合理，以及拿到手之后能不能顺利跑起来。

这套系统最实在的价值，是给正在做课程设计、毕业设计，或者刚入行想找一个完整项目练手的开发者，提供了一个可以直接上手、能跑通、能二次开发的基础工程。我自己也接触过很多号称“开箱即用”的管理系统项目，最后真正能省心的并不多，不是数据库脚本缺东少西，就是配置文件藏着私货。这篇博文我会从实际使用的角度，把这个SpringBoot医院管理系统从头到尾拆一遍，把技术选型、数据库设计、核心代码逻辑、调试部署流程，以及我在实操过程中踩过的坑和排查思路，一次性讲明白。

1. 项目整体架构与设计思路拆解

拿到任何一套源码，先别急着双击运行，第一步一定是看整体设计。SpringBoot医院管理系统之所以适合用来学习和做二次开发，本质原因在于它的业务复杂度和框架能力刚好匹配——既不会像电商系统那样一堆分布式中间件让人眼花缭乱，也不会像简单的CRUD项目一样学了等于白学。

1.1 框架层选型：为什么是SpringBoot

SpringBoot在这个项目里承担的是“地基”角色。它让你不用再像传统的SSM项目那样写一堆XML配置，一个spring-boot-starter-web依赖就能把Web环境全部搞定。尤其是内嵌Tomcat这个特性，对新手极度友好，本地启动就是一个main方法，不用单独装Tomcat、不用手动部署war包，大大降低了环境搭建的心理门槛。

在医院管理系统这种典型的管理类应用中，SpringBoot配合Spring MVC处理HTTP请求，配合Spring JDBC或MyBatis操作数据库，再通过Spring Security或者拦截器做权限控制，这套组合拳已经是行业内经过大量验证的成熟方案。选它，不是为了赶潮流，而是因为它最适合这个体量的业务系统。

1.2 业务模块拆解：医院管理系统到底管什么

一个真正能落地的医院管理系统，业务上必须要覆盖这些模块，缺了任何一个都谈不上“完整”：

• 科室管理：医院的科室信息维护，包括科室名称、位置、负责人、简介等。
• 医生管理：医生的基本信息、所属科室、职称、擅长领域、排班信息。
• 患者管理：患者建档，包含姓名、性别、年龄、联系方式、身份证号、既往病史等。
• 挂号管理：患者挂号的整个流程，包括号源管理、挂号记录、退号处理。
• 门诊/病历管理：医生对患者进行诊断，填写病历、开立处方。
• 药品管理：药品的入库、出库、库存管理，药品分类、厂家、有效期等。
• 收费管理：挂号费、药品费、诊疗费等费用的收取和结算记录。
• 系统管理：用户管理、角色管理、菜单权限管理、操作日志等。

这些模块看起来多，但彼此之间的关系并不复杂。患者先挂号，然后找医生问诊，医生开处方，患者到药房取药并缴费——核心业务链路就是一条线。系统开发时，所有表设计和后端接口都是围绕这条业务主线来组织的，这也是为什么我说医院管理系统具有很好的“教学价值”，因为它清晰呈现了一个业务系统从需求分析到落地实现的完整思考路径。

1.3 技术栈与项目结构预览

一般标准的SpringBoot医院管理系统，技术栈大概是这样的（不同项目会有细节出入，但大方向一致）：

• 后端：SpringBoot 2.x、MyBatis/MyBatis-Plus、Spring MVC、Lombok
• 前端：Thymeleaf模板引擎或者Vue.js，配合AdminLTE、Layui等后台管理模板
• 数据库：MySQL 5.7或8.0
• 构建工具：Maven

项目结构上，你大概率会看到这样的包层级：

src/main/java ├── com.example.hospital │ ├── controller # 控制器层，接收HTTP请求 │ ├── service # 业务逻辑层，核心业务处理 │ ├── mapper # 数据访问层，MyBatis接口 │ ├── entity # 实体类，映射数据库表 │ ├── config # 配置类，拦截器、跨域等 │ └── common # 通用工具类、返回结果封装

这种分层结构是最标准的领域分层风格。controller层只负责参数接收和结果返回，service层处理具体业务逻辑，mapper层只管数据库交互。三层各司其职，好处是后期维护时定位问题非常快——接口返回数据不对，先看controller；业务逻辑出错，直接查service；SQL语句有问题，检查mapper。这也是一套合格源码必须有的代码组织素养。

2. 数据库设计详解：核心表结构关系与初始化数据

很多拿到源码就跑不起来的开发者，十有八九是栽在数据库环节。要么是脚本没导入成功，要么是版本不兼容导致SQL语法报错。作为一套完整的医院管理系统，数据库表设计直接决定了整个系统能承载多少业务，这一章我给大家把核心表结构和初始化数据的套路盘清楚。

2.1 核心数据表结构与关联关系

医院管理系统的数据库设计核心在于“患者-医生-药品-收费”这条主链路的表关系，下面这几张核心表，基本上就是一套标准实现的标配：

用户表（sys_user）

这张表保存的是系统登录账号，包含用户名、密码、角色类型（管理员/医生/护士/药师等）、姓名、所属科室、状态等字段。密码一般是MD5加密存储，防止数据库泄露后明文密码直接暴露。

患者表（patient）

患者基本信息表。包括姓名、性别、年龄、身份证号、手机号、家庭住址、过敏史、创建时间等。患者的唯一标识是主键id，业务上身份证号会做唯一约束，避免重复建档。

医生表（doctor）

医生信息表，主键为doctor_id，关键外键是department_id，关联科室表。职称、擅长领域、排班时间段、挂号费用等信息都会在这张表中体现。

科室表（department）

科室表保存医院科室的编号、名称、位置、联系电话、科室主任等信息。医生表和科室表是多对一的关系，一个科室可以有多个医生。

挂号记录表（registration）

这张表非常关键，它记录了每一次挂号的完整信息，包括关联的患者id、医生id、科室id、挂号日期、挂号时段（上午/下午/晚上）、号源序号、挂号费用、状态（已挂号/已就诊/已退号）。设计上可以用一个status字段来区分不同状态，防止出现“号都挂了但医生不知道患者来看诊”的尴尬情况。

处方与处方明细表（prescription、prescription_item）

处方表和处方明细表是一对多的关系。处方主表记录就诊号、患者id、医生id、开单时间、诊断结果、总金额；明细表记录具体开了哪些药、每种药的用量、用法、数量，通过外键prescription_id关联主表。

药品表（medicine）

药品基础信息表，包含药品编码、通用名、规格、生产厂家、批准文号、零售价格、库存数量、有效期等信息。药品出库时扣减库存，低于预警值会提示补货，这也是管理系统基本会带的逻辑。

收费记录表（settlement）

收费表记录每笔费用的来源（挂号费/药品费/诊疗费）、金额、支付方式、操作员、收费时间。它和挂号记录是多对一的关系，和处方记录也是一对一的关系，目的是确保财务数据可追溯。

这几张表协同工作，业务闭环就很清楚了：患者建档 -> 挂号产生挂号记录 -> 医生接诊写病历开处方 -> 处方明细关联药品 -> 收费表记录缴费 -> 药房发药扣库存。表与表之间的外键关联，在这里不是摆设，而是保障数据一致性的关键。

2.2 初始化数据的重要性和必要性

空表能跑通系统吗？技术上能，业务上不行。拿到源码包之后，你一定会看到一个.sql文件，通常是hospital.sql或者init.sql，这个文件极为重要。它做了两件关键的事：

第一件事是建表，把上面讲的这些核心表全部创建出来，同时定义好主键、外键、唯一索引、非空约束。

第二件事是灌入初始数据，包括管理员账号（比如admin/admin123）、测试医生账号、若干科室名称、药品目录、一些模拟患者档案等。没有这些基础数据，系统登录进去后就是一个空壳，连下拉框都是空的，根本无法演示业务流程。

导入初始化数据时，我强烈建议：

先确认MySQL版本再导入脚本。MySQL 5.7和8.0的SQL语法在一些细节上兼容性会有差异，尤其是编码集、索引命名和timestamp字段默认值写法上，容易报错。如果使用的是Navicat等客户端工具，导入之前先手动创建一个hospital数据库，字符集选utf8mb4，排序规则选utf8mb4_general_ci，然后选中该数据库再执行SQL脚本。

2.3 数据库版本与连接配置

mysql的版本选型直接关系到后续连接配置能否成功。我遇到不少列表的项目用的还是MySQL 5.7，但也有一部分已经换到MySQL 8.0。两者的驱动类写法不同：MySQL 5.7的驱动是com.mysql.jdbc.Driver，MySQL 8.0的驱动是com.mysql.cj.jdbc.Driver。SpringBoot项目里现在主流都是用8.0驱动来兼容5.7和8.0版本的数据库，但你要注意一点——如果用8.0的驱动连接5.7的数据库，基本没问题；反过来，用5.7的驱动连8.0的库，大概率会报连接错误。

application.yml中经典的配置长这样：

spring: datasource: url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

网上很多人抱怨启动时报错Public Key Retrieval is not allowed，就是因为MySQL 8.0默认采用caching_sha2_password插件认证，客户端首次连接时需要获取公钥，驱动层面没有放行。解决方式就是在url后面加上allowPublicKeyRetrieval=true，实际操作中这句配置几乎成了标配。

serverTimezone=Asia/Shanghai也不可少，否则你用中国时区存的数据，数据库引擎按UTC时区解析，时间字段会整体差8个小时，到时候查看挂号时间或收费时间，会有一堆让你怀疑人生的数据误差。

3. 核心功能实现与关键代码逻辑剖析

有了数据库基础，接下来就是整个系统的“发动机”——后端代码。拿到源码之后，不要急着满世界找文档，直接从controller层入手，跟着接口一个个往下看，很快就能摸清系统的运转脉络。这一章我会挑几个最核心的功能模块，告诉大家实现方式以及为什么要这么写。

3.1 统一返回结果封装与异常处理

打开源码，你最先看到的应该是common包里的Result类。它做的事情非常简单：把接口返回值统一包装成{code, msg, data}的JSON格式。前端页面或者小程序端拿到这种结构的响应数据后，只管按照约定好的code去判断请求是否成功，不用关心具体返回了什么结构，极大降低前端和后端的沟通成本。

public class Result<T> { private Integer code; 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加@ExceptionHandler实现。这样做最大的好处是，service层只要专注业务判断，遇到参数非法、数据不存在等情况直接throw new CustomException("...")，全局异常处理器会自动捕获并转成标准错误响应返回给前端。你反正记住一句话：好的系统设计，一定是让核心业务代码尽量干净，把通用逻辑下沉到框架层面。

3.2 登录认证与权限拦截实现

医院管理系统这种有角色差异的系统，登录权限是必须有的。一般的实现方案有两种：一种是用JWT生成token，每次请求带上token，后端用拦截器校验；另一种是传统的Session方式，登录成功后把用户信息放进session，之后通过拦截器校验。

目前主流的SpringBoot项目都偏爱JWT方案，因为它是无状态的，方便前后端分离部署。核心流程大致是：用户提交用户名密码 -> 后端查库验证 -> 验证通过后生成JWT并返回 -> 前端把token存起来（localStorage或内存） -> 之后每次请求在header中带Authorization: Bearer token -> 后端登录拦截器解析token并放行。

如果你在源码里看到类似TokenInterceptor或者AuthInterceptor这样的类，就是这个机制的实现。拦截器类一般会实现HandlerInterceptor，并在preHandle方法里做放行判断：

@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token) || !jwtUtil.verifyToken(token)) { response.setStatus(401); return false; } // 解析token，获取当前登录用户信息，放入ThreadLocal return true; }

这里有个细节值得注意：拦截器里放行路径和拦截路径一定要配置清楚，比如login接口必须放行，静态资源（css/js/图片）也要放行，否则页面会出现“明明能打开但就是没样式”的诡异现象。

3.3 挂号流程的实现逻辑

挂号流程是医院管理系统的核心业务节点之一。代码实现上，挂号接口大多集中在RegistrationController中，核心逻辑是在RegistrationService中体现。流程大概是：

1. 前端提交挂号请求，带上患者id、医生id、挂号时段、费用。
2. 后端先校验该医生当前时段是否还有剩余号源。
3. 检查患者是否存在未就诊的重复挂号记录，防止恶意占号。
4. 满足条件后，生成一条挂号记录，状态为“已挂号”。
5. 如果有排班表，同步扣减该医生当前时段的剩余号源数量。
6. 返回挂号成功的信息给前端，包括排队号、就诊科室位置等。

这段逻辑不长，但涉及多个表的写入操作，强烈建议加上@Transactional事务注解。一旦后面的扣减号源失败，前面的挂号记录插入也必须回滚，否则就会出现“挂上了号但医生那边号源没减”的数据不一致问题。

3.4 MyBatis/MyBatis-Plus架构下的CRUD实操

很多项目的mapper层会直接用MyBatis-Plus，这个框架对单表CRUD极其友好——你只需要让Mapper接口继承BaseMapper<T>，简单的方法名（selectById、insert、deleteBatchIds）全部都自动帮你实现好了，连SQL都不用写。这种设计在管理系统里特别合适，因为大量操作就是围绕某一个业务实体的增删改查。

比如医生管理的Service层，核心代码可能就几个方法：

public interface DoctorService extends IService<Doctor> { Page<Doctor> getDoctorPage(int pageNum, int pageSize, String keyword); // 其他自定义方法 }

利用MyBatis-Plus的QueryWrapper，可以非常灵活地拼接查询条件：

LambdaQueryWrapper<Doctor> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), Doctor::getName, keyword) .eq(Doctor::getDeptId, deptId);

LambdaQueryWrapper既有类型安全，又能在条件为空时自动跳过该查询条件，避免了手写一堆if判断拼SQL的丑陋代码。对新手来说，掌握QueryWrapper的用法，差不多就等于掌握了MyBatis-Plus一大半的精髓。

碰到复杂的查询，比如“统计某科室某月的挂号量、收入、药品消耗”，MyBatis-Plus就不太适合硬写了，这时候通常会在Mapper接口写自定义SQL，使用@Select注解，或者搭配XML文件：

@Select("SELECT COUNT(*) FROM registration WHERE department_id=#{deptId} AND DATE_FORMAT(reg_date, '%Y-%m') = #{month}") int countByDeptAndMonth(Long deptId, String month);

源码里两种方式都有可能出现，不管用的是哪种，DATEPART这种日期函数在不同版本数据库中的写法有差异，如果要迁移数据库，这里要重点检查。

4. 调试部署全流程实录：从环境准备到跑通上线

终于到了大家最关心的章节——怎么把这套系统从代码变成能跑的服务。我说一个统计数字：市面上源码包能打开但跑不起来的，至少占五成以上，原因大多是环境不匹配或者傻傻分不清路径。这一章我按实际操作顺序，从上到下给你完整走一遍。

4.1 开发环境清单及安装校验

先把环境备齐，版本尽量贴近项目原始开发环境：

• JDK：1.8版本优先，个别项目需要JDK 11+，查看pom.xml里java.version的值
• Maven：3.6以上，需要配置阿里云镜像，否则下载依赖可能让你等到怀疑人生
• MySQL：5.7或8.0，建议直接用8.0，兼容性相对更好
• IDE：IntelliJ IDEA 2020以上版本
• Navicat或MySQL Workbench：数据库可视化操作工具

Maven的settings.xml里配置阿里云镜像，位置一般在Maven安装目录conf/settings.xml或者用户目录的.m2/settings.xml。配置内容很简单：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>aliyun maven</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

这一步极其关键，直接用默认中央仓库拉SpringBoot依赖，那个速度在没有外网加速的环境下会让你崩溃。经验之谈，别在这上面浪费时间。

4.2 IDEA导入项目的正确方式

IDEA导入SpringBoot项目，路径选错了会有一堆奇怪的错误。正确做法是：

打开IDEA -> File -> Open -> 选择项目根目录（就是pom.xml所在的目录） -> 选择Open as Project -> 等待Maven自动导入依赖。

导入后，检查一下右侧Maven面板里依赖是否全部下载成功。如果有红色波浪线，大概率是某个依赖下载失败或者版本冲突。这个时候先执行mvn clean，再执行mvn package -DskipTests把整个工程重新构建一遍，看具体报错信息。

4.3 关键配置文件的修改与启动技巧

找到src/main/resources目录下的application.yml或application.properties，把下面三处配置改成你自己的：

1. 数据库名和账号密码
2. 端口号（默认一般是8080，如果被占用就改成8081/9090等）
3. 日志输出路径（防止因为没有对应目录导致启动失败）

修改完成，找到启动类的main方法，直接运行。看到类似下面的日志，就说明启动成功了：

Tomcat started on port(s): 8080 (http) Started HospitalApplication in 5.23 seconds

浏览器地址栏输入localhost:8080，如果项目带了管理后台前端页面，你就能看到登录页了。有些项目把前端单独打包，接口和页面是分开部署的，这种情况下要先看源码里的README或doc目录说明，通常会有部署文档。

4.4 打包部署到服务器的生产实践

本地跑通了，下一步是部署到服务器给更多人用。SpringBoot内置Tomcat，所以部署非常简单：在项目根目录执行

mvn clean package -Dmaven.test.skip=true

打包完成后，target目录下会生成一个xxx.jar文件。把这个jar包上传到服务器，再用命令启动：

java -jar hospital-system.jar

生产环境千万别直接用这种方式启动，因为一旦关闭SSH会话，进程就断了。正确姿势是用nohup方式后台运行：

nohup java -jar hospital-system.jar > logs/app.log 2>&1 &

日志输出到logs/app.log，排查问题时直接tail -f logs/app.log就能看到实时的运行情况。服务器开了防火墙的话，还要确保对应端口是放行的，不同云平台的安全组规则也要单独配置。

部署环境上还有一个小坑：云服务器的MySQL默认可能只允许localhost连接，你的SpringBoot应用要连数据库，必须授权允许远程访问对应账号，或者干脆把应用和数据库部署在同一台机器，用localhost连接。

5. 常见问题与排查技巧实录

这部分我想把我在实操中频繁踩到的坑集中列一下。这些东西是网上文档很少写清楚的，但却是确保你能顺利跑起来的“潜规则”。

5.1 启动阶段常见报错速查表

我先整理一个高频问题排查表，每一行都是我亲眼见过的案例：

这个表请直接收藏，后面跑项目的时候遇到报错，对照着排查，比自己盲试高效十倍。

5.2 页面样式丢失或接口403的幕后真凶

我遇到过一个典型场景：项目能启动，登录页也能打开，但整个页面所有CSS和图片全部失效，控制台一堆net::ERR_ABORTED 404错误。排查后发现，原因在于Spring Security或拦截器把静态资源路径给拦截了。

如果你用的是Spring Security，正确放行方式是：

@Override public void configure(WebSecurity web) { web.ignoring().antMatchers("/css/**", "/js/**", "/images/**", "/favicon.ico"); }

如果是拦截器，那就要在addInterceptors的excludePathPatterns里把所有静态资源路径都排除掉：

registry.addInterceptor(authInterceptor) .addPathPatterns("/**") .excludePathPatterns("/login", "/css/**", "/js/**", "/images/**");

另一个常见403场景是跨域问题。如果你使用了前端分离的开发模式，前端跑在8081端口，后端接口跑在8080端口，那么前端请求后端必然存在跨域。这时候后端需要开启跨域支持。实现方式是在配置类里加一个WebMvcConfigurer，重写addCorsMappings方法：

registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowCredentials(true) .maxAge(3600);

跨域报错有个迷惑点，就是浏览器控制台报的是CORS error，但后端日志里可能根本没有对应请求记录。因为浏览器在发出正式请求之前，会先发一个OPTIONS预检请求，后端没有正确处理OPTIONS时，正式请求压根不会到达后端。以上配置把这个路打通了就好。

5.3 排查日志的正确姿势：从“瞎改”到“精准打击”

遇到问题不要急着改代码，先看日志。SpringBoot默认的日志输出已经足够定位大部分问题。启动时如果报错，立即翻看控制台最底部的Caused by行——这是问题的真正根源所在，上面那一大堆异常堆栈只是表象。

还有一个非常实用的技巧：临时把日志级别调成DEBUG。在application.yml里加一行配置：

logging: level: com.example.hospital.mapper: debug

这样MyBatis的SQL执行日志就会全部打印出来，你可以清楚看到每条SQL实际执行的参数和结果，几乎所有数据查询问题都能在这个层面发现。定位到具体问题之后，再改回INFO级别，避免生产环境日志刷屏。

5.4 源码二次开发时必避的三大雷区

如果你打算在这个系统上进行二次开发，把毕业设计或者课程设计往上叠加功能，下面这三点务必注意：

第一，不要随意修改数据库表的主键类型和长度。一旦改动，所有关联的外键都要同步，工作量远超预期。哪怕只是把int换成bigint，在数据量大的表上也可能引发连锁的头疼问题。

第二，新增接口时务必遵循原有代码分层。Controller只管接收参数和返回结果，Service层写业务逻辑，Mapper层负责SQL。图省事把业务逻辑全写在Controller里，短期看起来快，后期维护就是一场灾难。

第三，密码加密方式不要轻易更换。原项目如果用的是MD5，你新增用户时也保持MD5（或者项目里的实际加密方式），否则会出现老账号能登录、新账号永远登不进去的窘境。如果要升级为BCrypt，请把默认账号的密码一起重新生成并更新到数据库里。

6. 项目优化建议与经验心得

跑通只是第一步，能把系统种优化到接近生产可用的水平，才是这套源码真正的价值所在。基于医院管理系统的业务特点，有四个方向值得花时间研究。

6.1 安全加固：从“能登录”到“放心上线”

教育项目或课设项目，安全往往是配角，大部分密码MD5加密后就直接存储了。但如果你对标真实医院信息化系统的要求，MD5已经远远不够，至少在密码存储这一层要换成BCrypt或者加盐的SHA-256。

接口层面，除了登录接口，其他所有接口尽量都走登录拦截验证。如果系统涉及患者身份证号、家庭住址这些敏感信息，建议再加一层操作日志记录，谁在什么时间查看了哪个患者的档案，全部留存下来。医疗数据合规是大趋势，提前动手做没有坏处。

6.2 前端体验优化的补全方向

老式前后端不分离的管理系统，页面观感往往比较“复古”。如果对这个项目的前端界面不满意，预算有限的情况下，优先考虑换一套现有的后台管理UI模板，比如Vue3 + Element Plus的新一代管理界面，保留后端接口不动，只重写前端页面。接口返回格式已经用统一Result封装的话，对接起来非常顺手。

如果不想动前端，也可以小幅优化原页面的布局和交互——改logo、换主题色、加上Loading状态和提示弹窗，这些改动对于代码量的增加极其有限，但整体质感提升非常明显。

6.3 性能考虑：数据量变大后怎么办

医院管理系统的数据量增长不算夸张，但如果运行一段时间，挂号记录和收费记录表会积累大量数据。这时候建议在查询频率高的字段上建立索引，比如registration表的patient_id、doctor_id、reg_date字段，settlement表的create_time字段。

再往后，可以给统计类报表增加定时缓存，在每天的凌晨计算一次前一天的汇总数据，存到单独的统计表，白天查询直接走汇总表，比把所有明细聚合计算一遍快几个数量级。

6.4 我的最终使用建议

SpringBoot医院管理系统作为学习项目，我认为最大的收获不是“我跑通了一个系统”，而是完整经历一次“从架构认知到功能落地”的过程。我第一次拿到类似项目时，光是把数据库脚本成功导入、解决掉时区问题、让页面正常显示，就花了一个下午。但正是这些折腾，让我真正理解了application.yml里每一行配置的含义，也让我在后来的工作中能更快定位线上问题。

现在这个项目跑通了之后，建议你给自己设定一个小目标：不要停留在跑通的层面，随便挑一个模块，比如“退号”功能，从需求分析、表设计、后端接口、前端页面到联调，独立实现一遍。这个过程走过的每一个坑，都会比你看十篇教程都值钱。技术这东西，不动手永远只是听过，动过手才是自己的。