从零落地医院病历管理系统：Spring Boot与MyBatis Plus的Java Web实战

作为一个常年泡在Java后端项目里的开发者，看到“SSM359医院病历管理系统”这种编号就知道，这八成是某高校软件工程类专业的学期大作业，或者是培训机构结业时的综合实战项目。别小看这类管理系统，它把业务、数据、权限、前端页面全串起来了，是Java Web技术栈里很典型的练手场景。这篇文章我会以整套系统从零到落地的视角，把医院病历管理系统的核心模块、技术细节和实际踩坑点一次说透，尤其是Spring Boot和MyBatis Plus在真实项目里的组合打法，对正在做课程设计或者刚入行想积累项目经验的开发者会很有帮助。

1. 病历管理系统到底在管什么

很多同学一上来就急着建表、敲代码，结果做着做着发现功能满天飞，根本收不住。把需求理清楚，项目就成功了一半。一个合格的管理系统必须回答几个问题：谁在用、能干什么、数据从哪来、数据怎么流转。

1.1 从病历管理痛点说起

病历是医院的核心业务文档，过去用纸质病历的时候，翻档案柜、找病例、统计都极其痛苦。医院病历管理系统就是要解决这些痛点：病历数字化、存储结构化、查询快速化、权限精细化。系统里最基础的数据对象就是“患者”和“病历”，围绕这两个核心扩展出医生管理、科室管理、用户登录、病历分类（门诊/住院）、复诊记录等一系列业务。

这套系统面向的角色至少有三类：管理员、医生、护士，可能还有只读权限的访客或实习生。每一类角色能看到的数据和能做的操作必须分开，不然就乱套。所以RBAC（基于角色的权限管理）是这个项目里绕不开的设计点。

1.2 功能模块怎么拆才合理

从实操角度看，功能模块建议拆成下面几块：

• 系统登录与用户管理：账号密码校验、用户状态管理、角色分配。
• 患者管理：患者基本信息登记、修改、查询，病历号唯一。
• 病历管理：病历首页、入院记录、病程记录、出院记录等不同类型。
• 医嘱管理（可选但加分）：医嘱的新增、停用、查询。
• 统计与报表：按时间段、科室、病种统计病历数量。
• 系统配置：数据字典（科室列表、病历类型）、日志记录。

模块拆得好不好，直接影响后面的工作量。比如把病历类型做成数据字典而不是写死在代码里，后面要加类型就不用改Java代码，这是很实用的工程经验。

1.3 角色权限的边界划分

在这个项目里，权限控制我不建议直接引入Spring Security，太重了，课程设计阶段会被安全框架本身拖住大量时间。更高效的方式是做拦截器（HandlerInterceptor）加自定义注解，实现基于角色的访问控制。核心思路就是登录成功后把用户对象放进Session，然后拦截非登录请求，校验当前用户对当前URL是否有权限。

权限粒度方面，给三种主要角色划分界限：

把权限边界画清楚后再写后端接口，每个接口的语义就非常明确，代码写起来也很顺手。

2. 技术栈选型与工程结构落地

SSM359这个编号说明它原始版本是SSM（Spring+SpringMVC+MyBatis）架构，但现在主流做法已经转向Spring Boot。Spring Boot不等于抛弃SSM，它只是把旧SSM里繁琐的XML配置省掉了，核心思想还是一脉相承的。

2.1 为什么最终落在Spring Boot上

如果你按传统SSM去搭项目，光配置文件就要写一堆：web.xml、SpringMVC.xml、Spring配置、MyBatis的mapper扫描，还有各种jar包版本冲突问题。Spring Boot把这些全都自动化处理了。而且这个项目本身并不复杂，Spring Boot的约定大于配置能大幅减少样板代码。

推荐的技术版本组合是这样的：

• JDK 1.8或11（1.8最稳妥）
• Spring Boot 2.5.x或2.7.x
• MyBatis Plus 3.5.x（也可以叫MP，对单表CRUD的代码量削减效果非常明显）
• MySQL 5.7或8.0
• Thymeleaf做模板引擎（不建议用JSP，Spring Boot下JSP支持比较别扭）
• Maven做构建

2.2 项目目录结构与分层

项目包结构建议遵循实际REST风格项目，这样在代码评审的时候不会挨批：

