企业官网建设流程全解析

每年毕设季，医疗报销系统这个题目的出现频率都相当高。原因不难理解——它是典型的业务管理系统，覆盖了用户认证、流程审批、数据权限、金额计算、报表统计、文件上传这些JavaWeb必考知识点，难度又刚好卡在“工作量够、难度可控”的位置，所以老师们也爱往这个方向出题。

但做过的人心里都清楚，“看起来简单”和“真正能跑通”是两回事。报销系统最核心的难点不在CRUD，而在于报销状态的流转控制、金额的精确认算、审核并发的安全性，以及一整套可追溯的操作记录。这篇文章就从零拆解一个基于SpringBoot的医疗报销系统，包括需求分析、表结构设计、核心接口实现、前后端打包部署，以及我在实际开发中踩过的坑。不管你是刚拿到题目的应届生，还是想快速搭一套内部报销工具的开发者，花十分钟读完，对这套系统的整体脉络基本就能心中有数。

1. 项目定位：医疗报销系统到底在解决什么问题

1.1 一句话说清楚业务本质

医疗报销系统，表面看是“用户上传发票、管理员审核、然后打款”，但往深了挖，它背后其实是三件事：单据处理、资金核算、流程管控。

单据处理是说，用户每次看病会产生挂号单、药品清单、检查报告、费用发票，这些零散的纸质和电子凭证必须被录入系统，形成一笔完整的报销记录。资金核算则是说，系统需要根据报销政策计算可报金额。比如城镇职工医保、城乡居民医保的起付线和报销比例不同，一个健壮的系统要把这些规则配置化，而不是写死在代码里。流程管控更关键，报销单从“草稿”到“待审核”到“已通过”再到“已打款”，每一个动作都要有人负责、有迹可循。

所以做这个项目，第一步不是建表，而是把业务边界划定清楚。哪些用户能做什么操作、报销单要经过哪些状态、每一笔金额如何计算，必须提前想明白，否则后期改起来非常痛苦。这也就是为什么这类系统虽然功能看起来简单，但真正做得规范的版本并不多。

1.2 角色划分与权限边界

绝大多数毕设版本至少包含两种角色：普通用户和管理员。如果想让系统更完整，可以再加一个“财务/出纳”角色，专门负责打款回执登记，这样权限层级更清晰，工作量也更好看。

普通用户的核心操作是：维护个人信息、提交报销申请、上传费用凭证、查看审核进度、查看历史报销记录和统计。管理员的职责是：审核用户提交的报销单、驳回不合规的申请、维护报销政策与药品目录、查看全平台的报销统计报表。

角色的权限控制，在SpringBoot项目里最常用的方案就是Spring Security加JWT，或者简单一点用拦截器加自定义注解。我在实际做的时候，倾向于用Spring Security做认证，用@PreAuthorize("hasRole('ADMIN')")这种注解做方法级权限控制。这样Controller层的职责很清楚，权限逻辑不散落到业务代码里，后面要在某个接口上收紧权限，加一行注解就行。

1.3 核心功能清单与主流程梳理

把这个系统的核心功能列一下，方便后面做表设计和接口设计时对照：

• 用户注册与登录，密码加密存储
• 报销单管理，支持新建、编辑、提交、撤回、删除草稿
• 费用明细管理，一条报销单可以挂多条明细，比如挂号费、诊疗费、药品费、检查费
• 凭证附件上传，用于存发票照片、检查报告PDF
• 审核管理，管理员执行通过或驳回操作，填写审核意见
• 报销进度查询，用户随时看到当前单子走到哪一步
• 统计报表，按时间、按费用类型统计报销金额
• 系统管理，用户管理、政策参数配置、数据字典维护

主流程也很清楚：用户创建报销单，填写费用明细，上传附件，提交，管理员审核，通过则进入待打款流程，财务登记回执，用户看到最终状态。这个流程想清楚之后，数据库的表结构其实已经呼之欲出了。建议大家动手写代码之前，先把这条主流程画在纸上，每个状态节点、每个操作对应的角色标清楚，后面开发效率会高很多。

2. 技术选型拆解：SpringBoot + MyBatis + Vue这套组合为什么经典

2.1 SpringBoot自动装配到底帮我们省了什么

这个项目标题里把SpringBoot放在最前面，不是没道理的。SpringBoot这几年几乎成了JavaWeb项目的默认起点，核心原因就一个字：省。

