SpringBoot医院住院管理系统设计与实现全指南

1. 项目概述与价值分析

做计算机毕业设计选方向，最怕的不是题目难，而是题目看起来大、实际做起来空，或者做完之后自己都说不清楚做了什么。医院住院管理系统这个题目属于典型的中等复杂度Web应用——它不涉及算法攻坚，不依赖硬件环境，但也不是简单增删改查能糊弄过去的。它恰好卡在一个黄金位置：业务模型足够清晰，功能模块足够丰富，技术栈足够主流。用SpringBoot做后端、配合Vue或Thymeleaf做前端，既能体现工程化能力，又不至于因为题目太偏导致答辩时被问住。

这个系统解决的核心问题其实很接地气：住院部日常运作中，患者从办理入院到出院结算，中间要经历病房分配、医生查房、医嘱下达、护士执行、用药记录、费用核算等一系列流程。传统手工管理或者Excel管理方式下，信息分散在各个纸质单据里，护士站和医生办公室之间靠喊、靠跑、靠传纸条，效率低不说，还容易出错。床位使用情况没人能实时说清楚，患者费用明细对不上账，药品库存和医嘱脱节——这些都是真实存在且高频发生的痛点。

从毕业设计的角度看，这个选题有几个明显优势：第一，业务场景完整，患者管理、床位管理、医嘱管理、费用管理、药品管理、系统管理，每个模块都有清晰的CRUD逻辑可做；第二，数据模型有设计空间，多张表之间的关联关系可以体现数据库设计能力；第三，技术点容易展开，文件上传、分页查询、权限控制、定时任务、报表统计，随便挑几个都能展示工作量；第四，答辩时能讲的东西多，需求分析、功能设计、数据库设计、核心逻辑实现，每一块都有丰富的素材可以讲明白。

适合拿这个题目的人群也很明确：Java基础已经有了、想找一个综合性项目来串联SpringBoot知识点的同学；或者已经参加工作、想系统梳理一遍Web开发全流程的开发者。如果你只想找一个"最简单的管理系统模板"换个名字就交，那这个题目对你来说反而偏难——它的表结构至少十几张，关联关系也复杂，硬要简化反而会显得不专业。

下面我按实际操作顺序，把整个系统的设计思路、建表方案、核心功能实现、踩坑经验一次性讲清楚。这些内容不是从文档里抄出来的，是我实际做过类似项目之后总结出来的。

2. 核心功能模块与数据库设计思路

2.1 功能模块拆解

住院管理系统不管怎么包装，核心功能域跑不出下面这六大块：患者入出院管理、病房与床位管理、医生医嘱管理、护士执行与护理记录、药品与费用管理、系统用户与权限管理。毕设答辩时最忌讳的就是把系统说成"管理患者的系统"，那样太单薄。你要讲的是"围绕患者住院全流程的信息化管理平台"。

• 患者入出院管理：入院登记、病房分配、住院病历建立、出院办理、转科记录。这块是整个系统的主线，其他所有模块都围绕患者状态展开。
• 病房与床位管理：病房信息维护、床位状态管理（空闲/占用/维修）、患者换床操作。这里有一个隐含需求——床位状态必须和患者住院状态联动，不能出现病人在住院但床位显示空闲的情况。
• 医生工作站：医嘱开立、医嘱停用、查看患者病历、查房记录维护。医嘱类型要区分长期医嘱和临时医嘱，这是个专业考点，答辩时能讲清楚加分。
• 护士工作站：医嘱执行确认、护理记录登记、患者生命体征录入。
• 药品与费用管理：药品库存台账、发药退药记录、住院费用录入与汇总、费用明细查询。
• 系统管理：用户管理、角色管理、菜单权限管理、操作日志。这块可以直接套用RBAC模型。

2.2 数据库表结构设计要点

数据库设计是这个项目的重头戏，评阅老师和答辩老师大概率都会盯着ER图问。我直接给出一套经过验证的核心表结构，并标注关键字段逻辑，让你少走弯路。

