近几年带毕业设计陆陆续续接触了挺多“管理模块”类的课题像什么“XX管理系统设计与实现”“XX信息管理模块”几乎是毕业设计里的常青树。就拿这次要拆的这个“springboot定点医药单位管理模块设计与实现”来说标题看着平平无奇实际做起来门道不少——它不是单纯写个增删改查页面就能交差的背后牵扯到机构资质审核、药品目录同步、结算数据留痕还有权限体系这些破事。这篇就把我当时从需求分析到落地的完整思路重新盘一遍项目里能直接抄的配置、代码、表结构设计我都会放出来打算做同类型课题的同学可以当个参考不用从零去踩我踩过的坑。顺便说一句现在毕业设计选Spring Boot确实是个稳妥路子生态成熟、资料多、面试也能聊得上话。但正因为做的人多了想在答辩里拿出点东西就得在业务逻辑和工作流集成上下点功夫。这个项目我在基础CRUD之外加了Flowable流程引擎来处理资质审核这一块是加分项后面细说。1. 项目整体设计与技术选型思路1.1 定点医药单位管理到底管什么先把业务边界搞清楚。定点医药单位通俗讲就是和医保系统签约的药店、医院、诊所这一类机构它们能提供医保结算服务。那围绕这些机构做的管理模块核心职责就是把“机构档案—资质材料—药品服务—结算记录”这条线串起来。可能很多人拿到这个题目第一反应是“不就是管个名单嘛”真上手做需求分析就会发现没这么简单。比如一家定点药店要变更经营范围涉及执业药师资质换证谁发起申请谁审核审核通过之后药品目录需不需要同步更新结算记录出了异常是人工核查还是系统自动拦截所以我在设计时没有把系统狭义地理解成“机构信息表维护”而是拆成了几个子模块机构档案管理、资质证照管理、药品目录管理、诊疗/售药记录管理、结算数据统计外加系统层面的用户权限和操作日志。这样拆分的好处是业务边界清楚每个模块能独立开发答辩时也容易讲清逻辑。1.2 为什么是Spring Boot以及配套技术栈怎么搭课题指定Spring Boot那就围绕Spring Boot搭一套“能落地又不会太重”的技术组合。后端用的Spring Boot 2.7.x持久层用MyBatis-Plus权限认证用Sa-Token流程审核用Flowable前端用的Vue 3加Element Plus。数据库就选MySQL 8.0这套组合在真实中小型项目中也很常见。说下为什么这么选。Spring Boot本身不是新东西但它的自动配置机制确实省掉了大量XML配置尤其是起步依赖和内置Tomcat这两点让项目打包成可执行jar后直接java -jar就能跑这对毕设演示环境非常友好。MyBatis-Plus则是把单表CRUD和分页查询从“写SQL”简化成“调方法”开发效率提升明显而且它提供的逻辑删除和自动填充功能正好契合管理类系统的需求。至于Sa-Token可能有人习惯用Spring Security但毕业设计场景下Sa-Token的学习成本更低API更直观登录、鉴权、踢人下线这些功能几行代码就能接好。我当时对比过这两套方案认为安全框架不是主角够用且能讲清楚原理更重要事实上答辩老师更关注你对权限模型的理解而不是用了哪个框架。Flowable这块后面单独讲它是整个项目的亮点值得多花点篇幅。1.3 权限模型怎么设计RBAC还是更细的粒度管理类系统绕不开权限。这个项目我用的是经典RBAC模型数据库层面落地成五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。用户不直接绑权限而是通过角色间接获得菜单和操作权限。具体到定点医药单位的场景用户类型大体有三类系统管理员、机构业务员、稽核人员。管理员管用户和全局配置业务员只能维护自己所属机构的档案和药品信息稽核人员负责审核操作和数据查看。这个划分让权限控制有了实际业务含义在演示时可以直接展示“同一个按钮不同角色登录后可见性不同”的效果比空泛的“管理员/普通用户”两档要有说服力。菜单权限是粗粒度控制操作权限我用注解在接口层面做细粒度控制。比如药品上下架接口标注 SaCheckPermission(drug:changeStatus)这样即使有人绕过前端直接调接口后端也会拦截。毕业设计里能想到这一层已经是加分项了。2. 数据库设计先把表结构定明白再动手写代码2.1 核心表设计与字段含义数据库设计这块我踩过一次大坑。最早偷懒想用一张“机构信息表”包打天下把所有字段都塞进去结果做到药品目录和结算记录时被迫推倒重来。后来老老实实按业务域拆表核心表有这些。机构信息表是主表存的是定点单位的基础档案。字段包括机构编码、名称、类型药店/医院/诊所、统一社会信用代码、法定代表人、联系人电话、注册地址、经营状态、医保定点协议编号、签约开始和结束日期。其中机构编码我设置为业务主键用规则“地区码类型码序号”生成这样在后续关联药品目录和结算数据时直接用字符串匹配避免频繁Join大表。资质证照表单独设计因为一家机构会有多张证照比如《药品经营许可证》《医疗机构执业许可证》《执业药师注册证》每张证照有各自的编号、发证机关、有效期。如果把这些字段平铺到机构表里一旦出现证照增补就会很尴尬。我当时把证照信息设计成子表机构表只保留一个“资质状态”字段表示是否齐全证照记录通过机构ID关联这样既灵活又不冗余。药品目录表和服务项目表是另外两条线分别对应西药/中成药和诊疗服务项目的维护。每组数据要做定点标识是否是医保目录内品种、报销比例等字段这样结算模块就能直接引用而不是每次结算时临时去算。最后是结算记录表这个表字段最少但最关键结算单号、机构编码、就诊/购药人标识、费用总额、医保报销金额、自付金额、结算时间、操作人。这张表的定位是“不可变流水”所以我没有设计修改接口只有新增和查询。数据一旦写入只能通过冲正单来更正这是业务驱动的决策不是技术上的偷懒。用表格列几个核心表的字段纲要方便你建表时对照表名关键字段备注t_org_infoorg_code, org_name, org_type, credit_code, agreement_no, status机构档案主表t_org_certcert_type, cert_no, issue_org, expire_date, org_id资质证照子表t_drug_catalogdrug_code, drug_name, spec, manufacturer, reimburs_ratio, is_medical_insurance药品目录t_settlementsettle_no, org_code, total_amount, medical_ins_amount, self_pay_amount, settle_time结算流水t_user / t_role / t_menu用户名、角色标识、菜单权限RBAC五张表2.2 通用字段和状态机设计的规范管理类系统里每张表几乎都逃不掉几个通用字段我项目里的统一约定是id主键用雪花算法生成、create_time、update_time、create_by、update_by、deleted。create_time和update_time用MyBatis-Plus的自动填充处理deleted做逻辑删除标记查询时全局拦截器会自动追加条件不需要每条SQL手写。这里有一个很多人容易忽视的点为什么用逻辑删除而不是物理删除管理系统的数据往往有审计要求尤其是医药这类强监管行业记录不能随便消失。逻辑删除保留数据行只是通过标记位让它在业务查询中不可见后面要追溯随时能把数据捞回来。这个设计在答辩时如果被问到是一道送分题。状态字段我习惯于用“状态机”的思路去设计而不是简单定一个枚举值。比如机构的资质状态有草稿、待提交、待审核、审核通过、审核驳回、已过期这中间就包含了状态的流转方向和触发动作。在Java代码里我没有做特别复杂的有限状态机框架而是用状态字段加一个校验方法来约束流转合法性。核心逻辑就是定义一张状态流转表校验“从A状态只能流转到B/C状态”非法流转直接抛业务异常这样既简单又能保证数据不会出现意外跳变。3. 核心模块实操从登录鉴权到业务闭环3.1 登录认证与权限控制完整落地登录这块我用Sa-Token实现会话管理走Redis保证服务重启后会话还在这个体验对演示很重要。核心配置和逻辑都不复杂先在pom里引入sa-token-spring-boot-starter和sa-token-redis集成包然后在application.yml里配置token超时时间和Redis连接参数。sa-token: token-name: satoken timeout: 86400 active-timeout: -1 is-concurrent: true is-share: false token-style: uuid is-log: false登录接口的逻辑很直接接收账号密码用SaSecureUtil.md5BySalt加密后的密文和数据库比对成功后返回StpUtil.getTokenValue()给前端。关键是后续的拦截器注册Sa-Token提供了一个SaInterceptor注册到WebMvcConfigurer里就可以拦截所有接口配合注解就能实现细粒度鉴权。Configuration public class SaTokenConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new SaInterceptor(handle - StpUtil.checkLogin())) .addPathPatterns(/**) .excludePathPatterns(/user/login, /user/register); } }接口层直接加注解控制权限比如编辑机构信息的接口标注 SaCheckPermission(org:edit)删除药品目录的接口标注 SaCheckPermission(drug:delete)这样登录和越权问题就都兜住了。3.2 定点机构档案管理的业务校验细节机构档案的增删改查表面上是标准CRUD但“增”和“改”背后的校验逻辑才是工作量所在。新增机构时必填字段校验之外我额外做了三个检查统一社会信用代码的格式和唯一性、机构编码不能重复、签约日期范围不能倒挂结束日期必须晚于开始日期。还有一个细节值得展开地址字段。定点医药单位在监管时要核对注册地址和实际经营地址是否一致因为业务上有“注册地与经营地不一致需要备案”的规定。所以我在地址管理上设计了“注册地址”和“经营地址”两个字段而不是一个笼统的地址字段。这种细节在演示时提一嘴答辩老师会认为你确实理解业务而不是只会写CRUD。删除机构我前面提过用逻辑删除但还有一个配套动作删除前检查该机构下有没有未结算完成的记录。如果存在在途业务必须拦截删除操作并提示“该机构存在未完结业务无法删除”。同样是校验逻辑这个是业务完整性约束防止把有历史依赖的数据标记删除后引发查询空指针。修改操作里我用MyBatis-Plus的UpdateWrapper做字段级更新只更新前端传了值的字段避免把null值覆盖进数据库。这个坑很隐蔽有些同学图省事直接传整个实体类结果某个字段在页面里没填数据库原来的值就被覆盖成null了排查起来很费劲。3.3 药品目录维护与Excel批量导入定点机构的药品目录动辄几千条让用户一条条在表单里录入不现实所以批量导入是刚需。我这里用EasyExcel来完成前端上传Excel文件后端解析校验后分批写入数据库。实现逻辑分三层第一层解析文件EasyExcel监听器按行读取读取过程中做基础格式校验药品编码必填、报销比例范围0到1、规格不为空第二层做业务校验比如药品编码在库里不能重复、医保目录内品种必须在医保编码表里存在第三层将校验通过的数据批量入库用MyBatis-Plus的saveBatch方法分1000条一批提交。这里有性能上的考虑如果用单条循环insert5000条数据可能要跑好几十秒而批量插入只要一两秒这个差距演示时很明显。校验失败的记录我不会直接中断而是收集错误信息并生成错误报告返回给前端提示用户第几行哪几个字段有问题。这点体验上的设计很值得做因为用户导入Excel时最烦的就是“全部失败但又不知道哪错了”。3.4 审核流程用Flowable报销比例变更不再手工改库前面提的Flowable要单独开一节讲因为这个决策给项目加分不少。场景是这样定点单位的药品报销比例不是一成不变的政策调整或机构等级变化时需要修改某类药品的报销比例。但这个修改不能由业务员自己直接改库必须走审批流程提交申请→机构负责人确认→稽核部门审批→生效。如果不用工作流引擎这个审批逻辑用状态字段加if/else也能写但流程稍微复杂一点就恢复原状驳回后要重新提交、审批历史要留痕、不同角色看到不同的待办列表。Flowable的作用就是把“流程状态推进”这件事抽象出来由引擎管理任务节点和流转条件业务代码只需要在节点触发时写具体的业务动作。我设计了一个简单的一条链审批流程BPMN流程图用Flowable Modeler直接画节点是发起申请→业务员填报→机构负责人审核→稽核人员审批→更新药品报销比例。关键代码在启动流程和完成任务这两个环节。// 启动流程实例并绑定业务申请ID MapString, Object variables new HashMap(); variables.put(applyUserId, userId); variables.put(orgId, orgId); variables.put(drugType, drugType); variables.put(newRatio, newRatio); runtimeService.startProcessInstanceByKey(ratioChange, businessId, variables);任务完成后监听器里执行真正的业务逻辑更新药品目录的报销比例并记录审批历史。这个实现比手动改状态字段多了一层但在代码组织上却清晰得多——审批流转归Flowable管业务动作归业务Service管互不污染。关于Flowable的版本兼容问题要提醒一下Flowable 6.x和Spring Boot 2.7的兼容性比较稳如果你用的是Spring Boot 3.x就需要上Flowable 7否则启动时会报版本冲突。这是我实际踩过的坑大家选型时先确认版本矩阵不然引入依赖后启动报一堆NoClassDefFoundError查了半天发现是版本不匹配。4. 配置、部署与常见问题避坑实录4.1 application.yml里那些要命的配置项Spring Boot的配置文件看似简单实际项目里没配好就是各种幺蛾子。我整理了一份自认为比较完整的关键配置项包含数据源、Redis、MyBatis-Plus和Jackson时间格式化。spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/medicare?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 servlet: multipart: max-file-size: 20MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml configuration: 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 id-type: assign_id数据源连接池这块我用的是HikariCPSpring Boot 2.x默认之前遇到过一个问题本地跑得好好的一部署到服务器就偶发“Connection is not available, request timed out”。排查下来是连接池最大连接数设太小而接口里有个批量导入药品目录的操作事务内占用了多个连接导致连接池被耗尽。把maximum-pool-size调到20之后问题解决。另一个注意点MySQL的url里务必加上serverTimezone否则高版本驱动会报时区错误这个经典问题每届都有同学中招。Jackson时间格式化也要单独配否则后端返回LocalDateTime类型时前端拿到的是数组格式比如[2025, 6, 1, 10, 30, 0]接口联调时非常痛苦。加一行spring.jackson.date-format配置再把统一响应对象里的时间字段用JsonFormat注解标注就能保证前后端数据格式一致。4.2 前后端联调与打包部署的坑后端接口写完后前端联调阶段最容易出问题的是跨域。如果前端项目用Vite开发服务器默认端口5173后端跑在8080端口不同必然触发跨域。我当时通过WebMvcConfigurer的addCorsMappings方法做了跨域配置允许localhost和127.0.0.1的所有来源开发阶段够用。但要注意一个坑跨域配置拦的是浏览器请求接口本身是通的用Postman测没问题浏览器里却请求失败。很多同学遇到这个问题会怀疑是不是后端代码写错了其实是没配CORS。还有一个小细节如果后端配了拦截器跨域预检请求OPTIONS会被拦截器拦下来导致真实请求发不出去需要对OPTIONS请求直接放行。打包部署这块相对顺利。项目采用Maven构建执行mvn clean package -DskipTests打成可执行jar包然后用java -jar运行。需要注意的一点是不要用JDK 8去编译项目但服务器上装的是JDK 17等较高版本或者反过来版本不一致会报UnsupportedClassVersionError。毕业设计答辩用的电脑环境最好提前确认我见过有人现场突然启动不了就是因为本地JDK版本和打包时不一致。建议直接把Java环境变量指到项目用的JDK版本不要依赖系统默认。部署目录里我习惯把配置文件外置jar包同级别建一个config目录把application.yml放进去Spring Boot启动时会优先读取外部配置这样以后想改数据库密码或者调整端口就不用重新打包了。4.3 常见问题速查表从启动报错到接口异常把这段时间遇到的经典问题整理成一张速查表排查时对着看能省不少时间。问题现象可能原因解决方案启动失败报Failed to configure a DataSourceapplication.yml里数据源配置没生效或参数错误检查配置文件位置、数据库地址端口账号密码启动报Invalid bound statement (not found)Mapper接口和XML文件路径没对上检查Mapper接口包路径、XML的namespace和mapper-locations配置接口返回401未登录或token过期前端请求头带上token检查Sa-Token timeout配置接口返回403已登录但权限不足检查用户角色是否绑定了对应菜单权限接口权限注解是否匹配时区报错或日期错乱MySQL连接串缺serverTimezone在JDBC URL中添加serverTimezoneAsia/Shanghai前端请求跨域失败浏览器跨域拦截后端配置CORS并确保OPTIONS请求不被拦截器拦截分页查询不生效返回全部数据MyBatis-Plus分页插件未注册配置PaginationInnerInterceptor到MybatisPlusInterceptor批量插入很慢单条循环插入改用saveBatch批量写入分批提交Redis连接失败导致登录不行Redis未启动或端口不对确认Redis服务已启动检查配置文件连接参数4.4 测试数据和演示脚本的准备细节答辩演示最尴尬的瞬间就是现场愣在那里翻数据这个我经历过。所以项目里我专门写了一个初始化数据脚本除了必要的管理员账号之外预置了几十家定点机构、几百条药品目录、若干条结算流水记录。药品报销比例我特意设置了一些差异值比如不同机构对同一类药品的报销比例不同这样演示“报销比例变更审批”功能时对比效果非常直观。演示顺序我建议这样走先用管理员登录展示机构档案和权限菜单管理然后创建一家新机构填写资质信息并提交审核切换审核账号完成审核流程展示审核历史记录接着到药品目录页演示Excel批量导入把一份带错误数据的Excel导进去展示错误报告最后展示结算统计页面按机构维度汇总医保结算金额图形化展示一个月的趋势。这套流程走完系统核心模块都覆盖到了时间控制在10分钟左右节奏刚好。还有个小技巧把演示用的Excel文件和初始化脚本放在项目docs目录里编好号写清楚使用说明。个别同学到了答辩前一周连项目都跑不起来一看就是数据脚本没执行或者数据录入太少导致页面空空荡荡提前准备好这些能避免很多尴尬。另外强烈建议写一份项目部署文档内容包括环境要求、数据库初始化步骤、配置文件修改说明、前端构建命令和后端启动命令。这份文档不光是给自己看的答辩时老师问“这项目能直接跑起来吗”你当场按文档从零部署一遍就是最好的证明。根据我的个人经验做这类管理模块最重要的是先想清楚业务链路再动手。很多人一上来就写代码写到后面发现表结构缺字段又要改库改代码来回折腾的工期比前期多花两天做设计还要长。把业务读透把数据模型想清楚开发过程其实就是流水线式填充。做这个项目最大的收获倒不是把Spring Boot用得多溜而是理解了“技术永远服务于业务场景”这句话。同样是增删改查管理普通商品和定点医药单位在细节上差别很大正因为业务有特性项目才能做出差异化。如果你的毕业设计也是类似的管理系统不妨多花点精力去挖掘业务本身的门道哪怕只是把审批流程、报表统计这些点挖深一层也比堆砌一堆用不上的技术要强得多。
近几年带毕业设计陆陆续续接触了挺多“管理模块”类的课题像什么“XX管理系统设计与实现”“XX信息管理模块”几乎是毕业设计里的常青树。就拿这次要拆的这个“springboot定点医药单位管理模块设计与实现”来说标题看着平平无奇实际做起来门道不少——它不是单纯写个增删改查页面就能交差的背后牵扯到机构资质审核、药品目录同步、结算数据留痕还有权限体系这些破事。这篇就把我当时从需求分析到落地的完整思路重新盘一遍项目里能直接抄的配置、代码、表结构设计我都会放出来打算做同类型课题的同学可以当个参考不用从零去踩我踩过的坑。顺便说一句现在毕业设计选Spring Boot确实是个稳妥路子生态成熟、资料多、面试也能聊得上话。但正因为做的人多了想在答辩里拿出点东西就得在业务逻辑和工作流集成上下点功夫。这个项目我在基础CRUD之外加了Flowable流程引擎来处理资质审核这一块是加分项后面细说。1. 项目整体设计与技术选型思路1.1 定点医药单位管理到底管什么先把业务边界搞清楚。定点医药单位通俗讲就是和医保系统签约的药店、医院、诊所这一类机构它们能提供医保结算服务。那围绕这些机构做的管理模块核心职责就是把“机构档案—资质材料—药品服务—结算记录”这条线串起来。可能很多人拿到这个题目第一反应是“不就是管个名单嘛”真上手做需求分析就会发现没这么简单。比如一家定点药店要变更经营范围涉及执业药师资质换证谁发起申请谁审核审核通过之后药品目录需不需要同步更新结算记录出了异常是人工核查还是系统自动拦截所以我在设计时没有把系统狭义地理解成“机构信息表维护”而是拆成了几个子模块机构档案管理、资质证照管理、药品目录管理、诊疗/售药记录管理、结算数据统计外加系统层面的用户权限和操作日志。这样拆分的好处是业务边界清楚每个模块能独立开发答辩时也容易讲清逻辑。1.2 为什么是Spring Boot以及配套技术栈怎么搭课题指定Spring Boot那就围绕Spring Boot搭一套“能落地又不会太重”的技术组合。后端用的Spring Boot 2.7.x持久层用MyBatis-Plus权限认证用Sa-Token流程审核用Flowable前端用的Vue 3加Element Plus。数据库就选MySQL 8.0这套组合在真实中小型项目中也很常见。说下为什么这么选。Spring Boot本身不是新东西但它的自动配置机制确实省掉了大量XML配置尤其是起步依赖和内置Tomcat这两点让项目打包成可执行jar后直接java -jar就能跑这对毕设演示环境非常友好。MyBatis-Plus则是把单表CRUD和分页查询从“写SQL”简化成“调方法”开发效率提升明显而且它提供的逻辑删除和自动填充功能正好契合管理类系统的需求。至于Sa-Token可能有人习惯用Spring Security但毕业设计场景下Sa-Token的学习成本更低API更直观登录、鉴权、踢人下线这些功能几行代码就能接好。我当时对比过这两套方案认为安全框架不是主角够用且能讲清楚原理更重要事实上答辩老师更关注你对权限模型的理解而不是用了哪个框架。Flowable这块后面单独讲它是整个项目的亮点值得多花点篇幅。1.3 权限模型怎么设计RBAC还是更细的粒度管理类系统绕不开权限。这个项目我用的是经典RBAC模型数据库层面落地成五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。用户不直接绑权限而是通过角色间接获得菜单和操作权限。具体到定点医药单位的场景用户类型大体有三类系统管理员、机构业务员、稽核人员。管理员管用户和全局配置业务员只能维护自己所属机构的档案和药品信息稽核人员负责审核操作和数据查看。这个划分让权限控制有了实际业务含义在演示时可以直接展示“同一个按钮不同角色登录后可见性不同”的效果比空泛的“管理员/普通用户”两档要有说服力。菜单权限是粗粒度控制操作权限我用注解在接口层面做细粒度控制。比如药品上下架接口标注 SaCheckPermission(drug:changeStatus)这样即使有人绕过前端直接调接口后端也会拦截。毕业设计里能想到这一层已经是加分项了。2. 数据库设计先把表结构定明白再动手写代码2.1 核心表设计与字段含义数据库设计这块我踩过一次大坑。最早偷懒想用一张“机构信息表”包打天下把所有字段都塞进去结果做到药品目录和结算记录时被迫推倒重来。后来老老实实按业务域拆表核心表有这些。机构信息表是主表存的是定点单位的基础档案。字段包括机构编码、名称、类型药店/医院/诊所、统一社会信用代码、法定代表人、联系人电话、注册地址、经营状态、医保定点协议编号、签约开始和结束日期。其中机构编码我设置为业务主键用规则“地区码类型码序号”生成这样在后续关联药品目录和结算数据时直接用字符串匹配避免频繁Join大表。资质证照表单独设计因为一家机构会有多张证照比如《药品经营许可证》《医疗机构执业许可证》《执业药师注册证》每张证照有各自的编号、发证机关、有效期。如果把这些字段平铺到机构表里一旦出现证照增补就会很尴尬。我当时把证照信息设计成子表机构表只保留一个“资质状态”字段表示是否齐全证照记录通过机构ID关联这样既灵活又不冗余。药品目录表和服务项目表是另外两条线分别对应西药/中成药和诊疗服务项目的维护。每组数据要做定点标识是否是医保目录内品种、报销比例等字段这样结算模块就能直接引用而不是每次结算时临时去算。最后是结算记录表这个表字段最少但最关键结算单号、机构编码、就诊/购药人标识、费用总额、医保报销金额、自付金额、结算时间、操作人。这张表的定位是“不可变流水”所以我没有设计修改接口只有新增和查询。数据一旦写入只能通过冲正单来更正这是业务驱动的决策不是技术上的偷懒。用表格列几个核心表的字段纲要方便你建表时对照表名关键字段备注t_org_infoorg_code, org_name, org_type, credit_code, agreement_no, status机构档案主表t_org_certcert_type, cert_no, issue_org, expire_date, org_id资质证照子表t_drug_catalogdrug_code, drug_name, spec, manufacturer, reimburs_ratio, is_medical_insurance药品目录t_settlementsettle_no, org_code, total_amount, medical_ins_amount, self_pay_amount, settle_time结算流水t_user / t_role / t_menu用户名、角色标识、菜单权限RBAC五张表2.2 通用字段和状态机设计的规范管理类系统里每张表几乎都逃不掉几个通用字段我项目里的统一约定是id主键用雪花算法生成、create_time、update_time、create_by、update_by、deleted。create_time和update_time用MyBatis-Plus的自动填充处理deleted做逻辑删除标记查询时全局拦截器会自动追加条件不需要每条SQL手写。这里有一个很多人容易忽视的点为什么用逻辑删除而不是物理删除管理系统的数据往往有审计要求尤其是医药这类强监管行业记录不能随便消失。逻辑删除保留数据行只是通过标记位让它在业务查询中不可见后面要追溯随时能把数据捞回来。这个设计在答辩时如果被问到是一道送分题。状态字段我习惯于用“状态机”的思路去设计而不是简单定一个枚举值。比如机构的资质状态有草稿、待提交、待审核、审核通过、审核驳回、已过期这中间就包含了状态的流转方向和触发动作。在Java代码里我没有做特别复杂的有限状态机框架而是用状态字段加一个校验方法来约束流转合法性。核心逻辑就是定义一张状态流转表校验“从A状态只能流转到B/C状态”非法流转直接抛业务异常这样既简单又能保证数据不会出现意外跳变。3. 核心模块实操从登录鉴权到业务闭环3.1 登录认证与权限控制完整落地登录这块我用Sa-Token实现会话管理走Redis保证服务重启后会话还在这个体验对演示很重要。核心配置和逻辑都不复杂先在pom里引入sa-token-spring-boot-starter和sa-token-redis集成包然后在application.yml里配置token超时时间和Redis连接参数。sa-token: token-name: satoken timeout: 86400 active-timeout: -1 is-concurrent: true is-share: false token-style: uuid is-log: false登录接口的逻辑很直接接收账号密码用SaSecureUtil.md5BySalt加密后的密文和数据库比对成功后返回StpUtil.getTokenValue()给前端。关键是后续的拦截器注册Sa-Token提供了一个SaInterceptor注册到WebMvcConfigurer里就可以拦截所有接口配合注解就能实现细粒度鉴权。Configuration public class SaTokenConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new SaInterceptor(handle - StpUtil.checkLogin())) .addPathPatterns(/**) .excludePathPatterns(/user/login, /user/register); } }接口层直接加注解控制权限比如编辑机构信息的接口标注 SaCheckPermission(org:edit)删除药品目录的接口标注 SaCheckPermission(drug:delete)这样登录和越权问题就都兜住了。3.2 定点机构档案管理的业务校验细节机构档案的增删改查表面上是标准CRUD但“增”和“改”背后的校验逻辑才是工作量所在。新增机构时必填字段校验之外我额外做了三个检查统一社会信用代码的格式和唯一性、机构编码不能重复、签约日期范围不能倒挂结束日期必须晚于开始日期。还有一个细节值得展开地址字段。定点医药单位在监管时要核对注册地址和实际经营地址是否一致因为业务上有“注册地与经营地不一致需要备案”的规定。所以我在地址管理上设计了“注册地址”和“经营地址”两个字段而不是一个笼统的地址字段。这种细节在演示时提一嘴答辩老师会认为你确实理解业务而不是只会写CRUD。删除机构我前面提过用逻辑删除但还有一个配套动作删除前检查该机构下有没有未结算完成的记录。如果存在在途业务必须拦截删除操作并提示“该机构存在未完结业务无法删除”。同样是校验逻辑这个是业务完整性约束防止把有历史依赖的数据标记删除后引发查询空指针。修改操作里我用MyBatis-Plus的UpdateWrapper做字段级更新只更新前端传了值的字段避免把null值覆盖进数据库。这个坑很隐蔽有些同学图省事直接传整个实体类结果某个字段在页面里没填数据库原来的值就被覆盖成null了排查起来很费劲。3.3 药品目录维护与Excel批量导入定点机构的药品目录动辄几千条让用户一条条在表单里录入不现实所以批量导入是刚需。我这里用EasyExcel来完成前端上传Excel文件后端解析校验后分批写入数据库。实现逻辑分三层第一层解析文件EasyExcel监听器按行读取读取过程中做基础格式校验药品编码必填、报销比例范围0到1、规格不为空第二层做业务校验比如药品编码在库里不能重复、医保目录内品种必须在医保编码表里存在第三层将校验通过的数据批量入库用MyBatis-Plus的saveBatch方法分1000条一批提交。这里有性能上的考虑如果用单条循环insert5000条数据可能要跑好几十秒而批量插入只要一两秒这个差距演示时很明显。校验失败的记录我不会直接中断而是收集错误信息并生成错误报告返回给前端提示用户第几行哪几个字段有问题。这点体验上的设计很值得做因为用户导入Excel时最烦的就是“全部失败但又不知道哪错了”。3.4 审核流程用Flowable报销比例变更不再手工改库前面提的Flowable要单独开一节讲因为这个决策给项目加分不少。场景是这样定点单位的药品报销比例不是一成不变的政策调整或机构等级变化时需要修改某类药品的报销比例。但这个修改不能由业务员自己直接改库必须走审批流程提交申请→机构负责人确认→稽核部门审批→生效。如果不用工作流引擎这个审批逻辑用状态字段加if/else也能写但流程稍微复杂一点就恢复原状驳回后要重新提交、审批历史要留痕、不同角色看到不同的待办列表。Flowable的作用就是把“流程状态推进”这件事抽象出来由引擎管理任务节点和流转条件业务代码只需要在节点触发时写具体的业务动作。我设计了一个简单的一条链审批流程BPMN流程图用Flowable Modeler直接画节点是发起申请→业务员填报→机构负责人审核→稽核人员审批→更新药品报销比例。关键代码在启动流程和完成任务这两个环节。// 启动流程实例并绑定业务申请ID MapString, Object variables new HashMap(); variables.put(applyUserId, userId); variables.put(orgId, orgId); variables.put(drugType, drugType); variables.put(newRatio, newRatio); runtimeService.startProcessInstanceByKey(ratioChange, businessId, variables);任务完成后监听器里执行真正的业务逻辑更新药品目录的报销比例并记录审批历史。这个实现比手动改状态字段多了一层但在代码组织上却清晰得多——审批流转归Flowable管业务动作归业务Service管互不污染。关于Flowable的版本兼容问题要提醒一下Flowable 6.x和Spring Boot 2.7的兼容性比较稳如果你用的是Spring Boot 3.x就需要上Flowable 7否则启动时会报版本冲突。这是我实际踩过的坑大家选型时先确认版本矩阵不然引入依赖后启动报一堆NoClassDefFoundError查了半天发现是版本不匹配。4. 配置、部署与常见问题避坑实录4.1 application.yml里那些要命的配置项Spring Boot的配置文件看似简单实际项目里没配好就是各种幺蛾子。我整理了一份自认为比较完整的关键配置项包含数据源、Redis、MyBatis-Plus和Jackson时间格式化。spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/medicare?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 servlet: multipart: max-file-size: 20MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml configuration: 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 id-type: assign_id数据源连接池这块我用的是HikariCPSpring Boot 2.x默认之前遇到过一个问题本地跑得好好的一部署到服务器就偶发“Connection is not available, request timed out”。排查下来是连接池最大连接数设太小而接口里有个批量导入药品目录的操作事务内占用了多个连接导致连接池被耗尽。把maximum-pool-size调到20之后问题解决。另一个注意点MySQL的url里务必加上serverTimezone否则高版本驱动会报时区错误这个经典问题每届都有同学中招。Jackson时间格式化也要单独配否则后端返回LocalDateTime类型时前端拿到的是数组格式比如[2025, 6, 1, 10, 30, 0]接口联调时非常痛苦。加一行spring.jackson.date-format配置再把统一响应对象里的时间字段用JsonFormat注解标注就能保证前后端数据格式一致。4.2 前后端联调与打包部署的坑后端接口写完后前端联调阶段最容易出问题的是跨域。如果前端项目用Vite开发服务器默认端口5173后端跑在8080端口不同必然触发跨域。我当时通过WebMvcConfigurer的addCorsMappings方法做了跨域配置允许localhost和127.0.0.1的所有来源开发阶段够用。但要注意一个坑跨域配置拦的是浏览器请求接口本身是通的用Postman测没问题浏览器里却请求失败。很多同学遇到这个问题会怀疑是不是后端代码写错了其实是没配CORS。还有一个小细节如果后端配了拦截器跨域预检请求OPTIONS会被拦截器拦下来导致真实请求发不出去需要对OPTIONS请求直接放行。打包部署这块相对顺利。项目采用Maven构建执行mvn clean package -DskipTests打成可执行jar包然后用java -jar运行。需要注意的一点是不要用JDK 8去编译项目但服务器上装的是JDK 17等较高版本或者反过来版本不一致会报UnsupportedClassVersionError。毕业设计答辩用的电脑环境最好提前确认我见过有人现场突然启动不了就是因为本地JDK版本和打包时不一致。建议直接把Java环境变量指到项目用的JDK版本不要依赖系统默认。部署目录里我习惯把配置文件外置jar包同级别建一个config目录把application.yml放进去Spring Boot启动时会优先读取外部配置这样以后想改数据库密码或者调整端口就不用重新打包了。4.3 常见问题速查表从启动报错到接口异常把这段时间遇到的经典问题整理成一张速查表排查时对着看能省不少时间。问题现象可能原因解决方案启动失败报Failed to configure a DataSourceapplication.yml里数据源配置没生效或参数错误检查配置文件位置、数据库地址端口账号密码启动报Invalid bound statement (not found)Mapper接口和XML文件路径没对上检查Mapper接口包路径、XML的namespace和mapper-locations配置接口返回401未登录或token过期前端请求头带上token检查Sa-Token timeout配置接口返回403已登录但权限不足检查用户角色是否绑定了对应菜单权限接口权限注解是否匹配时区报错或日期错乱MySQL连接串缺serverTimezone在JDBC URL中添加serverTimezoneAsia/Shanghai前端请求跨域失败浏览器跨域拦截后端配置CORS并确保OPTIONS请求不被拦截器拦截分页查询不生效返回全部数据MyBatis-Plus分页插件未注册配置PaginationInnerInterceptor到MybatisPlusInterceptor批量插入很慢单条循环插入改用saveBatch批量写入分批提交Redis连接失败导致登录不行Redis未启动或端口不对确认Redis服务已启动检查配置文件连接参数4.4 测试数据和演示脚本的准备细节答辩演示最尴尬的瞬间就是现场愣在那里翻数据这个我经历过。所以项目里我专门写了一个初始化数据脚本除了必要的管理员账号之外预置了几十家定点机构、几百条药品目录、若干条结算流水记录。药品报销比例我特意设置了一些差异值比如不同机构对同一类药品的报销比例不同这样演示“报销比例变更审批”功能时对比效果非常直观。演示顺序我建议这样走先用管理员登录展示机构档案和权限菜单管理然后创建一家新机构填写资质信息并提交审核切换审核账号完成审核流程展示审核历史记录接着到药品目录页演示Excel批量导入把一份带错误数据的Excel导进去展示错误报告最后展示结算统计页面按机构维度汇总医保结算金额图形化展示一个月的趋势。这套流程走完系统核心模块都覆盖到了时间控制在10分钟左右节奏刚好。还有个小技巧把演示用的Excel文件和初始化脚本放在项目docs目录里编好号写清楚使用说明。个别同学到了答辩前一周连项目都跑不起来一看就是数据脚本没执行或者数据录入太少导致页面空空荡荡提前准备好这些能避免很多尴尬。另外强烈建议写一份项目部署文档内容包括环境要求、数据库初始化步骤、配置文件修改说明、前端构建命令和后端启动命令。这份文档不光是给自己看的答辩时老师问“这项目能直接跑起来吗”你当场按文档从零部署一遍就是最好的证明。根据我的个人经验做这类管理模块最重要的是先想清楚业务链路再动手。很多人一上来就写代码写到后面发现表结构缺字段又要改库改代码来回折腾的工期比前期多花两天做设计还要长。把业务读透把数据模型想清楚开发过程其实就是流水线式填充。做这个项目最大的收获倒不是把Spring Boot用得多溜而是理解了“技术永远服务于业务场景”这句话。同样是增删改查管理普通商品和定点医药单位在细节上差别很大正因为业务有特性项目才能做出差异化。如果你的毕业设计也是类似的管理系统不妨多花点精力去挖掘业务本身的门道哪怕只是把审批流程、报表统计这些点挖深一层也比堆砌一堆用不上的技术要强得多。