在Spring时代，配一个SpringMVC项目要写一堆XML，还要手动配置DispatcherServlet、包扫描、视图解析器、数据源。SpringBoot把这些东西全部通过自动装配搞定了。你加一个spring-boot-starter-web依赖，内嵌Tomcat自动启动，Controller直接能用；你加一个mybatis-spring-boot-starter，SqlSessionFactory自动建好，Mapper直接注入。这就是热词里“springboot自动装配原理”反复被讨论的原因。

理解自动装配对看懂这个项目很有帮助。SpringBoot的starter本质上是一个Maven描述符，里面打包了相关依赖和自动配置类。以mybatis-spring-boot-starter为例，它内部的AutoConfiguration会读取你在application.yml里的spring.datasource配置，自动创建DataSource、SqlSessionFactory，并通过MapperScannerRegistrar把你的Mapper接口扫描注册成Bean。这也是为什么你写@MapperScan("com.example.reimburse.mapper")时，实际上是在补充自动装配没有覆盖到的扫描范围。

2.2 持久层选型：为什么是MyBatis而不是JPA

做这个系统，我强烈建议用MyBatis。原因有三：第一，国内项目、教材、技术社区里MyBatis的普及度是压倒性的，遇到问题随便搜就有答案；第二，医疗报销这种业务，SQL里常要写复杂的条件查询和多表关联，比如按时间范围统计报销金额、查某个分类的费用总和，这种SQL用MyBatis的XML写起来非常顺手，用JPA就得写JPQL或者更别扭的Specification；第三，MyBatis的动态SQL在组合查询场景下极其好用。

有些同学纠结“MyBatis要写XML，太麻烦”。麻烦是麻烦，但可控性极高。尤其当你后续要加一个多条件组合查询时，MyBatis的if、where、foreach标签能让你少写很多字符串拼接代码。我经常跟人说一个类比：JPA像自动挡，开起来省心但紧急情况下你控制不了档位；MyBatis像手动挡，操作多一些，但动力输出和工况判断都在你手里。做这类业务系统，手动挡更稳妥。

2.3 前端方案：“Vue + 前后端分离”与“Vue打包进SpringBoot”

现在的毕设主力前端就是Vue。Vue 2虽然还很稳定，但新项目我更推荐Vue 3加Element Plus加Vite，组件库顺手，开发速度快，文档也全。前端页面主要就是登录页、报销单填写页、报销记录列表、审核管理页、统计图表页这几大块，Element Plus的表格、表单、上传组件基本都能直接满足需求。

这里有一个热词需要展开讲讲：“vue打包放进springboot中”。很多同学不想单独部署前端，或者不想让老师看到两个服务联调半天，就选择把Vue执行npm run build之后生成的dist目录，直接放到SpringBoot的src/main/resources/static下。这样最终交付的时候，一个jar包跑起来，前端文件跟着一起被服务，部署成本很低。

我的建议是：开发阶段用Vite devServer加后端proxy转发，解决跨域；部署阶段执行npm run build，然后把dist目录内容复制到static目录，再执行mvn clean package打成jar。但要注意几个点：第一，Vue路由如果是history模式，刷新会出现404，需要在SpringBoot里配置一个转发规则，把非/api开头的未知路径转发到index.html；第二，如果SpringBoot设置了server.servlet.context-path，前端静态资源的路径也要对应调整，否则js/css加载不出来。这些细节我放在后面常见问题章节具体讲。

2.4 附件存储：MinIO集成要点

热词里有“minio加入到springboot”，这个点和医疗报销系统的关系非常密切。系统里用户要上传发票图片、检查报告PDF，这些文件如果直接存数据库的BLOB字段，数据库会迅速膨胀，备份和查询速度都会受影响；如果存本地磁盘，部署到服务器后又不方便统一管理，换个机器文件就丢了。

MinIO是一个开源的对象存储服务，兼容S3协议，搭建也简单，下载一个服务端二进制启动就行，默认端口9000。在SpringBoot里集成的步骤也是标准化的：

第一步，引入io.minio的minio依赖； 第二步，在application.yml里配置endpoint、accessKey、secretKey、bucketName； 第三步，写一个MinioService，封装upload、download、delete三个方法； 第四步，业务代码里调用上传接口，把返回的文件URL存到数据库的attachment表。

注意两个坑：文件名冲突要处理，我习惯用UUID加原始文件名后缀重新生成存储对象名；另外大文件上传建议检查Nginx的client_max_body_size配置，否则会报413错误。

3. 核心功能模块是怎么落地的

3.1 登录认证与JWT签名认证