code复制com.medical.demo
├── config         // 配置类（拦截器注册、跨域配置）
├── controller     // 控制层
├── service        // 业务接口与实现
├── mapper         // MyBatis Mapper接口
├── entity         // 数据库实体类
├── common         // 公共返回类、异常类、常量类
├── interceptor    // 登录权限拦截器
└── utils          // 工具类（病历号生成、日期转换）

Controller只负责参数接收和返回结果，Service层承载真正的业务逻辑，让它尽可能厚一点，不要所有逻辑直接堆在Controller里结成大泥球。MyBatis的Mapper接口也统一放在Mapper包，XML可以放resources下的mapper目录，两者对应清晰。

2.3 数据库设计的几个关键决策

数据库设计时我反复提醒自己：真实医院病历表有很多张，但课程设计要有度。核心表控制在7张左右比较合理：

• sys_user（用户表）
• sys_role（角色表）
• sys_user_role（用户角色关联表）
• patient（患者表）
• medical_record（病历表）
• department（科室表）
• dict_data（数据字典表）

设计表的几个要点：

1. 患者表姓名、性别、出生日期、身份证号、联系方式、既往病史等要有冗余字段，避免病历查询时反复联表。
2. 病历表包含患者ID、科室ID、医生ID、病历标题、发病情况描述、诊断结论、治疗方案、复诊建议、病历类型、创建时间等。
3. 软删除字段逻辑删除：病历数据是医疗文档，不能物理删除，加一个deleted字段，逻辑删除即可。
4. 时间字段用datetime类型，病历时序性很重要，创建时间和更新时间都保留数据库自动填充能力。

有一点尤其重要：病历内容会很长，用TEXT类型；而SQL查询返回大量TEXT字段时会有性能问题，列表页不需要全文内容时只查出摘要部分，详情页再查完整内容，这是很多人忽略但很实际的优化点。

3. 核心功能模块实现细节

功能实现阶段最能看出一个开发者有没有工程思维。我会按实际开发次序来拆解几个核心模块，每个模块都给出关键代码和思路。

3.1 患者建档与病历号生成机制

建档是整个系统的数据源头。患者信息没有什么难度，典型的CRUD，但病历号怎么生成值得好好设计。有别于自增主键，病历号需要带有医院特征和日期信息。我采用的生成规则是“HIS+日期+三位流水号”，例如HIS20250115001。代码如下：

java复制public String generateMedicalRecordNo() {
    LocalDate now = LocalDate.now();
    String prefix = "HIS" + now.format(DateTimeFormatter.BASIC_ISO_DATE);
    // 查询当天已存在的最大病历号
    QueryWrapper<Patient> wrapper = new QueryWrapper<>();
    wrapper.likeRight("medical_record_no", prefix);
    wrapper.orderByDesc("medical_record_no").last("LIMIT 1");
    Patient patient = patientMapper.selectOne(wrapper);
    
    int seq = 1;
    if (patient != null) {
        String lastNo = patient.getMedicalRecordNo();
        seq = Integer.parseInt(lastNo.substring(lastNo.length() - 3)) + 1;
    }
    return prefix + String.format("%03d", seq);
}

这里用到了MyBatis Plus的QueryWrapper，非常轻巧。核心思路是每天的病历号从001开始累加，避免跨天冲突。系统并发量不高，这样处理绰绰有余。

患者信息保存除了基础校验，还要强调身份证号的唯一性和格式校验。用一个正则校验身份证位数，若有重复则拦截。这些校验逻辑在Service层做完，用自定义业务异常抛出，配合全局异常处理器返回统一JSON结构。

3.2 病历表单编辑与模板复用

病历不是一份死板的表格，不同类型有不同字段。比如门诊病历只需要主诉、现病史、体格检查、诊断、处理意见；入院记录要加既往史、个人史、家族史；手术记录还要麻醉方式、手术经过。不加设计的实现会是判空逻辑满天飞，每种病历写一个DTO实体。

更聪明的方式是“病历模板+富文本内容”。一张病历表中建立record_type字段区分病历类型，同时建立一个病历模板表，保存模板标题和模板字段。保存病历的时候，医生选择模板，系统把模板的字段结构动态渲染成表单，用户填写后以JSON字符串存进病历content字段。

这种设计前期只加了一张表，但带来了极大的灵活性。后期增加病历类型时，只用维护数据字典和模板表，完全不用改实体类。这也是很多同学在答辩时只讲一句“我用了数据字典”就得分的原因所在。

动手写病历保存接口时要记住，更新和插入是两回事。保存草稿时状态字段置为0，正式提交置为1，医生修改本人病历直接update。提交之后再修改就需要走审核通道，这是医院流程的真实要求。

