1. 项目概述与核心需求拆解做医疗信息系统的开发，其实是一件挺特殊的事。它和做电商、做内容管理完全不一样，最大的差别在于——病历数据是受严格监管的敏感数据，而且业务链条极长：从门诊医生接诊，到书写病历、开立医嘱，再到护士执行、药房发药、检验检查回报，最后到收费结算，任何一个环节出问题，都会直接影响医疗质量和患者安全。所以当我看到"Spring Boot电子病历管理系统"这个题目时，第一反应是：这不仅仅是一个简单的CRUD练习，而是涵盖医疗核心业务场景的完整系统设计。通常这类项目在企业里归属于HIS（医院信息系统）中的EMR（Electronic Medical Record，电子病历）子系统，前端医生工作站通过它完成患者病历的创建、编辑、审阅、归档和质控。适合参考这个项目的人群很明确：刚学完Spring Boot想找一个完整全栈实践项目的开发者，需要做毕业设计或课程设计的在校学生，以及刚进入医疗信息化领域、想快速了解业务模型的新人。这个系统解决的核心问题就是——让纸质病历电子化，让病历书写从手写改为结构化录入，同时提供权限控制、版本留痕和辅助质控能力。从技术角度讲，Spring Boot是目前Java后端开发最主流的选择，没有之一。它对繁琐的Spring配置做了大量自动化处理，内嵌Tomcat、默认提供健康检查和生产级运维端点，配合Spring Data JPA或MyBatis都能快速搭建一套可运行的服务。而电子病历系统选择Spring Boot，还有一个产业层面的原因：医疗信息化系统大多跑在医院内网的独立服务器上，需要稳定、易维护、可独立部署，Spring Boot打一个jar包扔到服务器上就能跑，这种轻量级特性对医院运维非常友好。在功能维度上，一个可用的电子病历系统通常至少包含这五块：患者管理：登记患者基本信息，生成住院号/门诊号，提供查询与关联操作病历文书管理：包括门急诊病历、住院病历、病程记录、出院小结等，支持按模板创建、编辑与归档医嘱管理：长期医嘱与临时医嘱的新建、作废、停止，关联计价与执行状态系统权限与审计：基于角色的访问控制（RBAC），记录谁在什么时间改了什么内容数据统计：基础的就诊量、病历完成率、归档率等指标的查询如果做的是毕业设计，建议在此基础上再增加一个可视化数据面板，展示历日就诊趋势、科室工作量排行等，会明显提升项目的完整度和答辩亮点。2. 核心技术栈与整体架构设计2.1 后端技术选型：为什么是Spring Boot + MyBatis-Plus电子病历系统的技术选型需要考虑数据一致性和开发效率的平衡。我见过不少团队在医疗项目里盲目引入微服务、分布式事务，结果把一个门诊病历保存流程拆成四五个服务调用，最后光排查问题就花了一周。对于这样一个系统，单体应用加模块化设计是完全够用的。后端我推荐这套组合：组件选型说明核心框架Spring Boot 2.7.x稳定、社区资料多，内嵌Tomcat，打jar部署方便ORM框架MyBatis-Plus代码生成效率高，内置分页插件，避免写大量XML数据库MySQL 8.0支持JSON字段和窗口函数，病历内容存储灵活权限方案Spring Security + JWT无状态鉴权，适合前后端分离架构缓存Redis验证码、token黑名单、高频字典数据缓存接口文档Knife4j基于Swagger的增强文档，支持离线文档导出工具库Hutool日期解析、加密、Excel导出等实用工具，减少重复代码MyBatis-Plus在简单CRUD场景下能省掉大量重复的Mapper方法，自带逻辑删除和乐观锁插件，刚好匹配病历系统中"记录不能物理删除、修改要留痕"的需求。实体类上加@TableLogic注解，删除操作就自动变成UPDATE，这是一个很实用的细节。2.2 数据库设计：病历数据怎么建模数据库模型是整个系统的地基，医疗项目尤其讲究字段的完整性和溯源能力。核心表可以这样规划：patient表：患者主索引，字段包括姓名、性别、出生日期、证件号、联系电话、血型、药物过敏史。过敏史一定要单独冗余存一份字符串，写进病历的时候直接带出来，不能靠联查，这是从安全角度考虑的，医生开处方时第一时间能看到。medical_record表：病历文书主表，包含患者ID、就诊类型（门急诊/住院）、就诊科室、主诉、现病史、既往史、体格检查、诊断结果、医生ID、病历状态（草稿/提交/归档/驳回）。关键点在于每个状态变更都要在record_status_log表中留一条轨迹。medical_record_detail表：有些设计把病历大字段单独拆表，用record_id关联，存放完整的富文本内容。拆表的逻辑是——列表页只需要查主表，只有打开详情时才加载大字段，能有效减轻数据库IO压力。diagnosis表：诊断信息，关联ICD-10编码，支持一条病历多个诊断，需要设置主诊断标记。prescription表 / prescription_item表：处方主表和明细表，一对多设计，明细记录药品名称、规格、单次剂量、频次、途径、天数、数量。sys_user表、sys_role表、sys_user_role表、sys_menu表：标准的RBAC四件套。这里特别要强调create_time和update_time字段不要用数据库的DEFAULT CURRENT_TIMESTAMP简单带过。代码里通过MyBatis-Plus的MetaObjectHandler统一填充，同时记录操作人。这样出了问题可以明确回答：是谁、在什么时间、把这个字段从什么值改成了什么值。2.3 前端技术栈与前后端交互前端建议使用Vue3 + Element Plus + Pinia + Axios。如果不想从零搭建工程，可以直接使用现成的后台管理模板，比如RuoYi-Vue这种开源脚手架也有不少医疗Demo，但直接用模板有一个问题——大量代码不是你写的，答辩问答环节容易被问住。我建议是搭好基础工程后，核心的业务组件（病历编辑器、处方录入、患者列表）自己动手写一遍。接口交互走RESTful风格，统一返回结构：public class Result<T> { private Integer code; private String message; private T data; }前端通过Axios拦截器统一处理401跳转和500错误提示，请求头携带Authorization字段作为JWT令牌。3. 详细设计：核心功能模块如何落地3.1 患者管理模块：别小看了这个模块很多人觉得患者管理不就是增删改查嘛，很简单的。但在实际医疗业务中，患者主索引是有讲究的——同一个患者可能用不同证件号挂过好几次号，也可能出生日期填错了。所以患者注册接口一定要加唯一性校验，用一个id_card_no + phone的组合去匹配已存在的记录，查到就提示"已存在患者，请确认是否复用"。在真实项目中还会引入主索引服务做相似度匹配，这里先不展开。患者注册页建议校验的字段至少包括：姓名不能为空，长度2~20出生日期不能晚于当前日期证件号如果填写，必须通过正则校验（身份证18位或护照等）联系方式必须为11位手机号或有效座机号3.2 病历文书管理：让医生能"写"也能"改"电子病历最大的痛点就是书写效率。老医生的打字速度不一定快，但如果让他用鼠标点几百个下拉框，他更不乐意。比较务实的方案是——提供可配置的病历模板。比如"首次病程记录"模板，把主诉、现病史、既往史、体格检查等段落排版好，医生只需要填写具体内容，必要时一键带入患者基本信息和历史诊断。这个模块在技术实现上有一个关键设计，就是分段存储。病历正文不能简单存一个超长字符串，而是拆成多个段落块，每个段落块有独立的标识和排序值。这样做的目的有两个：一是后续做病历质控时，可以针对"现病史"这种特定段做内容完整性校验；二是支持段落级别的修改留痕，而不是整篇文档替换。一段简化版的段落数据存储结构：CREATE TABLE record_segment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, record_id BIGINT NOT NULL COMMENT '病历主表ID', segment_key VARCHAR(50) NOT NULL COMMENT '段落标识，如chief_complaint', segment_name VARCHAR(100) NOT NULL COMMENT '段落显示名称', content TEXT COMMENT '段落内容', sort_order INT DEFAULT 0, create_by BIGINT, create_time DATETIME, update_by BIGINT, update_time DATETIME );前端富文本编辑器我推荐使用WangEditor或TinyMCE，不要再自己封装contenteditable了，踩过的坑太多了——光标丢失、粘贴格式混乱、浏览器兼容性问题，数都数不过来。WangEditor对Vue的支持相对友好，可以在工具栏里只保留医学文书需要的功能：加粗、字体、字号、标题、列表、表格、图片上传。3.3 病历审阅与质控这块属于系统的"管理后台"能力，也是能在答辩中体现出业务思考的部分。系统内置两个角色：住院医生（书写病历）和主治医生/科室主任（审阅病历）。审阅流程走状态机：草稿（DRAFT）→ 提交待审（SUBMITTED）→ 审阅通过（APPROVED）→ 归档（ARCHIVED）审阅不通过则回到DRAFT状态，并附带驳回意见状态流转在代码里建议用枚举封装：public enum RecordStatus { DRAFT(0, "草稿"), SUBMITTED(1, "待审阅"), APPROVED(2, "已通过"), ARCHIVED(3, "已归档"), REJECTED(4, "已驳回"); private final Integer code; private final String description; }每次状态变更写入record_status_log，保证全链路可追溯。在病历归档之后，要禁止再编辑。这一点在Controller层要通过状态校验拦截，不能只靠前端隐藏按钮。3.4 医嘱管理：数量、频次、剂量都不允许将就医嘱模块是医疗系统里面最容易出"问题"的地方，因为它直接关系到患者用药安全。一个合格的医嘱录入接口至少要包含以下校验：单次剂量必须大于0，并且剂量单位不能为空频次必须从字典表中选择（qd、bid、tid等），不允许自由输入天数必须是正整数，且不能超过系统限制作废医嘱必须填写作废原因，保证用药过程有据可查这里还要说一个细节，就是医嘱id和处方id的关系。一张处方可以包含多条医嘱，每条医嘱关联到具体药品主数据。药品主数据表要有统一的规格和厂家信息，录入时不能允许医生自己"造"药品。真实系统里药品字典是药房维护的，这里简化为管理员后台维护即可。4. 实战编码：从零搭建Spring Boot后端核心流程4.1 项目初始化与依赖配置用Spring Initializr或者直接在IDE里创建项目时，推荐的Java版本是8或11。不是越新越好——很多医院客户的服务器运行的还是CentOS 7环境，预装的JDK可能是1.8，如果项目用Java 17的语法，到了部署阶段就会发现自己给自己挖了个坑。Java 8 + Spring Boot 2.7是稳妥到不能再稳妥的组合。pom.xml核心依赖示例：<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>3.19.2</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>这里特别提一下Lombok在医疗项目中的使用态度。实体类加上@Data确实能少写很多getter/setter，但有一个隐患——如果项目后续需要做大量字段级的操作审计，IDE的getter和setter方法在断点调试时反而不直观。我的建议是简单DO类用Lombok，DTO/VO类上手动写构造方法，这样日志输出的字段能精确控制。4.2 JWT鉴权与RBAC权限控制Spring Security的配置是整个项目安全性的地基。B站上很多教学视频教你把Spring Security整个关闭然后自己写拦截器，这种方案在真实项目中是绝对不推荐的。正确的方式是使用Spring Security的过滤器链，通过自定义OncePerRequestFilter解析令牌，并把用户信息和权限列表放入SecurityContextHolder。核心配置类片段：@Configuration @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { @Resource private JwtAuthenticationFilter jwtAuthenticationFilter; @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers("/api/auth/login", "/api/auth/captcha").permitAll() .antMatchers("/api/patient/**").hasAnyRole("DOCTOR", "NURSE", "ADMIN") .antMatchers("/api/medical-record/**").hasRole("DOCTOR") .antMatchers("/api/system/**").hasRole("ADMIN") .anyRequest().authenticated() .and() .exceptionHandling().authenticationEntryPoint(customAuthenticationEntryPoint); http.addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); } }在前后端分离的架构下，关闭CSRF并把会话策略改为STATELESS是必要的。但一定要补齐两件事：一是自定义认证入口点，返回JSON格式的401响应，而不是Spring Security默认的HTML错误页；二是配置CORS跨域，否则前端请求会被浏览器拦截。4.3 自定义注解实现操作审计电子病历系统对安全审计有天然需求——谁在什么时候访问或修改了病历，这些都不能靠自觉记录。用AOP做一个统一操作日志切面，比在每个Service方法里手动调用日志工具类优雅得多。切面实现思路：@Aspect @Component public class OperationLogAspect { @Before("@annotation(operationLog)") public void doBefore(JoinPoint joinPoint, OperationLog operationLog) { // 获取当前登录用户（从SecurityContextHolder中取） // 解析Controller方法的请求参数，提取患者ID、病历ID等关键业务字段 // 将操作日志写入sys_operation_log表 // 对于敏感操作，额外发送到消息队列做异步存储 } }为操作日志加上查询条件（操作人、操作时间范围、患者ID、操作类型），这部分是病历溯源能力的有力补充。答辩时如果能主动提到这个设计，说明对医疗系统的合规性有基本认知，比干巴巴说"我做了登录功能"好太多。4.4 前端核心页面：病历录入与患者列表患者列表页使用Element Plus的el-table，配合分页组件。后端分页查询使用MyBatis-Plus的Page对象：@GetMapping("/patient/list") public Result<IPage<PatientVO>> list(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, PatientQueryDTO queryDTO) { Page<Patient> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Patient> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(queryDTO.getName()), Patient::getName, queryDTO.getName()) .eq(StringUtils.hasText(queryDTO.getIdCardNo()), Patient::getIdCardNo, queryDTO.getIdCardNo()) .orderByDesc(Patient::getCreateTime); IPage<Patient> patientPage = patientService.page(page, wrapper); // 转换为VO返回，避免把敏感字段全部暴露给前端 return Result.success(patientPage.convert(patient -> patientMapper.toVO(patient))); }病历编辑器页面是开发工作量最大的部分。建议把工具栏配置为：粗体、斜体、下划线、字体字号、编号列表、项目符号、表格、插入图片、清除格式。图片上传接口要限制文件类型，只接受jpg/png/webp，这个校验必须做在后端，前端限制一个accept属性挡不住有心的操作。5. 部署、测试与常见问题排查5.1 本地快速启动指南拿到源码之后不要着急改代码，先按这个顺序跑起来：本地安装MySQL 8.0，创建数据库emr_system，执行项目内的sql/init.sql脚本在application.yml里修改数据库账号密码，注意把时区设置为serverTimezone=Asia/Shanghai启动Redis服务（没有Redis环境可以先把验证码相关代码注释掉，不影响主流程）运行EmrApplication.java的主方法，观察控制台日志看到Tomcat started on port(s): 8080后，访问后端健康检查接口/actuator/health启动前端工程，修改.env文件中的VITE_API_BASE_URL指向http://localhost:8080/api浏览器访问前端地址，使用系统内置的管理员账号登录内置管理员账号建议设置为admin / admin123，首次登录后强制修改密码——这是我在真实项目里坚持的习惯，避免系统交付后弱口令风险。5.2 端口冲突与数据库连接超时端口占用是新手最常遇到的问题。启动时控制台报Port 8080 was already in use，解决办法有三种：杀掉占用进程（Windows下用netstat -ano | findstr 8080找到PID再taskkill /PID），或者修改application.yml里的server.port。MySQL连接超时的典型报错是Communications link failure，排查思路：确认MySQL服务是否启动：systemctl status mysqld确认防火墙是否开放3306端口确认url中的serverTimezone参数没有问题用命令行工具试连一下，排除代码问题；一般来说，先用你写在代码里的账号密码在命令行里连一次，如果连不上，问题基本不在Spring Boot，而在MySQL侧。导入SQL失败则要注意MySQL版本差异。如果你本地是5.7版本，但SQL脚本里用了JSON类型函数或utf8mb4_0900_ai_ci排序规则，就会直接报错。建议统一用MySQL 8.0，和项目的数据库版本保持一致。5.3 前后端联调时常见的"疑难杂症"登录成功后请求依然返回401：大概率是JWT没有放进请求头。检查前端的Axios拦截器，确认config.headers.Authorization = 'Bearer ' + token的写法；后端则确认JwtAuthenticationFilter是否在Security过滤器链中执行。CORS跨域报错：确认后端SecurityConfig里配置了CORS源，并开启Spring MVC的跨域支持。注意allowCredentials(true)时不能同时设置allowedOrigins("*")，这是浏览器的安全策略限制。返回给前端的日期格式是时间戳：可以在application.yml中配置：spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+85.4 医疗系统特有的注意事项这里有些经验是从真实医疗项目里总结的，虽然写的是代码，但背后都是业务约束。做电子病历系统，不能只管代码能跑，更要考虑数据安全与合规。第一，敏感字段脱敏。患者信息接口返回前端时，身份证号中间8位应该掩码处理，比如110***********1234，手机号也可以保留前3后4。前端展示时全部使用脱敏值，只有获得更高授权或者特定操作（如医生打开完整病历）才返回完整数据。这个用@JsonSerialize自定义脱敏序列化器就能统一实现。第二，备份不能省。数据库要启用定时备份任务，推荐方案是每天凌晨执行mysqldump，保留最近7天的备份文件。真到了数据误操作恢复的那一天，你会感谢这个习惯。病历数据的价值远超软件本身，这个意识在医疗行业尤其重要。第三，权限不能只在前端控制。后端接口必须做二次鉴权。前端只是用户体验问题，后端是安全问题。一个用户可以直接跳过UI调用接口，所以每个修改、删除、查询接口都要校验当前用户的角色和归属部门。6. 代码优化与答辩亮点6.1 性能优化：一张表数量过千万怎么办如果真实医院环境中的病历数量达到千万级，就必须考虑分表和索引优化了。按patient_id做哈希取模进行水平分表是一个常见方案，比如medical_record_0、medical_record_1……但这个方案的查询逻辑复杂度会明显上升，必须通过分库分表中间件处理。对于课程设计或演示项目来说，这样一个H2标题的分享内容是了解性的，但了解了不去实现也没问题。索引优化则是立刻可以做并且对性能影响非常大的：patient表id_card_no字段加唯一索引medical_record表patient_id + status加联合索引record_status_log表record_id加普通索引所有逻辑删除字段和其它高频查询条件加普通索引6.2 让代码更好维护的四个习惯第一个习惯是统一响应体。所有Controller返回值都用Result<T>包裹，不要有的返回Map、有的返回String、有的直接返回实体对象。对接前端的人是谁不重要，规范一致比什么都重要。第二个习惯是异常收敛。全局异常处理器统一捕获BusinessException和Exception，不要在每个Controller里写try-catch。医疗系统报了异常，患者那边就等着一脸懵——所以异常文案要尽量清晰，比如"该病历已归档，禁止编辑"，而不是"系统异常"。第三个习惯是参数校验前置。使用@Validated配合@NotNull、@NotBlank、@Size注解在DTO层做声明式校验，不要在Service里写一连串的if (xxx == null)。第四个习惯是日志里不打印敏感数据。身份证号、手机号必须打码后输出，toString()方法也不要输出密码字段。这些习惯在代码审查时最容易暴露也是面试官最爱追问的点。6.3 电子病历系统的扩展建议如果时间和精力允许，推荐给项目增加这两个方向：一是病历质控规则引擎。比如定义一个简单的规则：诊断结果填写了，但没有对应检查检验记录，标记为"待完善"。规则引擎可以是一组判断逻辑，不必上Drools这种重框架，但体现了对医疗逻辑的理解。二是数据大屏。用ECharts做一个医院运营驾驶舱，展示今日门诊量、病历完成率、科室排行、药占比等指标。前端大屏+后端聚合查询接口是很多毕业设计里最抢眼的部分，医疗数据的可视化呈现本身就是一个独立的技能点。7. 写在最后：这套系统让我学到的三件事做完这个Spring Boot电子病历管理系统后，我的感觉是：技术上没有特别难的点，难的是把业务规则梳理清楚，并且让代码结构能持续承接新的需求。三个心得体会分享一下。第一，写出"能跑"的代码和写出"能维护"的代码是两码事。电子病历这类系统，最大的风险不是功能不够多，而是改一个字段要连带改七八个文件还没改全。所以在项目初期就花时间把VO、DTO、Entity分层划分清楚，接口路径规划合理，看起来多花了半天时间，后面省下的时间远超过这些。第二，医疗系统的开发必须重视"留痕"。纸质病历时代靠签字，电子病历时代靠操作日志和数据版本。日志切面、状态记录表这些基础能力一定要搭好，往后的所有功能都依赖这层地基。第三，真实的开发流程永远是先理解业务再写代码。做患者列表之前，先搞清楚什么是门诊号什么是住院号；做医嘱模块之前，先明白药品频次的含义。不要拿起代码就写，这个习惯无论在哪个行业项目里都适用，但医疗领域尤其不能犯。如果手上有这个源码，建议不要只停留在"能跑起来"的程度。找一个真实的业务流程，比如"患者挂号→医生接诊→书写病历→开立医嘱→护士执行"，把整条链路的接口和数据流走一遍，比单纯堆CRUD接口有用得多。这套系统还可以继续扩展护士工作站、药房管理、费用结算等模块，每一个模块都可以独立成章，整套做下来，你对医院信息系统的理解就已经超过很多只做过后台管理系统的开发者了。
1. 项目概述与核心需求拆解做医疗信息系统的开发，其实是一件挺特殊的事。它和做电商、做内容管理完全不一样，最大的差别在于——病历数据是受严格监管的敏感数据，而且业务链条极长：从门诊医生接诊，到书写病历、开立医嘱，再到护士执行、药房发药、检验检查回报，最后到收费结算，任何一个环节出问题，都会直接影响医疗质量和患者安全。所以当我看到"Spring Boot电子病历管理系统"这个题目时，第一反应是：这不仅仅是一个简单的CRUD练习，而是涵盖医疗核心业务场景的完整系统设计。通常这类项目在企业里归属于HIS（医院信息系统）中的EMR（Electronic Medical Record，电子病历）子系统，前端医生工作站通过它完成患者病历的创建、编辑、审阅、归档和质控。适合参考这个项目的人群很明确：刚学完Spring Boot想找一个完整全栈实践项目的开发者，需要做毕业设计或课程设计的在校学生，以及刚进入医疗信息化领域、想快速了解业务模型的新人。这个系统解决的核心问题就是——让纸质病历电子化，让病历书写从手写改为结构化录入，同时提供权限控制、版本留痕和辅助质控能力。从技术角度讲，Spring Boot是目前Java后端开发最主流的选择，没有之一。它对繁琐的Spring配置做了大量自动化处理，内嵌Tomcat、默认提供健康检查和生产级运维端点，配合Spring Data JPA或MyBatis都能快速搭建一套可运行的服务。而电子病历系统选择Spring Boot，还有一个产业层面的原因：医疗信息化系统大多跑在医院内网的独立服务器上，需要稳定、易维护、可独立部署，Spring Boot打一个jar包扔到服务器上就能跑，这种轻量级特性对医院运维非常友好。在功能维度上，一个可用的电子病历系统通常至少包含这五块：患者管理：登记患者基本信息，生成住院号/门诊号，提供查询与关联操作病历文书管理：包括门急诊病历、住院病历、病程记录、出院小结等，支持按模板创建、编辑与归档医嘱管理：长期医嘱与临时医嘱的新建、作废、停止，关联计价与执行状态系统权限与审计：基于角色的访问控制（RBAC），记录谁在什么时间改了什么内容数据统计：基础的就诊量、病历完成率、归档率等指标的查询如果做的是毕业设计，建议在此基础上再增加一个可视化数据面板，展示历日就诊趋势、科室工作量排行等，会明显提升项目的完整度和答辩亮点。2. 核心技术栈与整体架构设计2.1 后端技术选型：为什么是Spring Boot + MyBatis-Plus电子病历系统的技术选型需要考虑数据一致性和开发效率的平衡。我见过不少团队在医疗项目里盲目引入微服务、分布式事务，结果把一个门诊病历保存流程拆成四五个服务调用，最后光排查问题就花了一周。对于这样一个系统，单体应用加模块化设计是完全够用的。后端我推荐这套组合：组件选型说明核心框架Spring Boot 2.7.x稳定、社区资料多，内嵌Tomcat，打jar部署方便ORM框架MyBatis-Plus代码生成效率高，内置分页插件，避免写大量XML数据库MySQL 8.0支持JSON字段和窗口函数，病历内容存储灵活权限方案Spring Security + JWT无状态鉴权，适合前后端分离架构缓存Redis验证码、token黑名单、高频字典数据缓存接口文档Knife4j基于Swagger的增强文档，支持离线文档导出工具库Hutool日期解析、加密、Excel导出等实用工具，减少重复代码MyBatis-Plus在简单CRUD场景下能省掉大量重复的Mapper方法，自带逻辑删除和乐观锁插件，刚好匹配病历系统中"记录不能物理删除、修改要留痕"的需求。实体类上加@TableLogic注解，删除操作就自动变成UPDATE，这是一个很实用的细节。2.2 数据库设计：病历数据怎么建模数据库模型是整个系统的地基，医疗项目尤其讲究字段的完整性和溯源能力。核心表可以这样规划：patient表：患者主索引，字段包括姓名、性别、出生日期、证件号、联系电话、血型、药物过敏史。过敏史一定要单独冗余存一份字符串，写进病历的时候直接带出来，不能靠联查，这是从安全角度考虑的，医生开处方时第一时间能看到。medical_record表：病历文书主表，包含患者ID、就诊类型（门急诊/住院）、就诊科室、主诉、现病史、既往史、体格检查、诊断结果、医生ID、病历状态（草稿/提交/归档/驳回）。关键点在于每个状态变更都要在record_status_log表中留一条轨迹。medical_record_detail表：有些设计把病历大字段单独拆表，用record_id关联，存放完整的富文本内容。拆表的逻辑是——列表页只需要查主表，只有打开详情时才加载大字段，能有效减轻数据库IO压力。diagnosis表：诊断信息，关联ICD-10编码，支持一条病历多个诊断，需要设置主诊断标记。prescription表 / prescription_item表：处方主表和明细表，一对多设计，明细记录药品名称、规格、单次剂量、频次、途径、天数、数量。sys_user表、sys_role表、sys_user_role表、sys_menu表：标准的RBAC四件套。这里特别要强调create_time和update_time字段不要用数据库的DEFAULT CURRENT_TIMESTAMP简单带过。代码里通过MyBatis-Plus的MetaObjectHandler统一填充，同时记录操作人。这样出了问题可以明确回答：是谁、在什么时间、把这个字段从什么值改成了什么值。2.3 前端技术栈与前后端交互前端建议使用Vue3 + Element Plus + Pinia + Axios。如果不想从零搭建工程，可以直接使用现成的后台管理模板，比如RuoYi-Vue这种开源脚手架也有不少医疗Demo，但直接用模板有一个问题——大量代码不是你写的，答辩问答环节容易被问住。我建议是搭好基础工程后，核心的业务组件（病历编辑器、处方录入、患者列表）自己动手写一遍。接口交互走RESTful风格，统一返回结构：public class Result<T> { private Integer code; private String message; private T data; }前端通过Axios拦截器统一处理401跳转和500错误提示，请求头携带Authorization字段作为JWT令牌。3. 详细设计：核心功能模块如何落地3.1 患者管理模块：别小看了这个模块很多人觉得患者管理不就是增删改查嘛，很简单的。但在实际医疗业务中，患者主索引是有讲究的——同一个患者可能用不同证件号挂过好几次号，也可能出生日期填错了。所以患者注册接口一定要加唯一性校验，用一个id_card_no + phone的组合去匹配已存在的记录，查到就提示"已存在患者，请确认是否复用"。在真实项目中还会引入主索引服务做相似度匹配，这里先不展开。患者注册页建议校验的字段至少包括：姓名不能为空，长度2~20出生日期不能晚于当前日期证件号如果填写，必须通过正则校验（身份证18位或护照等）联系方式必须为11位手机号或有效座机号3.2 病历文书管理：让医生能"写"也能"改"电子病历最大的痛点就是书写效率。老医生的打字速度不一定快，但如果让他用鼠标点几百个下拉框，他更不乐意。比较务实的方案是——提供可配置的病历模板。比如"首次病程记录"模板，把主诉、现病史、既往史、体格检查等段落排版好，医生只需要填写具体内容，必要时一键带入患者基本信息和历史诊断。这个模块在技术实现上有一个关键设计，就是分段存储。病历正文不能简单存一个超长字符串，而是拆成多个段落块，每个段落块有独立的标识和排序值。这样做的目的有两个：一是后续做病历质控时，可以针对"现病史"这种特定段做内容完整性校验；二是支持段落级别的修改留痕，而不是整篇文档替换。一段简化版的段落数据存储结构：CREATE TABLE record_segment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, record_id BIGINT NOT NULL COMMENT '病历主表ID', segment_key VARCHAR(50) NOT NULL COMMENT '段落标识，如chief_complaint', segment_name VARCHAR(100) NOT NULL COMMENT '段落显示名称', content TEXT COMMENT '段落内容', sort_order INT DEFAULT 0, create_by BIGINT, create_time DATETIME, update_by BIGINT, update_time DATETIME );前端富文本编辑器我推荐使用WangEditor或TinyMCE，不要再自己封装contenteditable了，踩过的坑太多了——光标丢失、粘贴格式混乱、浏览器兼容性问题，数都数不过来。WangEditor对Vue的支持相对友好，可以在工具栏里只保留医学文书需要的功能：加粗、字体、字号、标题、列表、表格、图片上传。3.3 病历审阅与质控这块属于系统的"管理后台"能力，也是能在答辩中体现出业务思考的部分。系统内置两个角色：住院医生（书写病历）和主治医生/科室主任（审阅病历）。审阅流程走状态机：草稿（DRAFT）→ 提交待审（SUBMITTED）→ 审阅通过（APPROVED）→ 归档（ARCHIVED）审阅不通过则回到DRAFT状态，并附带驳回意见状态流转在代码里建议用枚举封装：public enum RecordStatus { DRAFT(0, "草稿"), SUBMITTED(1, "待审阅"), APPROVED(2, "已通过"), ARCHIVED(3, "已归档"), REJECTED(4, "已驳回"); private final Integer code; private final String description; }每次状态变更写入record_status_log，保证全链路可追溯。在病历归档之后，要禁止再编辑。这一点在Controller层要通过状态校验拦截，不能只靠前端隐藏按钮。3.4 医嘱管理：数量、频次、剂量都不允许将就医嘱模块是医疗系统里面最容易出"问题"的地方，因为它直接关系到患者用药安全。一个合格的医嘱录入接口至少要包含以下校验：单次剂量必须大于0，并且剂量单位不能为空频次必须从字典表中选择（qd、bid、tid等），不允许自由输入天数必须是正整数，且不能超过系统限制作废医嘱必须填写作废原因，保证用药过程有据可查这里还要说一个细节，就是医嘱id和处方id的关系。一张处方可以包含多条医嘱，每条医嘱关联到具体药品主数据。药品主数据表要有统一的规格和厂家信息，录入时不能允许医生自己"造"药品。真实系统里药品字典是药房维护的，这里简化为管理员后台维护即可。4. 实战编码：从零搭建Spring Boot后端核心流程4.1 项目初始化与依赖配置用Spring Initializr或者直接在IDE里创建项目时，推荐的Java版本是8或11。不是越新越好——很多医院客户的服务器运行的还是CentOS 7环境，预装的JDK可能是1.8，如果项目用Java 17的语法，到了部署阶段就会发现自己给自己挖了个坑。Java 8 + Spring Boot 2.7是稳妥到不能再稳妥的组合。pom.xml核心依赖示例：<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>3.19.2</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>这里特别提一下Lombok在医疗项目中的使用态度。实体类加上@Data确实能少写很多getter/setter，但有一个隐患——如果项目后续需要做大量字段级的操作审计，IDE的getter和setter方法在断点调试时反而不直观。我的建议是简单DO类用Lombok，DTO/VO类上手动写构造方法，这样日志输出的字段能精确控制。4.2 JWT鉴权与RBAC权限控制Spring Security的配置是整个项目安全性的地基。B站上很多教学视频教你把Spring Security整个关闭然后自己写拦截器，这种方案在真实项目中是绝对不推荐的。正确的方式是使用Spring Security的过滤器链，通过自定义OncePerRequestFilter解析令牌，并把用户信息和权限列表放入SecurityContextHolder。核心配置类片段：@Configuration @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { @Resource private JwtAuthenticationFilter jwtAuthenticationFilter; @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers("/api/auth/login", "/api/auth/captcha").permitAll() .antMatchers("/api/patient/**").hasAnyRole("DOCTOR", "NURSE", "ADMIN") .antMatchers("/api/medical-record/**").hasRole("DOCTOR") .antMatchers("/api/system/**").hasRole("ADMIN") .anyRequest().authenticated() .and() .exceptionHandling().authenticationEntryPoint(customAuthenticationEntryPoint); http.addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); } }在前后端分离的架构下，关闭CSRF并把会话策略改为STATELESS是必要的。但一定要补齐两件事：一是自定义认证入口点，返回JSON格式的401响应，而不是Spring Security默认的HTML错误页；二是配置CORS跨域，否则前端请求会被浏览器拦截。4.3 自定义注解实现操作审计电子病历系统对安全审计有天然需求——谁在什么时候访问或修改了病历，这些都不能靠自觉记录。用AOP做一个统一操作日志切面，比在每个Service方法里手动调用日志工具类优雅得多。切面实现思路：@Aspect @Component public class OperationLogAspect { @Before("@annotation(operationLog)") public void doBefore(JoinPoint joinPoint, OperationLog operationLog) { // 获取当前登录用户（从SecurityContextHolder中取） // 解析Controller方法的请求参数，提取患者ID、病历ID等关键业务字段 // 将操作日志写入sys_operation_log表 // 对于敏感操作，额外发送到消息队列做异步存储 } }为操作日志加上查询条件（操作人、操作时间范围、患者ID、操作类型），这部分是病历溯源能力的有力补充。答辩时如果能主动提到这个设计，说明对医疗系统的合规性有基本认知，比干巴巴说"我做了登录功能"好太多。4.4 前端核心页面：病历录入与患者列表患者列表页使用Element Plus的el-table，配合分页组件。后端分页查询使用MyBatis-Plus的Page对象：@GetMapping("/patient/list") public Result<IPage<PatientVO>> list(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, PatientQueryDTO queryDTO) { Page<Patient> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Patient> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(queryDTO.getName()), Patient::getName, queryDTO.getName()) .eq(StringUtils.hasText(queryDTO.getIdCardNo()), Patient::getIdCardNo, queryDTO.getIdCardNo()) .orderByDesc(Patient::getCreateTime); IPage<Patient> patientPage = patientService.page(page, wrapper); // 转换为VO返回，避免把敏感字段全部暴露给前端 return Result.success(patientPage.convert(patient -> patientMapper.toVO(patient))); }病历编辑器页面是开发工作量最大的部分。建议把工具栏配置为：粗体、斜体、下划线、字体字号、编号列表、项目符号、表格、插入图片、清除格式。图片上传接口要限制文件类型，只接受jpg/png/webp，这个校验必须做在后端，前端限制一个accept属性挡不住有心的操作。5. 部署、测试与常见问题排查5.1 本地快速启动指南拿到源码之后不要着急改代码，先按这个顺序跑起来：本地安装MySQL 8.0，创建数据库emr_system，执行项目内的sql/init.sql脚本在application.yml里修改数据库账号密码，注意把时区设置为serverTimezone=Asia/Shanghai启动Redis服务（没有Redis环境可以先把验证码相关代码注释掉，不影响主流程）运行EmrApplication.java的主方法，观察控制台日志看到Tomcat started on port(s): 8080后，访问后端健康检查接口/actuator/health启动前端工程，修改.env文件中的VITE_API_BASE_URL指向http://localhost:8080/api浏览器访问前端地址，使用系统内置的管理员账号登录内置管理员账号建议设置为admin / admin123，首次登录后强制修改密码——这是我在真实项目里坚持的习惯，避免系统交付后弱口令风险。5.2 端口冲突与数据库连接超时端口占用是新手最常遇到的问题。启动时控制台报Port 8080 was already in use，解决办法有三种：杀掉占用进程（Windows下用netstat -ano | findstr 8080找到PID再taskkill /PID），或者修改application.yml里的server.port。MySQL连接超时的典型报错是Communications link failure，排查思路：确认MySQL服务是否启动：systemctl status mysqld确认防火墙是否开放3306端口确认url中的serverTimezone参数没有问题用命令行工具试连一下，排除代码问题；一般来说，先用你写在代码里的账号密码在命令行里连一次，如果连不上，问题基本不在Spring Boot，而在MySQL侧。导入SQL失败则要注意MySQL版本差异。如果你本地是5.7版本，但SQL脚本里用了JSON类型函数或utf8mb4_0900_ai_ci排序规则，就会直接报错。建议统一用MySQL 8.0，和项目的数据库版本保持一致。5.3 前后端联调时常见的"疑难杂症"登录成功后请求依然返回401：大概率是JWT没有放进请求头。检查前端的Axios拦截器，确认config.headers.Authorization = 'Bearer ' + token的写法；后端则确认JwtAuthenticationFilter是否在Security过滤器链中执行。CORS跨域报错：确认后端SecurityConfig里配置了CORS源，并开启Spring MVC的跨域支持。注意allowCredentials(true)时不能同时设置allowedOrigins("*")，这是浏览器的安全策略限制。返回给前端的日期格式是时间戳：可以在application.yml中配置：spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+85.4 医疗系统特有的注意事项这里有些经验是从真实医疗项目里总结的，虽然写的是代码，但背后都是业务约束。做电子病历系统，不能只管代码能跑，更要考虑数据安全与合规。第一，敏感字段脱敏。患者信息接口返回前端时，身份证号中间8位应该掩码处理，比如110***********1234，手机号也可以保留前3后4。前端展示时全部使用脱敏值，只有获得更高授权或者特定操作（如医生打开完整病历）才返回完整数据。这个用@JsonSerialize自定义脱敏序列化器就能统一实现。第二，备份不能省。数据库要启用定时备份任务，推荐方案是每天凌晨执行mysqldump，保留最近7天的备份文件。真到了数据误操作恢复的那一天，你会感谢这个习惯。病历数据的价值远超软件本身，这个意识在医疗行业尤其重要。第三，权限不能只在前端控制。后端接口必须做二次鉴权。前端只是用户体验问题，后端是安全问题。一个用户可以直接跳过UI调用接口，所以每个修改、删除、查询接口都要校验当前用户的角色和归属部门。6. 代码优化与答辩亮点6.1 性能优化：一张表数量过千万怎么办如果真实医院环境中的病历数量达到千万级，就必须考虑分表和索引优化了。按patient_id做哈希取模进行水平分表是一个常见方案，比如medical_record_0、medical_record_1……但这个方案的查询逻辑复杂度会明显上升，必须通过分库分表中间件处理。对于课程设计或演示项目来说，这样一个H2标题的分享内容是了解性的，但了解了不去实现也没问题。索引优化则是立刻可以做并且对性能影响非常大的：patient表id_card_no字段加唯一索引medical_record表patient_id + status加联合索引record_status_log表record_id加普通索引所有逻辑删除字段和其它高频查询条件加普通索引6.2 让代码更好维护的四个习惯第一个习惯是统一响应体。所有Controller返回值都用Result<T>包裹，不要有的返回Map、有的返回String、有的直接返回实体对象。对接前端的人是谁不重要，规范一致比什么都重要。第二个习惯是异常收敛。全局异常处理器统一捕获BusinessException和Exception，不要在每个Controller里写try-catch。医疗系统报了异常，患者那边就等着一脸懵——所以异常文案要尽量清晰，比如"该病历已归档，禁止编辑"，而不是"系统异常"。第三个习惯是参数校验前置。使用@Validated配合@NotNull、@NotBlank、@Size注解在DTO层做声明式校验，不要在Service里写一连串的if (xxx == null)。第四个习惯是日志里不打印敏感数据。身份证号、手机号必须打码后输出，toString()方法也不要输出密码字段。这些习惯在代码审查时最容易暴露也是面试官最爱追问的点。6.3 电子病历系统的扩展建议如果时间和精力允许，推荐给项目增加这两个方向：一是病历质控规则引擎。比如定义一个简单的规则：诊断结果填写了，但没有对应检查检验记录，标记为"待完善"。规则引擎可以是一组判断逻辑，不必上Drools这种重框架，但体现了对医疗逻辑的理解。二是数据大屏。用ECharts做一个医院运营驾驶舱，展示今日门诊量、病历完成率、科室排行、药占比等指标。前端大屏+后端聚合查询接口是很多毕业设计里最抢眼的部分，医疗数据的可视化呈现本身就是一个独立的技能点。7. 写在最后：这套系统让我学到的三件事做完这个Spring Boot电子病历管理系统后，我的感觉是：技术上没有特别难的点，难的是把业务规则梳理清楚，并且让代码结构能持续承接新的需求。三个心得体会分享一下。第一，写出"能跑"的代码和写出"能维护"的代码是两码事。电子病历这类系统，最大的风险不是功能不够多，而是改一个字段要连带改七八个文件还没改全。所以在项目初期就花时间把VO、DTO、Entity分层划分清楚，接口路径规划合理，看起来多花了半天时间，后面省下的时间远超过这些。第二，医疗系统的开发必须重视"留痕"。纸质病历时代靠签字，电子病历时代靠操作日志和数据版本。日志切面、状态记录表这些基础能力一定要搭好，往后的所有功能都依赖这层地基。第三，真实的开发流程永远是先理解业务再写代码。做患者列表之前，先搞清楚什么是门诊号什么是住院号；做医嘱模块之前，先明白药品频次的含义。不要拿起代码就写，这个习惯无论在哪个行业项目里都适用，但医疗领域尤其不能犯。如果手上有这个源码，建议不要只停留在"能跑起来"的程度。找一个真实的业务流程，比如"患者挂号→医生接诊→书写病历→开立医嘱→护士执行"，把整条链路的接口和数据流走一遍，比单纯堆CRUD接口有用得多。这套系统还可以继续扩展护士工作站、药房管理、费用结算等模块，每一个模块都可以独立成章，整套做下来，你对医院信息系统的理解就已经超过很多只做过后台管理系统的开发者了。