用户表加角色表加用户角色关联表，这是权限系统的三件套。密码不能用明文，也尽量不要用MD5，我在项目里用的是BCrypt加密，Spring Security自带的BCryptPasswordEncoder直接就能用。登录成功之后签发JWT，JWT的claims里放userId和role，下次请求通过拦截器解析Token，把用户信息放进ThreadLocal上下文里，方便后面Service层随时获取当前登录人。

热词里提到的“springboot 签名认证”，其实就是JWT签名这套。我的建议是：

• token过期时间设成2小时，刷新Token的机制可以后续再扩展；
• 校验签名用HS256，秘钥放配置文件，别硬编码在代码里；
• 拦截器要排除login、register、静态资源等路径；
• 权限控制推荐方法级别的@PreAuthorize，比在拦截器里写角色判断更清晰，可读性也更好。

登录认证这一块如果弄不明白，整个系统开发会有一种“到哪都卡住”的感觉。所以拿到项目第一步，可以先做一个最简单的注册登录接口，把SpringBoot加MyBatis加MySQL这条链路跑通，再做别的功能。热词里的“第1关：项目整合 - springboot + mybatis”和“第2关：使用springboot + mybatis实现一个最简单的注册功能”，说的就是这个思路，先把骨架立起来。

3.2 报销单状态机：系统最核心的设计

这是整个系统的灵魂，值得多花点篇幅展开。

报销单的一条完整生命线是这样的：草稿（DRAFT）到待审核（PENDING）到通过（APPROVED）再到已打款（PAID），从待审核可以驳回到草稿（REJECTED）。如果用户提交之后想改，可以在待审核之前撤回；被驳回之后，只能修改草稿重新提交。

状态机设计最忌讳的就是到处写if/else判断。我推荐在Service层建一个状态流转校验的方法，整体思路是让枚举自己管理“哪些状态可以流转到哪些状态”：

public enum ReimburseStatus { DRAFT, PENDING, APPROVED, REJECTED, PAID; public boolean canTransferTo(ReimburseStatus target) { switch (this) { case DRAFT: return target == PENDING; case PENDING: return target == APPROVED || target == REJECTED; case APPROVED: return target == PAID; case REJECTED: return target == PENDING; default: return false; } } }

调用时统一走校验：

private void checkStateChange(ReimburseOrder order, ReimburseStatus target) { if (!order.getStatus().canTransferTo(target)) { throw new BusinessException("不允许从" + order.getStatus() + "流转到" + target); } }

这样的好处是，所有状态流转的规则都集中在一个地方，后续增加状态只改枚举即可。比如以后要加一个“已驳回待补充材料”的状态，不会影响其他代码。这个设计是项目答辩时很值得拿出来讲的一个点。

3.3 费用明细与金额计算精度

报销单和费用明细是1对N的关系。费用明细表至少要包含：医院名称、就诊时间、费用类型、总金额、自费金额、报销金额。

这里有一个“魔鬼细节”：金额计算精度。如果在Java代码里直接用double或者float做金额计算，0.1 + 0.2这种问题会直接让你的报销金额差出分厘。我见过不止一个初学同学的代码里，报销比例乘以总金额之后出现了19.999999这种结果。后端实体类里要用BigDecimal，数据库里要用DECIMAL(10,2)，前端传过来的字符串在接收时直接映射为BigDecimal。虽然实际金额差异可能也就是一分钱，但作为报销系统，钱的问题一点含糊不得。

报销金额怎么算？最灵活的方式是配置化规则。系统中维护一张报销政策配置表，字段包括费用类型、报销比例、是否启用。计算时根据费用类型查配置，套用公式：

BigDecimal actualAmount = total.subtract(selfPay); BigDecimal reimbursable = actualAmount.multiply(rate).setScale(2, RoundingMode.HALF_UP);

如果规则更复杂，比如按金额区间走不同比例，可以在配置表里加minAmount和maxAmount字段，查询时先找匹配区间再计算。这样就把业务规则从代码里剥离出来了，运维人员改政策不需要重新发版。

3.4 审核流程、乐观锁与操作留痕

审核是后台管理员的核心动作。审核时管理员可以看到报销单的所有明细和上传的附件，然后选择“通过”或“驳回”，填写审核意见。审核通过后，报销单状态从PENDING变为APPROVED，进入待打款列表；如果驳回，状态变成REJECTED，用户在前端看到驳回原因，修改后可以重新提交。