3.3 分页查询与条件检索的实用做法

病历检索是这个系统的刚需，医生每天都要按患者姓名、诊断、时间段来找病历。用MyBatis Plus自带分页插件是效率最快的方案：

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

使用分页查询接口时，Service层用LambdaQueryWrapper完成条件拼接，这才是精髓：

java复制public IPage<MedicalRecordVO> queryRecord(int page, int size, String condition, 
                                          Integer type, Long deptId, String startDate, String endDate) {
    Page<MedicalRecord> pager = new Page<>(page, size);
    LambdaQueryWrapper<MedicalRecord> wrapper = new LambdaQueryWrapper<>();
    wrapper.like(StringUtils.hasText(condition), MedicalRecord::getDiseaseDesc, condition)
           .eq(type != null, MedicalRecord::getRecordType, type)
           .eq(deptId != null, MedicalRecord::getDeptId, deptId)
           .between(StringUtils.hasText(startDate) && StringUtils.hasText(endDate),
                    MedicalRecord::getCreateTime, startDate + " 00:00:00", endDate + " 23:59:59")
           .orderByDesc(MedicalRecord::getCreateTime);
    return medicalRecordMapper.selectPage(pager, wrapper);
}

三个经验要点：

1. 条件判断里一定要加hasText或者!= null，别拼垃圾SQL去数据库里查。
2. 日期范围查询注意把结束日期自动拼上23:59:59，否则当天记录查不出来。
3. 分页对象IPage不要直接返回给前端，先转成VO再返回。

列表页的懒加载也值得一提：病历内容从不一次性在列表里展示全文，通常是截取前50个字作为摘要，点进详情页再加载完整内容。数据库查询时的映射完全可以只在SQL里处理，比如select substring(record_content, 1, 50) as recordSummary。

3.4 登录鉴权与拦截器配置

没有Spring Security，登录这块反而更可控。密码用BCrypt加密存储，登录接口校验成功后将用户ID、姓名、角色放入Session。然后注册拦截器：

java复制@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    HttpSession session = request.getSession();
    User user = (User) session.getAttribute("loginUser");
    if (user == null) {
        response.sendRedirect("/login");
        return false;
    }
    // 进一步校验角色权限
    if (handler instanceof HandlerMethod) {
        HandlerMethod hm = (HandlerMethod) handler;
        RequiresPermission permissionAnno = hm.getMethodAnnotation(RequiresPermission.class);
        if (permissionAnno != null && !checkRole(user, permissionAnno.value())) {
            response.setStatus(403);
            response.setContentType("application/json;charset=UTF-8");
            response.getWriter().write("{\"code\":403,\"msg\":\"无权限访问\"}");
            return false;
        }
    }
    return true;
}

自定义RequiresPermission注解的妙处在于声明式权限控制。方法加一行注解就能控制访问，不侵入业务代码，看起来清爽，答辩时也有足够的说头。操作日志建议在Controller层配合AOP做切面记录，记录谁在什么时间访问了什么接口，这是加分项。

4. 实际开发中的“坑”与排查记录

这块内容的价值比建表和CRUD大得多。但凡做过项目都知道，真正的工时不是耗在业务编码上，而是不断跟环境、框架、数据细节搏斗。下面这些坑我基本都踩过，你提前看一看，能少走很多弯路。

4.1 日期格式与JSON序列化的来回折腾

第一个高频坑就是前端传日期字符串给后端，后端用LocalDateTime接收时直接报错。比如前端传“2025-04-18”，后端属性是LocalDateTime类型，Jackson默认解析不了。

解决办法有两层。第一层，前端传来什么样的字符串，实体类的日期字段就定义成对应的类型。只传日期就定义LocalDate，需要时分秒才用LocalDateTime。第二层，在Spring Boot配置里加Jackson序列化规则：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

但如果接口接收的是JSON格式，只配置date-format并不能完全搞定LocalDateTime。更稳的方式是自定义Jackson反序列化器，或者干脆前后端协商用字符串传递日期。最省事的经验法则：数据库存datetime，实体用LocalDateTime，VO给前端展示用String“yyyy-MM-dd HH:mm:ss”。System.currentTimeMillis()丢毫秒值的问题在前后端分离的项目里经常出现，一次统一规划好，后面全是省心。

4.2 MyBatis的XML映射与动态SQL细节

