在基层做医疗信息管理系统最让我头疼的从来不是技术本身而是那些藏在业务细节里的“坑”。城乡居民基本医疗信息管理系统这类项目表面看是常见的增删改查实际碰过之后才会发现参保状态跟踪、报销流程流转、身份信息唯一性、年度缴费与就诊记录的关联这些业务逻辑才是真正决定系统好不好用的关键。这篇文章就围绕一个真实落地的项目展开Java SpringBoot Vue3 MyBatis MySQL 前后端分离架构的城乡居民基本医疗信息管理系统。我会从需求拆解、数据库设计、后端接口、前端页面到部署上线完整复盘整套实现思路重点讲那些平时文档里查不到、自己跑一遍才能发现的细节。适合正在做医疗类、政务类管理系统的开发者参考也适合毕业设计或者小团队自研项目的同学拿来对照。我尽量把每个环节的设计原因和踩坑过程都写清楚不只有代码还有代码背后的取舍。1. 这个系统到底在管什么需求拆解与模块设计1.1 业务背景为什么基层需要这样一套系统城乡居民基本医疗保险的特点是覆盖面广、人员基数大、参保周期固定一般按年度缴费。基层服务中心日常要处理的表格特别多居民花名册、参保登记表、缴费单据、就诊记录、报销审批单。以前线下靠Excel和纸质单据流转时最大的问题是数据分散核对一个人的参保状态可能要翻好几个文件而且很容易出现同一身份证号在不同表格里格式不一致的情况。这些系统要解决的核心问题可以概括成三句话一人一档每个居民的身份信息、参保状态、缴费记录、就诊记录都能从一条主线上串起来按年度管理参保缴费以年度为周期业务上有“未缴、已缴、补缴、停保”的状态流转报销有据可查就诊和报销记录不能随意删除审核过程要留痕。1.2 功能模块划分六个核心模块我在设计时没有把系统做成一个单页面堆砌的大杂烩而是按业务边界拆成六个模块居民信息管理居民档案的录入、修改、查询、注销身份证号唯一校验支持按姓名、身份证、参保状态多条件检索。参保缴费管理按年度办理参保登记设定缴费标准记录缴费状态生成缴费凭证编号。就诊记录管理记录门诊、住院的就诊信息包括就诊机构、就诊日期、费用明细。报销审核管理居民提交报销申请审核员核对费用明细和参保状态后生成结算单。数据统计看板统计参保率、缴费率、报销总金额等核心指标给管理者做决策参考。系统管理用户管理、角色分配、菜单权限、操作日志。模块划分的逻辑是先管人、再管钱、最后管流程。居民信息是所有业务的基础没有档案就谈不上参保更谈不上报销参保缴费决定了报销资格就诊和报销则是业务的核心出口。这样的拆分让团队协作时职责清晰前端按模块分页面后端按模块分包不会互相牵扯。1.3 核心业务流程参保到结算的完整闭环整个系统里最关键的一条链路是居民建档 → 年度参保登记 → 缴费完成 → 就诊记录登记 → 提交报销申请 → 审核通过 → 生成结算单。这条链路里有一个关键的业务规定报销资格和缴费状态是联动绑定的。也就是说在数据库层面报销记录表必须能查到对应参保年度和缴费状态如果缴费状态不是“已缴”审核环节应该直接拦截。这个规则直接影响后端接口的设计我在做报销申请接口时会先查参保记录判断状态再继续后续逻辑而不是简单地把报销单插入数据库。另外要重视的一点是逻辑删除。医疗相关数据涉及历史追溯不能物理删除一旦删了后续审计和核查就没法做了。所以所有核心业务表都加了deleted字段删除操作统一走“update deleted1”的方式。2. 技术选型为什么是这套组合2.1 后端SpringBoot MyBatis 的组合逻辑先聊聊后端。SpringBoot的优势无需多言内嵌Tomcat、自动配置、starter机制能快速把一个Web工程跑起来。对这类管理系统来说SpringBoot最实用的地方是生态成熟整合MyBatis、Druid连接池、Redis、JWT等组件都只要很少配置。MyBatis在这个项目里比Spring Data JPA更合适。管理系统的查询场景往往涉及多表关联和动态条件比如“按身份证查居民所有参保记录”“统计某年度不同乡镇的缴费人数”这类SQL用MyBatis的XML文件写非常直观想怎么join就怎么joinSQL执行计划也在掌控范围内。JPA对单表CRUD确实是强项但这种多条件组合、统计报表密集的场景实体关系映射反而让简单的问题变复杂。版本选择上我给了两个方案稳妥方案JDK 8 SpringBoot 2.7.x这也是目前大量生产项目使用的组合资料多、踩坑记录齐全。进阶方案JDK 17 SpringBoot 3.x性能更好但要注意javax到jakarta的包名迁移以及MySQL驱动升级带来的配置变化。如果你只是拿这个项目做学习或者毕业设计建议直接上SpringBoot 3.x用新不用旧如果是生产环境更推荐2.7.x稳定压倒一切。2.2 前端Vue3 Element Plus 的工程化选择前端选Vue3的核心原因是组合式API带来的代码组织方式配合