这里有一个容易被忽视但非常重要的设计：操作留痕。报销系统牵扯资金，必须保证每一次状态变更都有迹可溯。我建了一张operation_log表，记录操作人、操作类型、操作时间、审核意见、变更前后的状态。管理员审核通过后，日志里要清清楚楚写着“admin于2025-xx-xx将单号RE2025001从PENDING变更为APPROVED”。答辩时提一句“可通过日志表全链路追溯报销审核过程”，是很明显的加分项，因为这说明你不是只做了一个简单CRUD，而是考虑了系统的合规性。

3.5 统计报表怎么写得又简单又好看

系统里要给用户端和管理员端都做些统计。

用户端比较简单：查看自己历史报销总额、报销次数、各类型费用占比。实现方式就是按userId分组查询，前端用ECharts画饼图或柱状图。

管理员端相对复杂一些：按月度统计报销总金额、新增报销单数、通过率、未处理单数。这种统计SQL要单独写到Mapper的XML里，不要在业务代码里做运算。一个比较典型的SQL是这样：

SELECT DATE_FORMAT(order_date, '%Y-%m') AS month, COUNT(*) AS total, SUM(CASE WHEN status = 'APPROVED' THEN 1 ELSE 0 END) AS approved_count, SUM(CASE WHEN status = 'PENDING' THEN 1 ELSE 0 END) AS pending_count FROM reimburse_order WHERE deleted = 0 GROUP BY DATE_FORMAT(order_date, '%Y-%m') ORDER BY month DESC;

统计查询尽量单独写Mapper方法，不要为了偷懒在一个方法里塞各种if判断，那会让SQL变得臃肿难维护。前端图表推荐使用ECharts，体积可控，文档细致，给用户端画一个年度报销趋势折线图，给管理员端画一个报销类型占比饼图，视觉效果一下子就上来了。

4. 关键表结构与核心代码实现

4.1 数据库表结构设计

数据库是这个项目的地基，表设计做好，后面写代码顺风顺水。核心表一共六张：用户表、报销单主表、费用明细表、附件表、操作日志表、报销政策配置表。

用户表sys_user：

报销单主表reimburse_order：

费用明细表reimburse_item：

附件表attachment、操作日志表operation_log、政策配置表policy_config的字段按照前面章节的设计写就行，这里不再重复。

有两点提醒：第一，表名尽量不要用order，因为order是MySQL的保留字，非常容易踩坑，加个前缀叫reimburse_order最省心；第二，所有表都加逻辑删除标记deleted，查询时统一加WHERE deleted = 0，这样以后用户删了报销单，后台还能查到记录。这也能在答辩时体现工程规范性。

4.2 报销单提交的Service实现

提交报销单这个接口，业务逻辑上是：校验用户是否登录，校验报销单状态是否为草稿，校验费用明细非空，计算报销金额，更新主表状态，最后落一条操作日志。代码写成一个事务方法：