用了MyBatis Plus，单表操作几乎不用写XML，但复杂联表聚合查询还是要写XML。最容易出问题的是resultMap中字段映射下划线转驼峰对不上的问题。如果数据库字段是create_time，实体是createTime，一直查出来是null，那就是mybatis-plus配置没开驼峰映射。在application.yml里加上：

yaml复制mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true

动态SQL还有一个常见毛病，就是test表达式里字符串类型判空要同时判断空字符串。或者直接用MP的LambdaQueryWrapper，把判断逻辑交给Java代码，比XML里的标签直观得多，也更不易出错。能用代码解决的就别丢给XML，这句话放在MP时代尤其适用。

4.3 事务与并发场景的守护方案

病历保存接口的写操作不是一个单表操作，可能同时更新病历主表、记录日志表、修改患者最后就诊时间，这时候必须加事务。

Spring Boot下在Service方法上直接加@Transactional(rollbackFor = Exception.class)是最常见的写法。注意rollbackFor参数一定要带上，否则只对RuntimeException回滚，对自定义业务异常无效。

并发场景下，最直接的问题是“同时编辑同一份病历”。我给出两种处理思路，复杂度不同：

课程设计阶段用乐观锁最合适。只加一个字段和几条判断代码，效果立竿见影。我见过不少项目因为多人测试时同时改一份数据，最后记录互相覆盖，答辩时被老师抓了痛点。

4.4 打包部署与环境配置的最后一公里

开发环境一切正常，打成jar包部署到服务器时而前端页面加载不出来，这种问题在Thymeleaf项目中很常见。通常是因为模板路径写成了绝对路径前缀，jarr包模式下找不到文件。解决方案是模板和静态资源的路径全部使用相对路径。

这里放一个系统变量注入案例：

java复制@Value("${file.upload-path}")
private String uploadPath;

配置文件里用application-dev.yml和application-prod.yml分别维护本地与服务器配置。数据库连接记得用utf8mb4，否则特殊字符存不进去：

code复制jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai

部署用java -jar运行，端口通过--server.port参数灵活切换，也能用Nginx做反向代理。到这里系统的工程层面才算是完整的，不只是能跑在IDE里，而是能真正上线。

5. 让细节经得起推敲的加分项

一个医疗机构系统，光功能跑通还远远不够。病历数据涉及患者隐私，数据安全和合规细节值得认真对待。这部分做好了，是系统的灵魂所在。

病历数据的安全性有两个维度的考量。第一是网络传输，部署时一定记得配置HTTPS，登录接口的密码传输要做加密处理。第二是前端展示，患者姓名和身份证等敏感信息可采用脱敏展示，比如“张**”。这两个细节在真实医院场景里都是底线要求，在课程设计里也是亮眼的加分项。

操作日志记录也不要忘记。谁在什么时间修改了哪份病历，改了什么字段，要有留痕机制。用AOP切面做法，在系统里定义Log注解，标注操作模块和操作类型，通过环绕通知把日志记录到一个sys_operation_log表里。这个模块单独抽出来完全不侵入业务代码，而且数据安全性瞬间提升一个档次。

数据备份策略也值得写一小段思路：每日定时binlog备份加定期全量导出，这样的方案在答辩时说出来会让评委觉得思路完整，而不是简简单单做个CRUD。

6. 项目收尾的最后一个建议

如果你是在做课程设计，表格、接口、权限都完成后，请务必给自己留出一天时间复查。做病历管理系统，简历上写的不应该是“熟悉CRUD”，而是“掌握了RBAC权限模型、数据字典设计、软删除、乐观锁并发控制、敏感数据脱敏”这些有区分度的关键词。把细节打磨搞清楚，它能成为非常好的综合能力证明。

尤其建议把系统跑起来后专门测试一遍异常操作路径：未登录直接访问接口、越权查看病历、超长文本提交、并发修改同一患者记录。在这些测试中发现的问题，把这些豁免经验写进文末说明或答辩PPT里，老师觉得这才是有真实项目经验的样子，比用一整页写“系统优点”有价值得多。

代码整洁度也是加分项，常量不要裸写，异常信息统一管理，前后端字段命名风格一致。有一天别人接手你的代码时，或者一个月后的自己再翻代码时，都会感谢当时认真命名的你。真正好用的病历系统不在于代码生成器铺得多快，而在于每一个细节都经得起追问。病历管理是敏感业务，带着敬畏心写代码，系统整体质量才会明显上一个台阶。