患者信息表（patient）

• patient_id：主键，建议用自增或雪花ID，不要用患者身份证号做业务主键，因为隐私保护要求决定了身份证号必须加密存储。
• admission_status：住院状态字段，建议用tinyint存0/1/2（0-待入院，1-在院，2-已出院）。这个字段几乎是所有业务查询的过滤条件，务必加索引。

病房表（ward）和床位表（bed）
这两个表要分开建。ward存病房号、所属科室、病房类型（普通/重症/隔离），bed表存病房ID、床位号、床位状态。床位状态不要直接存"空闲/占用"这种字符串，用tinyint映射，占用时关联当前患者ID。实际项目里踩过坑：如果床位表不冗余患者ID，换床时得靠住院记录反查，SQL会绕很多，性能也差。

住院记录表（hospitalization）
这张表是整个系统的事实表，所有业务都围绕它展开。关键字段包括：患者ID、入院时间、出院时间、入院科室、当前病区、床ID、主治医生ID、责任护士ID、住院状态。一个患者多次住院，就是多条住院记录。报表统计"出院人数""在院人数"时直接查这张表即可。

医嘱表（medical_order）
医嘱表要区分长期医嘱（order_type=0）和临时医嘱（order_type=1）。字段上必须有：医嘱内容、开立医生、开立时间、停止时间、医嘱状态（执行中/已停止）、关联的住院记录ID。为什么要单独做医嘱执行子表？因为一条长期医嘱每天可能要执行多次，比如"每天三次每次一片"，如果用一条记录表示，无法追踪每次执行情况。

药品表（drug）和药品库存表（drug_stock）
如果系统包含药房管理模块，建议拆成药品基础信息表和药品出入库流水表。药品基础表存通用名、商品名、规格、剂型、生产厂家；库存表记录每次入库、出库数量变化。发药时自动扣减库存，这个操作要放在事务里，否则并发出药时库存数量会出偏差。

费用表（expense）
住院费用一般拆成费用类别（药品费、检查费、治疗费、床位费、护理费）和费用记录。做日结汇总时按住院记录ID分组求和就好。床位费建议在出院结算时按住院天数统一计算，比每日定时任务更简单可靠。

用户与权限表（user、role、menu）
标准三张表加两张关联表。密码不能用MD5明文哈希，必须加盐做BCrypt加密，SpringSecurity直接支持。

下面给出一段用户表和角色表的核心建表SQL，可以直接作为参考模板：

