这两年做毕设指导被问得最多的方向之一就是医院信息管理系统。原因也不难理解——医院业务场景足够复杂挂号、门诊、收费、药房、住院、统计报表全都有真实业务逻辑模块一拆就是三四个独立子项目不管做毕业设计还是往简历上写都比图书管理、商城秒杀这种“标配课题”有说服力得多。但复杂也意味着坑多很多同学拿着SpringBoot起步做完登录就卡在业务设计和数据一致性上。这篇聊的就是怎么用SpringBoot把这套系统从零搭起来哪些环节值得花时间哪些坑我替你先踩了。1. 项目定位与需求分析1.1 为什么医院信息管理系统是毕业设计的好选题先说实话医院信息管理系统HIS不是什么新技术方向但它是个极其优秀的“练手综合体”。一个完整的HIS系统面向的角色至少有四类挂号收费员、门诊医生、药房管理员、系统管理员每种角色各有各的业务流程和操作界面这意味着你的系统必然是多角色、多权限、多模块的复杂业务系统而不是简单的单表增删改查。从毕业设计的评分角度来说这种复杂度天然就能撑起“工作量饱满”这一条。更关键的是医院场景里藏着大量真实业务规则退号要控制时限、处方金额要联动库存、收费单据要精确到分、药房发药要核对库存批次。这些规则一旦设计进去你的项目说明书写起来会非常扎实答辩时也有话可说——“为什么要这样设计”“这个字段为什么要冗余”“这个接口为什么做成事务”都是能体现思考深度的加分点。从技能成长的角度看HIS系统几乎把Java技术栈的常见考点全覆盖了SpringBoot搭建与配置、MyBatis分页查询、Spring Security或JWT做登录鉴权、Redis做缓存和验证码、POI导出报表、事务管理保证数据一致性。把这些技术点各学一遍不难但在一个真实业务系统里组合使用才是面试官真正想看到的。我见过太多简历写着“熟练使用SpringBoot”问项目却只有登录注册的例子HIS系统就是用来打破这种尴尬的。1.2 基层医疗机构的核心需求拆解做毕业设计时最容易犯的错是“大而全”一上来就想着做三甲医院级别的大系统结果做到一半撑不住了。我的建议是把目标对准基层医疗机构——社区卫生服务中心、乡镇卫生院、校医院这类场景。它们的业务规模适中科室设置简单不涉及复杂医技设备对接但核心流程一个不少特别适合毕业设计体量。基层医院的核心业务可以拆成五条主线门诊业务线挂号 → 候诊 → 医生接诊 → 开具处方/检查 → 收费 → 取药。这是HIS系统的骨架也是整个系统的核心流程。药品管理线药品入库 → 库存管理 → 处方核销 → 库存预警 → 效期管理。药品数据贯穿门诊和药房是最容易出现数据不一致的地方。收费财务线收费单据创建 → 退费处理 → 日终对账 → 财务报表。金额字段必须用Decimal不用Float这一点后面详细讲。住院业务线入院登记 → 床位分配 → 医嘱管理 → 费用记录 → 出院结算。如果时间紧张住院模块可以做简化版但不能完全没有。系统管理线用户管理、角色权限、操作日志、数据字典。这条线是系统的基座做得好不好直接影响前四条线的开发效率。每条业务线背后都有明确的角色需求和操作流程。比如门诊医生需要看到患者的历史就诊记录、当前挂号信息开处方时要能查看药品库存和价格药房管理员需要实时看到待发药处方收费员需要快速完成收费退费并且日终汇总。这些需求在需求分析阶段就要理清楚越细致越好因为它们直接决定后面的数据库表怎么设计、接口怎么规划。1.3 技术选型SpringBoot为什么是合适的选择医院信息管理系统这种场景选SpringBoot我不觉得有什么悬念。SpringBoot带来的核心价值是降低了集成的门槛。以前SSH或SSM时代配置文件动辄上百行光是一个事务管理器就要写半天空闲时间都消耗在环境配置和依赖冲突上而SpringBoot通过自动配置和起步依赖Starter把这些问题基本藏了起来让我们能把注意力集中在业务代码本身。具体到HIS系统SpringBoot的优势有三点生态成熟MyBatis-Plus、Spring Data JPA、Spring Security、Redis、MinIO这些常用组件都有对应的Starter引入依赖加上简单配置就能跑起来不用自己造轮子。部署成本低打包成Jar文件后服务器上只要装个JDK就能运行不需要额外配置Tomcat容器。对于毕业设计演示和部署这点特别省心——一台Windows或Linux服务器一行java -jar命令搞定。资料丰富这也是很现实的一点。遇到问题搜索时SpringBoot的解决方案覆盖面是最广的无论你卡在拦截器、过滤器还是事务回滚基本都能找到现成的参考案例。相比冷门框架你的开发效率会高很多。有些同学会纠结要不要用微服务架构来显得高级我的建议是不要。单体应用完全够用微服务的服务拆分、注册发现、远程调用、分布式事务这些问题在HIS项目里不但帮不上忙还会把问题搞复杂。毕业设计的核心是把业务做完整、做扎实不是架构炫技。2. 系统架构设计与数据库建模2.1 前后端分离架构与单体后端设计今年选择前后端分离架构的毕业设计越来越多这是好事。前端用Vue或React后端用SpringBoot提供JSON接口分工清楚、调试方便也更贴近实际工作场景。但在架构设计上有一个容易被忽略的点前后端分离不等于后端可以不用管页面逻辑了。我的做法是后端从设计阶段就明确输出API文档用Swagger或Knife4j生成接口文档前端只需要按照接口约定去开发。这样两边可以并行推进进度不互相拖累。接口设计上遵循RESTful风格资源的增删改查对应POST、DELETE、PUT、GET路径语义化比如/api/patients、/api/prescriptions、/api/drugs一眼就能看出调的是什么。后端部分我采用经典分层架构Controller层接收参数、校验参数、返回结果。不写业务逻辑只做接口的“门面”。Service层业务逻辑的核心。事务在这里控制业务规则在这里落地。Mapper层数据访问层用MyBatis-Plus内置的方法加自定义SQL完成数据库操作。实体层PO/VO数据库表对应的实体类加上传给前端用的视图对象VO。有一件事我在指导时反复强调Controller层和Service层要区分开不要图省事把业务逻辑写进Controller里。一开始可能觉得没什么但模块一多之后代码会迅速腐化成一个巨大的不可维护类排查问题时特别痛苦。分层的成本很低收益却很高。2.2 核心数据库表设计思路数据库设计是整个项目的灵魂。表设计不合理后面开发步步为艰表设计合理了业务代码写起来行云流水。HIS系统的核心表我列一下每张表附上几个关键字段和设计考量用户与权限sys_user用户表id、username、password加密存储、real_name、role_id、status。密码必须加密我建议用BCrypt不要用MD5MD5是可逆字典查询的。sys_role角色表id、role_code、role_name、description。角色和数据字典一样属于系统的基础数据独立成表便于扩展。sys_menu菜单表id、parent_id、menu_name、menu_url、perms。菜单和权限绑定前端通过接口获取菜单列表动态生成路由。患者与挂号patient患者表id、patient_no病历号、name、gender、birth_date、phone、id_card。病历号是业务主键建议用时间戳加序号生成保证唯一性。registration挂号表id、patient_id、doctor_id、department_id、regist_date、regist_type、fee、status。status字段是关键区分已挂号、已完成、已退号等状态。门诊与处方medical_record就诊记录表id、patient_id、doctor_id、visit_date、chief_complaint、diagnosis、treatment_advice。主诉和诊断是文本字段建议用TEXT类型。prescription处方表id、record_id、patient_id、doctor_id、total_amount、status。一个就诊记录可以对应多个处方所以单独建表。prescription_item处方明细表id、prescription_id、drug_id、drug_name、specification、quantity、price、amount。明细表里冗余药品名称和规格是为了报表查询时不用反复关联药品表这是一种常用的反规范化设计。药品与库存drug药品表id、drug_code、drug_name、specification、unit、price、stock_quantity、alert_quantity、manufacturer。库存字段单独放在主表里还是单独建库存表取决于业务复杂度。基层医院放到主表就够用。stock_record出入库记录表id、drug_id、change_type入库/出库、change_quantity、before_quantity、after_quantity、operator_id、create_time。这张表是审计追溯的关键任何库存变动都要留痕。收费与财务charge_record收费记录表id、charge_no、patient_id、total_amount、refund_amount、status、create_time、cashier_id。收费记录是财务类报表的基础字段尽量冗余完整。settlement_record日结表id、cashier_id、start_time、end_time、total_income、total_refund、status。用于收费员日终交接是基层医院真实存在的需求。这里我用了大约9张核心表实际项目还会有数据字典表、操作日志表、公告表等总共十五张左右。对于毕业设计来说这个规模刚好既不显得内容单薄也不至于不可完成。2.3 字段类型选择与金额处理的讲究数据库设计里有一个特别容易踩坑的点金额字段用错了类型。很多同学喜欢用Float或Double存金额最后报表对账对不上小数点后多几位。原因很简单浮点数在计算机里是用二进制表示的很多十进制小数比如0.1无法精确表示运算时会出现误差。医院收费场景金额是必须精确的差了1分钱都是事故。解决方案是使用Decimal类型。Java中用BigDecimal对应处理MySQL中用DECIMAL(10,2)来存储小数点后精确到分。这是做过真实财务系统的人一定会强调的点毕业设计里用对会显得很专业。日期时间字段也要注意。统一使用datetime类型Java侧用LocalDateTime接收不要用DateLocalDateTime有更清晰的时区处理配合JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解前端拿到的就是格式化好的字符串。还有一个细节每个表都要有create_time、update_time字段。MyBatis-Plus有自动填充功能通过MetaObjectHandler实现插入和更新时自动填充不用每个Service层方法里手动写一遍。3. 核心功能模块的技术实现细节3.1 基于JWT的登录鉴权与权限控制医院信息管理系统涉及多个角色登录鉴权和权限控制是系统安全的第一道防线。这里我选用了JWTJSON Web Token方案配合Spring Security来实现。JWT的原理不复杂用户登录成功后后端生成一个Token返回给前端前端在后续请求中放到请求头通常是Authorization: Bearer token后端通过拦截器或过滤器校验Token有效性并从中取出用户信息。实现思路如下登录接口接收用户名和密码用BCryptPasswordEncoder校验密码。密码校验通过后查询用户角色和权限列表。生成JWT Token把用户ID和角色信息放进Token的payload部分设置过期时间24小时够用。配置一个拦截器或过滤器在doFilterInternal方法中解析请求头里的Token校验签名和过期时间然后把用户信息放到SecurityContextHolder里。通过PreAuthorize(hasAuthority(doctor))或Spring Security的配置方法对不同接口做权限控制。需要注意的一个常见坑Spring Security的过滤器链和SpringMVC的拦截器执行顺序不一样。Spring Security是Servlet层的过滤器在请求进入Controller之前就会生效而SpringMVC的拦截器是在DispatcherServlet内部的。如果你用了Spring Security做JWT解析就不需要再额外写拦截器去解析Token了否则会出现Token被解析两次的情况。两种方式用其一即可不要混着来。另外一个细节定义登录接口时不要加权限校验否则自己把登录入口关死了。3.2 挂号流程与并发处理的思考挂号模块看起来简单无非是选择科室、选择医生、填写患者信息、提交但这里面藏着一个真实业务问题并发。如果一个专家号源剩余1个两个患者同时提交挂号怎么办如果不在代码层面做控制数据库层面的更新就会出错设计出两个人都挂上号的情况。解决方案并不复杂两种思路数据库乐观锁在号源表registration_schedule排班表里加一个version字段更新时用UPDATE ... SET stockstock-1, versionversion1 WHERE id? AND version?影响行数为0说明更新失败提示用户号源已满。这种方式简单可靠适合毕业设计。Redis分布式锁用Redis实现一个简单的锁提交挂号的请求先去获取锁拿到锁才能操作号源操作完释放锁。在高并发场景下这是标准解法但会引入Redis依赖。毕业设计用乐观锁就足够了实现简单也好解释。但有一个更实际的问题容易被忽略挂号要检查号源库存号源库存是哪里来的这需要从排班模块说起——门诊医生每周有出诊计划表需要管理员提前维护号源数量挂号时扣减号源。如果连排班和号源都没有挂号模块就只是往registration表插一条记录业务逻辑会显得单薄。所以在做挂号模块之前我建议先花时间把排班表schedule表设计好包含医生ID、出诊日期、上午/下午时段、总号源数、剩余号源数这几个核心字段。有了排班挂号、医生工作量统计、号源余量查询都有依托。3.3 门诊开药与库存扣减的事务一致性门诊医生开处方是整个系统里最有业务价值的功能。前端页面是一个表单患者信息是只读的位于页面顶部中间是诊断信息输入区下方是药品明细列表支持动态添加和删除最后是合计金额。前端提交的数据结构是嵌套的一个处方主记录prescription带着一个处方明细列表prescription_item。后端处理这个提交必须在一个事务方法里完成Transactional(rollbackFor Exception.class) public PrescriptionVO createPrescription(PrescriptionDTO dto) { // 1. 保存处方主记录 Prescription prescription new Prescription(); prescription.setPatientId(dto.getPatientId()); prescription.setDoctorId(dto.getDoctorId()); prescription.setTotalAmount(calculateTotalAmount(dto.getItems())); prescription.setStatus(1); // 状态待收费 prescriptionMapper.insert(prescription); // 2. 批量保存处方明细并扣减药品库存 for (PrescriptionItemDTO item : dto.getItems()) { PrescriptionItem prescriptionItem new PrescriptionItem(); // 设置字段... prescriptionItemMapper.insert(prescriptionItem); // 扣减库存 Drug drug drugMapper.selectById(item.getDrugId()); if (drug.getStockQuantity() item.getQuantity()) { throw new BusinessException(药品库存不足 drug.getDrugName()); } drug.setStockQuantity(drug.getStockQuantity() - item.getQuantity()); drugMapper.updateById(drug); // 记录出入库流水 StockRecord record new StockRecord(); record.setDrugId(drug.getId()); record.setChangeType(2); // 出库 record.setChangeQuantity(-item.getQuantity()); stockRecordMapper.insert(record); } return convertToVO(prescription); }这里面的关键点是Transactional注解它是一个事务拦截器方法执行过程中如果抛出RuntimeException会自动回滚前面所有的数据库操作。但注意MySQL的InnoDB引擎默认自动提交事务回滚只对被事务管理的方法有效。我写代码时习惯加上rollbackFor Exception.class因为默认配置只对运行时异常RuntimeException回滚被检查异常Checked Exception不回滚。如果你用SpringBoot默认配置抛出一个IOException事务不会回滚这是一个很容易踩的坑。另外库存足不足的判断要在扣减前完成写代码时先select再判断再update之间是有并发窗口的理论上A用户和B用户同时查询库存都看到剩余1然后同时扣减就会变成-1。这在毕业设计里问题不大但如果你想在答辩时有亮点可以在Drug表中加version字段做乐观锁更新时带version条件。这一个细节就能说明你懂并发控制。3.4 收费退费模块的边界处理收费模块是医院信息管理系统里和数据交互最密集的模块之一——收费员根据患者的ID查询待收费处方确认金额点击收费处方状态随之变为已收费药房收到信息准备配药。核心逻辑不复杂但退费就有讲究了。退费要控制两个边界能不能退和退多少。能不能退要检查处方状态是否为已收费已发药的处方不能直接退费必须先退药退多少要支持全额退费和部分退费部分退费后处方状态保留已收费状态已退金额累计起来。我设计收费记录charge_record的时候就考虑了这一点表里有total_amount、refund_amount、status三个字段。status表示收费状态0待收费、1已收费、2已退费、3部分退费。后端退费接口的业务逻辑Transactional(rollbackFor Exception.class) public void refund(RefundDTO dto) { // 校验处方状态 Prescription prescription prescriptionMapper.selectById(dto.getPrescriptionId()); if (prescription.getStatus() ! 1) { throw new BusinessException(该处方不在可退费状态); } // 查询收费记录 ChargeRecord charge chargeMapper.selectByPrescriptionId(prescription.getId()); // 校验退费金额 if (dto.getRefundAmount().compareTo(charge.getTotalAmount().subtract(charge.getRefundAmount())) 0) { throw new BusinessException(退费金额超出可退金额); } // 更新收费记录累计退费金额 charge.setRefundAmount(charge.getRefundAmount().add(dto.getRefundAmount())); chargeMapper.updateById(charge); // 更新处方状态 if (charge.getRefundAmount().compareTo(charge.getTotalAmount()) 0) { prescription.setStatus(2); // 全额退费 } else { prescription.setStatus(3); // 部分退费 } prescriptionMapper.updateById(prescription); // 记录退费流水 }退费的时候还涉及药房退药、库存加回这些操作都在同一个事务里处理保证要么全部成功要么全部失败。这里还可以延伸出一个毕业设计的加分项每一笔退费都要有操作日志记录谁在什么时间退了费、退费金额、退费原因方便财务审计。3.5 药品库存管理与MinIO的文件上传场景药品库存管理通常包含三个要点商品主数据维护、出入库管理、库存预警。药品主数据包括药品名称、规格、生产厂家、批准文号、价格、库存上下限出入库管理就是入库单和出库单的录入审核库存预警则是在药品库存低于预警值时后台展示提醒。库存预警的实现很简单写一个定时任务或者叫调度任务每天凌晨扫描所有药品库存如果stock_quantity alert_quantity就生成一条预警记录或推送通知。SpringBoot里用自带的Scheduled注解就能实现定时任务不需要引入额外框架。演示的时候把一个药品库存改到预警值以下第二天打开系统就能看到预警信息效果很直观。MinIO在这里派得上用场的地方有两个一是药品批文/说明书的扫描件管理二是检验检查报告的上传与在线查看。MinIO是一个开源的兼容S3协议的对象存储服务直接用Docker就能部署docker run -d --name minio -p 9000:9000 -p 9001:9001 \ -e MINIO_ROOT_USERminioadmin \ -e MINIO_ROOT_PASSWORDminioadmin \ minio/minio server /data --console-address :9001SpringBoot集成MinIO很顺手先引入minio依赖配置好endpoint、accessKey、secretKey、bucket名称封装一个上传下载的Service类。上传时生成一个UUID作为文件名避免文件名冲突和路径穿越问题。要注意的是MinIO的前提是服务器上能部署服务或者用本机服务毕业设计演示环境里用本机部署最方便。3.6 数据报表与POI导出报表统计是毕业设计要求里的重要部分也是医院管理系统里被频繁要求的功能之一。门诊工作量报表要统计每名医生每天接诊了多少患者收费日报要统计每个收费员一天收了多少钱、退了多少费还有科室收入排行、药品消耗排行等。报表的展示用前端图表库ECharts最方便后端返回统计数据JSON就好。比如门诊量趋势图前端按日粒度发起请求后端SQL按日期分组统计数据。到了报表导出环节就要用Apache POI了。POI导出的核心思路是查出数据 → 创建Workbook → 创建Sheet → 创建Row和Cell → 写入数据 → 输出到HttpServletResponse的OutputStream。SpringBoot里封装成一个导出工具类按模板填充数据后设置响应头Content-Disposition: attachment; filenamexxx.xlsx前端就能直接下载excel。有一点要注意文件名要做URL编码处理否则中文文件名在浏览器里大概率乱码。单元格的内容类型也要处理好数字要用setCellValue(0.1)日期要用setCellValue(new Date())并设置单元格格式否则会显示成双整数值。这些小细节虽然不影响功能正确性但用过一次Excel导出的都知道乱码和时间格式不对会让人立刻对系统印象大打折扣。4. 开发过程中的典型问题与排查实录4.1 MyBatis-Plus分页插件不生效的真相很多同学刚用MyBatis-Plus做分页时都会遇到一个情况明明配置了分页插件但返回的total永远是0或者分页没有真正生效。其实原因基本都是同一个分页插件没有正确注册到MyBatis拦截器链中。在SpringBoot 3.x版本里MyBatis-Plus分页插件的正确配置方式是这样的Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这里的重点是DbType.MYSQL要正确指定因为不同数据库方言生成的分页SQL不一样。比如MySQL用LIMITOracle用ROWNUMPostgreSQL用OFFSET如果指定错了生成的SQL就会出错。还有一个问题容易被忽略PaginationInnerInterceptor的注入时机。如果你用了多个拦截器要把分页拦截器放在最后一个否则分页SQL可能会被其他拦截器处理掉。另外记得加上MapperScan注解不然Mapper接口扫描不到项目启动就会失败。4.2 全局过滤器处理上传PDF时的XSS防护XSS跨站脚本攻击在Web应用里是个老问题医院信息管理系统里患者主诉、诊断意见这些字段经常需要录入文本如果不做防护恶意代码能通过文本内容注入到页面上执行。很多同学在处理XSS时走极端把所有参数都做HTML转义结果用户提交的富文本内容被转义到面目全非或者干脆在Controller里一个一个字段手动过滤累死累活还没过滤全。比较务实的做法是注册一个全局过滤器统一拦截请求参数做清洗。针对上传PDF等二进制文件的接口要特殊处理因为文件流的Body不能像文本参数那样做转义否则文件会损坏。我这里的解决方案是过滤器解析请求参数再做HTML标签过滤但判断ContentType是multipart/form-data或文件上传请求时直接放行不碰文件Body。Component public class XssFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; String contentType req.getContentType(); if (contentType ! null contentType.contains(multipart/form-data)) { chain.doFilter(request, response); return; } chain.doFilter(new XssHttpServletRequestWrapper(req), response); } }XssHttpServletRequestWrapper继承HttpServletRequestWrapper重写getParameter、getParameterValues、getHeader方法返回过滤后的内容。思路不难核心是用一个包装器把原始请求包一层在读取参数时做清洗这是Servlet规范里标准的装饰器模式面试时能讲清楚会很加分。4.3 分布式环境下的数据一致性简析HIS系统虽然单体就够用但数据一致性仍然是答辩时一个高频考点。比如挂号和收费是两个接口如果患者在挂号后、收费前的间隙里不想看了要退号或者收费成功后药房没有收到消息——这些场景一旦设计不严谨就会出现数据不一致。单体应用的事务管理已经能解决绝大多数问题但数据一致性的话题不止事务层面。我的建议是在事务边界之外把关键的业务状态流转状态机化。挂号有未支付/已支付/已退号三种状态处方有待收费/已收费/已发药/已退费状态每笔状态变更都记录日志。状态机 日志审计这八个字足够撑起答辩时的数据一致性话题了。如果想让系统更具说服力可以提一下消息队列的思路收费成功之后发一条消息到药房队列药房系统接单后发药发药后回调更新状态这是真实分布式HIS系统的常见落地方式。作为设计方案提出来再说明单体环境里用同步调用事务就能完成这一层对比能体现出你思考的深度。4.4 Jar包部署与反编译排查的经验部署阶段SpringBoot应用的交付物是一个可执行的Jar包对于毕业设计和实际项目都一样。演示环境里服务器上装好JDK把Jar包传上去java -jar hospital-system.jar就能启动。如果要让系统在后台运行用nohup命令加上换行符nohup java -jar hospital-system.jar --server.port8080 app.log 21 这时常遇到一个窘境在开发环境跑得好好的功能部署后发现不对或者有人传上来一个Jar包让我们改需求但源码丢了。这时候就要用到反编译了。Java的字节码反编译工具里我用得最多的是JD-GUI和CFRCFR是命令行工具适合批量反编译JD-GUI则是图形界面直观。反编译后生成的Java代码无法完全还原源码比如注释、泛型信息、常量折叠但足够用来理解逻辑和修改小问题。由于Jar包里包含class文件的索引直接解压后拿.class文件反编译是最常见的方式。有一个经验值得记下来最好在开发阶段就养成保留源码仓库镜像的习惯可以放到本地私有仓库或者云代码托管平台反编译只是兜底方案拿反编译代码去二次开发效率低到崩溃。4.5 典型问题速查表开发过程中遇到的各类问题和解决思路我整理成了一张表方便速查问题现象可能原因解决建议登录后请求API返回401Token过期或未正确放入请求头检查前端拦截器是否设置了Authorization头后端过滤器放行路径是否配置正确前后端联调跨域报错未配置CORS在SpringBoot中添加CorsFilter配置允许指定来源和请求方法生产环境不要用*全部放开分页查询total始终为0分页插件未注册或方言错误确认MybatisPlusInterceptor中PaginationInnerInterceptor是否正确指定DbType金额运算结果多了小数点使用了Float/Double全局替换为BigDecimal和DECIMAL(10,2)四舍五入用RoundingMode.HALF_UP事务不回滚Exception处理不当Transactional(rollbackFor Exception.class)确保异常不会被Service层捕获吞掉上传的PDF文件打开损坏过滤器过滤了二进制流在XSS过滤器中放行multipart/form-data请求或对文件流单独处理数据库字段带下划线映射不全MyBatis-Plus驼峰映射未开启配置mybatis-plus.configuration.map-underscore-to-camel-casetrueJar包启动时报端口被占用程序未正常关闭或者端口冲突使用netstat -ano查看占用进程换端口或用kill结束进程后再启动这张表里的问题都是真实开发中反复出现的配置检查时可以先按表排查一遍能省下不少时间。4.6 最后的避坑心得回头梳理这个项目我很想给正在做类似毕业设计的同学几个挤掉水分的建议。第一个建议是设计先行数据库表和接口定义一定要先写文档再有代码别在Controller和Mapper里“边写边改”。HIS系统的核心是业务规则数据库里少一个字段到后期补的代价是指数级增长的。第二个建议是把核心业务线串通再做功能完善。我的习惯是花前两周打通“挂号 → 就诊 → 开处方 → 收费 → 药房发药”这条主链路哪怕做得难看一点先把端到端流程跑通再回头发散增加报表、公告、日志等辅助功能。如果一开始就在药品信息维护上抠细节很容易陷入局部到主流程还没通交差日期却快到了的窘境。第三个建议是测试数据一定要仿真。不要用“张三”“李四”这种测试数据演示尽量用类似“张伟”这样的真实名字、10位手机号、标准身份证格式。仿真数据对验证前端布局、接口返回、报表统计都有帮助答辩时观感也完全不同。最后说点心态上的。做HIS系统不像做玩具项目它一定有让你头疼的业务逻辑退费规则、库存扣减、状态流转每一个都是需要认真设计才能跑顺的。但也正因为如此做完这个项目之后你会明显感觉自己对SpringBoot的理解不再停留在“会写接口”的层面而是真正理解了“用Java解决真实业务问题”是什么体验。这种实打实的进步比任何简历上的技术名词都值钱。