@Transactional(rollbackFor = Exception.class) public Long submitOrder(Long orderId, Long userId) { // 查询报销单 ReimburseOrder order = orderMapper.selectById(orderId); if (order == null) { throw new BusinessException("报销单不存在"); } // 权限校验 if (!order.getUserId().equals(userId)) { throw new BusinessException("无权操作该报销单"); } // 状态校验 if (order.getStatus() != ReimburseStatus.DRAFT) { throw new BusinessException("只有草稿状态的报销单才能提交"); } // 明细非空校验 List<ReimburseItem> items = itemMapper.selectByOrderId(orderId); if (items.isEmpty()) { throw new BusinessException("报销单明细不能为空"); } // 计算可报销金额 BigDecimal reimbursable = calculateReimbursable(items); order.setReimbursableAmount(reimbursable); order.setStatus(ReimburseStatus.PENDING); order.setApplyTime(new Date()); order.setVersion(order.getVersion() + 1); orderMapper.updateById(order); // 写入操作日志 logService.log(orderId, userId, "SUBMIT", ReimburseStatus.DRAFT, ReimburseStatus.PENDING, ""); return order.getId(); }

事务对这个系统极其重要。报销单创建、明细插入、附件记录、日志写入必须保证“要么全部成功，要么全部回滚”，否则就会出现明细有数据、主表没有，或者日志缺失的脏数据。@Transactional要放在public方法上并确保外部调用，不能自己调自己，否则Spring的代理机制不生效。这就绕到了热词“springboot默认使用cglib代理”的知识点：SpringBoot 2.x之后默认使用CGLIB代理，它通过生成子类来增强Bean，所以目标方法不能是private，否则无法被拦截。

4.3 审核操作的并发控制代码

管理员审核也是一个事务方法：先查出报销单，校验状态是PENDING，然后执行审核动作。这里存在一个并发隐患：如果两个管理员同时打开同一个报销单，一个点击“通过”，一个点击“驳回”，没有锁保护的情况下，后执行的一方可能基于过期的状态做判断，导致两条审核操作都“成功”，状态却错乱。

我用乐观锁解决这个问题。审核更新时，在SQL里带上version条件：

int rows = orderMapper.auditUpdate( orderId, ReimburseStatus.PENDING, targetStatus, order.getVersion(), auditUserId, auditOpinion, new Date()); if (rows == 0) { throw new BusinessException("操作失败，该报销单状态已发生变化，请刷新后重试"); }

对应的Mapper XML大概是：

<update id="auditUpdate"> UPDATE reimburse_order SET status = #{targetStatus}, audit_time = #{auditTime}, audit_user_id = #{auditUserId}, audit_opinion = #{auditOpinion}, version = version + 1 WHERE id = #{orderId} AND status = #{expectedStatus} AND version = #{version} </update>

如果没有更新到任何行，说明状态或版本已经被别人改过了，直接拒绝并提示用户刷新页面。这就是典型的CAS比较并交换思路。虽然一个小型的报销系统几乎不会有两个人同时审核同一个单子的情况，但把这种保护机制写进去，无论从工程质量还是答辩角度看，都是值钱的细节。

5. 打包部署、踩坑记录与答辩加分点

5.1 前后端联调与Maven构建部署

开发阶段，前端Vite启动在5173端口，SpringBoot跑在8080，通过Vite的proxy配置把/api开头的请求转发到8080，这样解决跨域问题，同时前端代码里请求路径直接写/api/...，不用写死主机名，后续改部署环境也方便。

部署阶段，执行npm run build，把生成的dist目录中的内容复制到SpringBoot的src/main/resources/static下，然后执行标准的三步构建：

mvn clean mvn package java -jar target/reimburse-system.jar --spring.profiles.active=prod

热词里“javamaven项目构建方法springboot”说的就是这个标准流程。还有“idea 2026怎么配置springboot服务编辑配置数据比如启动端口”，经常有人问。答案其实有两层：一是在application.yml里配置server.port，这是推荐做法，因为不同环境可以用不同配置文件管理；二是在IDEA的Run/Debug Configuration里，给VM options加-Dserver.port=8081，或者Environment variables里加SERVER_PORT=8081，适合临时调试。生产环境优先用配置文件方案，这是规范。

5.2 常见坑位速查表

把这个项目开发运维中容易踩的坑整理成一张速查表：

遇到这些问题时不要慌，先看日志，再对照配置，大多数都是配置层面的小问题。日志配置建议在application.yml里把logging.level.com.example.reimburse设为debug，大问题小问题一眼就能看到Mapper对应的SQL执行情况。

5.3 答辩汇报时值得重点讲的几个加分点

这个项目做完，答辩的时候有些点值得系统地讲。第一，状态机设计。用枚举管理状态流转，集中校验，杜绝了if/else散落各处，这是软件工程里“状态机模式”的实践。第二，乐观锁控制审核并发，体现工程意识，你可以现场演示两个管理员同时点审核，后一个会收到友好的错误提示。第三，操作日志全链路留痕，呼应“资金安全可追溯”这个核心诉求。第四，金额基于BigDecimal加配置化规则计算，体现对金融计算精度的理解。第五，MinIO对象存储管理附件，说明你了解对象存储的基本思路，而不是把文件存数据库。

这些点不是花架子，每一个都切中医疗报销系统“流程严谨、数据准确、可追溯”的行业属性。把这几条讲清楚，比你对着代码念10分钟CRUD强得多。

最后再分享一点个人体会。这个项目我在帮人改代码和指导学生的过程中看过不下二十个版本，做得好的各有各的好，做得差的都逃不过几个通病：状态乱跳、金额用double、日志缺失、权限只靠前端隐藏。如果看这篇文章的你正在做这个题，我建议把上面几个点逐一核对一遍，改掉这些毛病，你的系统无论从运行稳定性还是答辩表现，都会远超平均水准。

我个人最大的感受是：这类业务系统项目，技术框架反而是次要的，真正见功力的是对业务状态的梳理和对核心数据规则的敬畏。状态机想清楚、金额计算用对类型、每一步操作可追溯，这个项目的灵魂就立住了。比起纠结某个组件的新版本特性，先把这些基本功做扎实，才是一个开发者真正的底气。