sql复制CREATE TABLE `sys_user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '登录账号',
  `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码',
  `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名',
  `user_type` tinyint(4) DEFAULT NULL COMMENT '1-医生 2-护士 3-管理员',
  `status` tinyint(4) DEFAULT '1' COMMENT '1-启用 0-禁用',
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.3 为什么选择这三层数据模型

很多同学拿到需求后，习惯性按界面去建表：用户管理建一张用户表，床位管理建一张床位表，费用管理建一张费用表。这样做出来的系统，表之间没有业务关系，报表统计几乎做不出来，代码也全是一搜一大把的重复CRUD。

我的建议是引入"主数据 + 业务单据 + 流程状态"三层意识：患者、病房、床位、药品属于主数据，生命周期稳定；住院记录、医嘱、费用流水属于业务单据，围绕主数据产生；而每个业务单据的核心字段里，必须包含一个状态字段，记录流程走到了哪一步。这样设计的好处是，每个业务动作在代码层面都对应"创建单据→修改状态"两步，逻辑清晰且便于追溯。

比如办理入院这个动作，不是"往患者表插一条记录"这么简单。它实际要做的事情是：判断床位是否空闲→更新床位状态为占用→创建一条住院记录（状态为在院）→更新患者状态为在院。如果某一步失败，前面的操作必须回滚。这一串操作放在一个事务方法里，在答辩时可以顺势讲清楚Spring的@Transactional事务传播机制，这是面试和答辩里的高频考点。

3. 开发环境搭建与核心技术选型

3.1 技术栈版本选择避坑指南

SpringBoot的版本选择，是很多初学者项目跑不起来的第一大坑。目前网上能找到的大部分教程基于SpringBoot 2.x，但很多新初始化的项目默认拉取的是3.x版本。3.x要求JDK17及以上，如果你的本机还是JDK8，会让环境配置变得很纠结。

我给一套稳妥的组合，按这个搭配基本不会出大问题：

SpringBoot版本太高带来最典型的问题就是javax命名空间迁移到jakarta。SpringBoot3.x里原本的javax.servlet、javax.validation全部变成jakarta.*前缀，如果还用旧教程的习惯去导入包，编译直接报红。如果你不想在毕业设计阶段花时间处理这种迁移问题，老老实实留在2.7.18。

用start.spring.io生成项目骨架时，注意Dependency面板不要一股脑全勾上。建议只加Spring Web、Spring Data JPA（或MyBatis）、MySQL Driver、Lombok这四个起步依赖，后面需要什么再加什么。一个干净的起步项目比一个堆满依赖但不知道干什么用的项目好得多。

3.2 SpringBoot项目基础骨架搭建

初始化过程用IDEA最省心，操作路线上我建议：新建Spring Initializr项目→填好Group和Artifact→Java版本选8→依赖勾选Web、MyBatis、MySQL Driver、Lombok→ Finish。

项目生成之后，先别急着写业务代码。第一步应该做统一返回结构和全局异常处理，这是后期开发效率的分水岭。没有统一返回结构，每个Controller方法都要自己拼Map返回，二十个接口写下来手都能写酸。用一个通用泛型类R作为所有接口的返回包装，里面放三个字段：code（业务状态码）、message（提示信息）、data（响应数据）。

java复制@Data
public class R<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> R<T> ok(T data) {
        R<T> r = new R<>();
        r.setCode(200);
        r.setMessage("success");
        r.setData(data);
        return r;
    }

    public static <T> R<T> fail(String message) {
        R<T> r = new R<>();
        r.setCode(500);
        r.setMessage(message);
        return r;
    }
}

全局异常处理同样要趁早做。项目开发过程中，空指针、SQL异常、参数校验失败都是家常便饭，如果没有兜底处理器，异常堆栈直接抛给前端，接口返回的不是标准结构，前端同学就没法判断错误。用@RestControllerAdvice注解定义一个全局异常捕获类，捕获Exception后返回R.fail(e.getMessage())，开发阶段这个优化能帮你省下一个晚上。

整合MyBatis-Plus时，有一个跨普遍到的坑：MyBatis-Plus默认会把驼峰命名的实体字段映射为下划线数据库字段，但如果你恰好字段开头大写或者存在特殊场景，映射会失败。建议在application.yml中显式开启驼峰映射配置，并且实体类字段和数据库表字段严格按驼峰、下划线一一对应。

yaml复制mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

日志配置里那个log-impl值得保留，开发阶段开启控制台SQL打印，调试效率能翻倍。上线前去掉即可。

4. 核心功能实现与关键业务流程梳理

4.1 入院登记与床位分配联动实现

整个系统里业务流程最典型的就是入院登记。不做联动的话，它就是单纯往住院记录表插一条数据，但实际业务里，这个操作牵扯到床位状态、患者状态和住院记录三条数据的一致性。

我先说实现思路：前端页面展示的床位列表必须实时反映床位状态，点击"空闲"的床位可选中，然后带着床位ID和患者ID提交入院申请。后端Service层接收请求后，需要按顺序完成以下操作：

• 校验该患者当前是否存在未出院的住院记录，避免重复入院；
• 校验床位状态是否为0（空闲），防止多人并发抢占同一张床；
• 更新床位表状态为占用（1），并写入患者ID；
• 更新患者表住院状态为1；
• 创建住院记录，默认状态为在院。

由于这五步必须同时成功或同时失败，方法上要加@Transactional(rollbackFor = Exception.class)。不要只写@Transactional，默认只捕获RuntimeException，如果你的代码抛的是自定义的检查异常，事务不会回滚，这个细节很多教程忽略、但实际里校验失败时容易漏。

关键代码可以这样实现：

java复制@Transactional(rollbackFor = Exception.class)
public void admission(AdmissionDTO dto) {
    // 1. 校验患者
    Patient patient = patientMapper.selectById(dto.getPatientId());
    Assert.notNull(patient, "患者不存在");
    
    // 2. 检查是否已有在院记录
    Integer count = hospitalizationMapper.selectCount(
        new LambdaQueryWrapper<Hospitalization>()
            .eq(Hospitalization::getPatientId, dto.getPatientId())
            .eq(Hospitalization::getStatus, 1));
    Assert.isTrue(count == 0, "该患者已有在院记录，不能重复办理入院");
    
    // 3. 校验并锁定床位
    Bed bed = bedMapper.selectById(dto.getBedId());
    Assert.notNull(bed, "床位不存在");
    Assert.isTrue(bed.getStatus() == 0, "该床位已被占用");
    
    // 4. 更新床位
    bed.setStatus(1);
    bed.setPatientId(patient.getId());
    bedMapper.updateById(bed);
    
    // 5. 更新患者状态
    patient.setAdmissionStatus(1);
    patientMapper.updateById(patient);
    
    // 6. 创建住院记录
    Hospitalization hospitalization = new Hospitalization();
    hospitalization.setPatientId(patient.getId());
    hospitalization.setBedId(dto.getBedId());
    hospitalization.setWardId(bed.getWardId());
    hospitalization.setAdmissionTime(LocalDateTime.now());
    hospitalization.setStatus(1);
    hospitalizationMapper.insert(hospitalization);
}

代码里每个业务动作都有前置校验，这个习惯一定要养成。没有校验的入参会直接污染数据库里的核心数据，后面排查问题时要花更多时间来回倒数据。

出院办理是入院流程的逆操作，但也有自己的特有逻辑：释放床位时要先校验该床位当前是否确实关联了该住院记录；住院记录状态置为2已出院时，要补上出院时间和出院结算费用。床位的释放放在事务最后，避免病人还没出院、床位提前释放给下一个患者的不合理情况。

4.2 医嘱管理与护士执行拆分实现

医嘱管理是医疗业务里最有区分度的一个模块。很多毕设系统把医生和护士的操作合并成一揽子功能，看起来省事，但实际上违背了医疗分级操作的专业逻辑。

我的设计是医生端和护士端分开。医生登录后看到的是自己名下患者的列表，点击某个患者查看病历信息，然后开立医嘱。护士登录后看到的是待执行医嘱的列表，护士确认执行后医嘱才进入"已执行"状态。

医嘱表的核心设计上，我建议加两个字段来区分执行状态：status（0-未执行 1-执行中 2-已停止）和execute_status（0-待执行 1-已执行）。对于长期医嘱，每天会产生多次执行记录。为追踪每次执行情况，需要额外建一张医嘱执行记录表medical_order_execute，每条记录关联医嘱ID和执行护士ID：

java复制@Entity
@Table(name = "medical_order_execute")
public class MedicalOrderExecute {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private Long orderId;        // 关联医嘱表
    private Long executeNurseId; // 执行护士ID
    private LocalDateTime executeTime; // 执行时间
    private String executeRemark;    // 执行备注
}

护理记录也是一张核心业务表。护士可以按患者维度或按时间维度登记护理操作，比如体温测量记录、输液记录、特殊护理记录。这张表建议包含字段：住院记录ID、护理项目、护理内容、操作护士、护理时间。可以做一个按住院记录ID查全部护理记录的前端接口，配合时间倒序排序，方便护士站快速回看。

我实际开发中踩过的一个坑是：医嘱执行确认时只做了插入执行记录，忘记修改医嘱表的execute_status状态。结果护士操作三次之后，医嘱记录仍显示"待执行"，后续执行列表越积越长，这个bug靠看日志才定位到。所以在拆分操作时，务必记住每个业务动作都必须有"写主表状态 + 记录流水"的双写设计，不可只记录流水导致医生端看到的还是未执行。

4.3 床位状态展示的实时刷新思路

住院部大屏或护士站页面里，床位分布图通常是系统的门面。这块如果做得好看且数据准确，答辩演示效果会非常加分。前端可以做一个房间床位矩阵图：每个病区一栏，病房按顺序排列，病房里显示床位小方块，空闲显示绿色，占用显示黄色，维修显示灰色。

实际实现时，前端的轮询刷新方案更稳：页面每隔10秒调用一次床位状态查询接口，返回当前病区的所有床位状态列表。利用轮询而不是WebSocket技术的原因在于——毕设项目通常不需要处理高并发实时推送，轮询实现简单、容易稳定运行，答辩演示时也不会因为网络断连导致页面卡死。

查询接口可以一次查出关联信息：

java复制@GetMapping("/ward/status")
public R<List<WardStatusVO>> getWardStatus(@RequestParam String deptCode) {
    List<WardStatusVO> result = wardService.listWardStatus(deptCode);
    return R.ok(result);
}

VO里除了病房ID、房间号、病房类型，还包含床位列表。每个床位对象里包含床位号、床位状态、当前患者姓名。如果当前床位被占用，前端展示患者姓名并支持点击查看详情，点击后跳转患者住院详情页。这个细节能极大提升答辩展示的完整感。

5. 关键接口设计、权限控制与常用补充技术

5.1 权限控制的常见实现方式与选型比较

住院管理系统涉及三类主要用户：医生、护士、管理员。如果不做权限控制，所有登录用户都能访问所有接口，这在毕设答辩时一定是一个被追问的弱点。权限控制最简单可行的方案是SpringSecurity + JWT，它仍然是当前企业级应用最常见的组合。

网上毕设项目关于SpringSecurity + JWT的完整教程很多，但核心思想可以简化成一句话：登录验证成功后，后端签发一个包含用户ID和角色信息的Token，前端后续请求在Header中携带这个Token，后端通过拦截器解析Token并判断当前用户是否有权限访问该接口。

需要注意的是，SpringBoot版本和Security版本之间也有适配问题。用SpringBoot 2.7.x时，Security的版本一般自动依赖5.7.x，配置方式和6.x差别很大，我建议直接在pom里锁定版本，跟着2.7的教程走，别追新。SpringSecurity 6的配置类写法改成了LambdaDSL，网上很多老代码直接抄会编译不过。

实际做一个可用的权限控制方案，我推荐用拦截器 + 自定义注解的方式替代完整框架接入（如果想快速演示的话）。自定义一个@RequireRole注解，加在Controller的方法上，然后写一个HandlerInterceptor，在请求进入Controller前校验当前用户的角色是否匹配。这种方式代码量更少，也更容易在答辩时讲到点上。

核心拦截器代码模板如下：

java复制@Component
public class RoleInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) 
            throws Exception {
        // 放行OPTIONS预检请求
        if ("OPTIONS".equals(request.getMethod())) {
            return true;
        }
        // 从Header中获取Token，解析用户信息
        String token = request.getHeader("Authorization");
        if (StringUtils.hasText(token) && token.startsWith("Bearer ")) {
            String realToken = token.substring(7);
            // 解析JWT获取用户角色
            Claims claims = Jwts.parser()
                .setSigningKey(SECRET_KEY)
                .parseClaimsJws(realToken)
                .getBody();
            String role = claims.get("role", String.class);
            
            // 获取方法上的注解，判断角色是否匹配
            if (handler instanceof HandlerMethod) {
                HandlerMethod handlerMethod = (HandlerMethod) handler;
                RequireRole requireRole = handlerMethod.getMethodAnnotation(RequireRole.class);
                if (requireRole != null && !role.equals(requireRole.value())) {
                    response.setStatus(403);
                    response.setContentType("application/json;charset=UTF-8");
                    response.getWriter().write("{\"code\":403,\"message\":\"无权限访问\"}");
                    return false;
                }
            }
            return true;
        }
        response.setStatus(401);
        return false;
    }
}

用自定义注解的好处是语义清晰，比如删除患者数据的接口上加个@RequireRole("ADMIN")，答辩时能自然地引到"设计上的考虑"，比单纯说"我用了SpringSecurity"更能体现理解深度。

5.2 数据库查询常用增强技巧与多表组装

住院管理系统的数据查询模型大多是多表关联的，比如"查询科室下的所有在院患者，展示患者姓名、病房号、床位号、主治医生、入院时间"。如果从头自己写SQL拼接，工作量大且容易出错。

用MyBatis-Plus的LambdaQueryWrapper做单表过滤非常方便，但多表DQL还是要靠自定义SQL去完成。建议用注解@Select直接写在Mapper接口上，简单直观且不需要XML配置。

java复制@Select("SELECT p.patient_name, p.gender, w.ward_no, b.bed_no, " +
        "u.real_name AS doctor_name, h.admission_time, h.id AS hospitalization_id " +
        "FROM hospitalization h " +
        "LEFT JOIN patient p ON h.patient_id = p.id " +
        "LEFT JOIN ward w ON h.ward_id = w.id " +
        "LEFT JOIN bed b ON h.bed_id = b.id " +
        "LEFT JOIN sys_user u ON h.doctor_id = u.id " +
        "WHERE h.status = 1 AND h.ward_id IN (SELECT id FROM ward WHERE dept_id = #{deptId}) " +
        "ORDER BY h.admission_time DESC")
List<HospitalizationVO> listInHospitalPatients(@Param("deptId") Long deptId);

会写连接查询是基本功，但更值得讲的是"分页查询怎么处理"。MyBatis-Plus的Page<T>对象可以传入自定义SQL查询中，配合其自带的分页插件，自动生成limit语句。

java复制IPage<HospitalizationVO> page = new Page<>(current, size);
IPage<HospitalizationVO> result = hospitalizationMapper.selectHospitalPage(page, queryVO);

// 返回给前端
Map<String, Object> data = new HashMap<>();
data.put("total", result.getTotal());
data.put("records", result.getRecords());

分页插件需要在配置类里注册：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        PaginationInnerInterceptor pagination = new PaginationInnerInterceptor(DbType.MYSQL);
        pagination.setOverflow(false);
        pagination.setMaxLimit(100L);
        interceptor.addInnerInterceptor(pagination);
        return interceptor;
    }
}

这里有另外一个坑：分页插件必须配置，否则Page查询虽然不报错，但total始终为0、数据全部返回，会花时间排查才发现没有注册拦截器。

5.3 定时任务与数据统计报表实现

住院管理系统还有一个很实用的功能点：出院患者床位日费用汇总和科室床位使用率报表。如果手写统计，可以用DateTime相关的日期计算逻辑，但用SpringBoot的@Scheduled定时任务会更直观。

我实现的最常见场景是每天凌晨自动生成前一天各科室的费用汇总，存到一张日汇总表里，方便管理层查询历史数据。这样对数据库的压力小，读性能也好。

java复制@Component
public class DailyReportTask {
    @Scheduled(cron = "0 0 2 * * ?")
    public void generateDailySummary() {
        // 查询前一天所有出院的住院记录
        // 分组统计科室费用
        // 插入汇总表
    }
}

这个类上记得加@EnableScheduling启用定时任务。如果只是要做实时统计报表，也可以直接写一个统计查询接口，按科室分组查费用流水表sum操作。但如果报表查询响应超过三秒，就需要考虑预处理或缓存优化。

5.4 常见面试与答辩追问整理

做完系统之后，最容易被追问的问题大概率集中在"为什么选这个方案""遇到什么问题怎么解决的"。我把高频问题整理成一张速查表，你对着它准备，答辩时基本能覆盖80%的问题：

6. 项目打包部署、环境配置与避坑经验

6.1 SpringBoot项目打包成Docker镜像的实操过程

毕设演示环节如果还依赖本机IDE启动，会有两个风险：一是别人电脑上没有环境，演示临时搭环境时间又很长；二是突发断电或端口占用会导致演示卡壳。提前把项目打包成Docker镜像，用一条命令就能在任何装有Docker的机器上跑起来，观感和稳定性都会好很多。

先打包出可执行Jar包：

bash复制mvn clean package -DskipTests

然后按下面的方式编写Dockerfile。如果你的项目用的是JDK8，选择基础镜像时要注意带jdk8的字样，不能随便拉最新版jdk镜像（jdk20之后项目可能起不来）。

dockerfile复制FROM openjdk:8-jdk-alpine
MAINTAINER yourname
COPY target/hospital-system.jar /app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app.jar", "--spring.profiles.active=prod"]

构建并运行镜像的命令：

bash复制docker build -t hospital-system:1.0 .
docker run -d -p 8080:8080 \
  -e DB_HOST=192.168.1.100 \
  -e DB_PORT=3306 \
  -e DB_USERNAME=root \
  -e DB_PASSWORD=123456 \
  --name hospital hospital-system:1.0

数据库地址、用户名和密码通过环境变量注入，避免把明文密码写死在镜像里，这也是一个展示工程素养的加分点。在application.yml中用占位符引用环境变量：

yaml复制spring:
  datasource:
    url: jdbc:mysql://${DB_HOST}:${DB_PORT}/hospital_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

如果想让MySQL容器和SpringBoot容器互相连通，可以使用docker-compose的方式编排两个服务。我在这上面踩过最大的坑是时区问题：MySQL容器的默认时区是UTC，而项目中LocalDateTime.now()取的是系统默认时区，两者相差8小时，导致入院时间记录时间比实际早了8小时。解决方式是在MySQL连接串上显式加serverTimezone=Asia/Shanghai，或者在启动MySQL容器时加入-e TZ=Asia/Shanghai环境变量。

6.2 我在实际开发中遇到过的典型问题

第一类是数据库连接问题。MySQL 8.0的驱动类名和5.7时代不一样。如果是com.mysql.jdbc.Driver，这是旧驱动，连MySQL 8.0会报错。正确写法为com.mysql.cj.jdbc.Driver。同时要在URL后加上useSSL=false和allowPublicKeyRetrieval=true两个参数，否则有些MySQL版本配置会在连接时抛出Public Key Retrieval is not allowed的错误。

第二类是Lombok的坑。IDEA里运行正常，但打包后运行报错找不到getter/setter方法。这是因为Lombok在编译期通过注解处理器生成方法，如果没有在Maven编译器插件里显式声明annotationProcessorPaths，部分环境下会跳过Lombok处理。排查后找到原因是SpringBoot Maven插件做repackage时启用了排除规则，导致Lombok注解没有被处理。这个问题的解决方式是把Lombok版本和使用方式统一，确保依赖范围是provided而不是compile时打包漏掉。

第三类是前端跨域问题。如果前端项目是Vue独立运行在8081端口，后端跑在8080端口，那么必须处理CORS跨域。解决办法很简单，在SpringBoot中写一个配置类实现WebMvcConfigurer接口，添加跨域映射规则：

java复制@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);
    }
}

我这里要特别说明一点：allowCredentials设置为true时，allowedOrigins不能使用""，只能用allowedOriginPatterns("")，否则浏览器会直接拦截响应，真实原因跟Cookie携带策略有关。

第四类是内存溢出问题。JVM默认堆内存如果设置太小，访问大量的统计报表数据时可能抛出java.lang.OutOfMemoryError: insufficient memory异常。用IDEA运行的话，可以在运行配置的VM options中加-Xms256m -Xmx512m，开发机一般能撑住。Docker运行时通过-e JAVA_OPTS=-Xmx512m传给容器。生产或演示环境的机器内存不够用，频繁Full GC会导致明显的卡顿，这个经验很真实。

6.3 代码规范与日志管理建议

我见到很多毕设项目只有一个Controller类里塞了几百行业务逻辑，Service层形同虚设，Mapper接口和XML自己都分不清哪个对应哪个。这样一种结构虽然也能凑出来功能，但在答辩时面对追问会比较吃力，代码的健壮性也差。我写此类项目的习惯是强制分包：Controller只做参数接收和返回，Service做业务编排，Mapper做SQL持久化，Entity只做数据映射。

日志是所有系统里最容易忽视但又最有用的故障排查工具。建议在关键业务接口上打印操作日志：谁在什么时间对哪位患者执行了什么操作。如果后续要接ELK进行日志收集，那更要把日志格式统一。简单一点的做法是用SpringBoot自带的Logback，在application.yml中配置日志文件路径和级别：

yaml复制logging:
  level:
    com.hospital: debug
  file:
    name: logs/hospital-system.log

实际排查问题时，日志里最有用的是SQL执行日志和异常堆栈信息。所以在开发阶段，Mapper级别的日志level设为debug非常有必要，但上线阶段记得关掉，否则每产生一条SQL都打印一行，磁盘写入量会非常大。

7. 项目管理与时间规划建议

毕业设计的周期一般是三到四个月，我见过不少同学第一个月纠结选题、第二个月才发现技术栈不熟、最后一个月熬夜赶工，导致代码质量和论文质量双双崩塌。这个选题虽然完整，工作量也不小，所以时间规划显得尤其重要。如果现在问我怎么排进度，我建议按以下方式推进。

前两周做需求分析和数据库设计。不要急着写代码，把ER图画清楚、字段级别设计完整。数据库多花两天时间，后期少写废代码、少改表结构。中间五到六周集中开发后端接口和前端页面，按模块迭代推进。建议第一个迭代只做系统管理和用户登录权限，快速跑通前后端联调链路，这个基础体系一旦打通，后续模块就是流水线式的体力活。第三个月做联调测试和演示数据填充，同时启动论文初稿。最后两到三周专门做Bug修复、论文排版和答辩PPT。PPT不需要太多页，核心是把业务背景、技术架构、ER图、核心接口时序图、系统演示截图放进去，每一页都要能讲三分钟。

要特别提醒的是，演示系统里一定要准备充足的模拟数据。一个只有三条患者的系统，无论功能做得多深入，看起来也缺少说服力。每个科室至少放二十个患者、每个患者起码有七八条住院明细、医嘱和费用流水，这样页面一打开才有真实系统的感觉。这些数据不要手写SQL一条条插，可以用一段Java逻辑循环批量生成，或者写一个数据初始化接口，加个开关只在dev环境生效。

8. 写给即将开始做这个题目的同学

最后再分享一点个人经验。做完整个住院管理系统，我最大的体会是：优秀的毕设项目，不是功能堆得越多越好，而是把每个功能背后"为什么这么设计"想透了。比如为什么床位状态要用独立字段而不是通过住院记录反查？为什么医嘱要把医生开立和护士执行分开两张表？为什么出院时要统一结算床位费而不是每天累加？这些决策背后都藏着真实的临床业务逻辑和技术考量。

你如果现在拿到这个题目，建议先不用急着网上找现成的代码，也不要直接依赖任何开源的医院系统项目。先花半天时间把需求想象成自己在一个真实的住院部：如果你是护士长，希望一个软件帮你看到什么？如果你是信息科负责人，系统坏了怎么办、权限怎么分？如果从这些实际使用倒推系统设计，就能做出有一个有思考深度的系统——这才是判断一个学生有没有真正理解软件工程的标准。项目做完后，就算你的代码有一些边角瑕疵，只要核心模块严密地实现了业务流程、面对追问能清楚地解释设计思路，就已经把大部分同题目的对手落开一截了。祝顺利。