城乡居民医保管理系统源码解析：SpringBoot+Vue+MySQL实战

作为一个常年泡在项目堆里的技术博主，我最近在好几个技术群里看到不少人贴出同一个项目的名字：城乡居民基本医疗信息管理系统源码，SpringBoot后端加Vue前端配MySQL，还特别标注了“可直接运行”。很多同学私信问我这东西到底怎么样、值不值得下载来研究，甚至有人上来就问“能不能帮我跑通”。说真的，我看了那么多号称毕业设计、课程设计的开源项目，这一个方向偏冷门，但业务逻辑一点都不简单。借着这个机会，我把这套城乡居民基本医疗信息管理系统完整拆一遍，讲清楚代码背后到底藏着什么设计思路，怎么在本地把它跑起来，以及真正容易踩坑的地方在哪儿。

这个系统本质上是一个典型的行政区划级基层政务业务系统，面向的是城乡居民基本医疗的参保登记、缴费核定、报销结算、待遇查询等场景。跟常见的电商后台、博客系统不一样，它的数据模型里充满了居民身份属性、医保批次参数、报销比例规则这类业务字段，对表结构设计、角色权限划分、前后端数据流转的要求都比较高。也正因为它业务不复杂、又没有特别畸形的技术坑，非常适合用来理解SpringBoot加Vue前后端分离项目的完整闭环：从页面录入、接口请求、服务端校验、数据库读写一直到统计汇总。适合的人群也很明确：准备做毕设的在校生、刚学完框架想找个中小型实战项目练手的新人，以及想快速搭一个行政管理域业务原型给领导或客户演示的开发者。

这个项目跑起来只需要一台普通开发电脑，不需要高配置。但跑通只是第一步，把里面的业务逻辑吃透才是真收获。

1. 一个看着不起眼的项目，为什么值得好好拆一遍

很多人第一眼看到“城乡居民基本医疗信息管理系统”这种命名，第一反应是“这是不是那种很老套的管理系统，是不是就用表格堆一堆增删改查”。我只能说，这个刻板印象害人不浅。表面上它确实是一个后台管理项目，但只要你打开数据库表结构，看到参保人、家庭成员、缴费批次、报销申请、补偿比例、医疗机构这几个核心实体之间的关系，你就会明白这类系统的信息量远大于普通的商品管理。

1.1 城乡居民基本医疗信息管理系统到底在管什么

城乡居民基本医疗，主要面向的是没有参加职工基本医疗的人群，比如农村居民、城乡失业人员、老人和未成年人。这类人群的特点是数量大、分布散、动态变化频繁，而且参保状态跟户籍属性、人员类别、缴费档次是强绑定的。具体到信息管理系统里面，你需要处理的数据大体就是几类：

• 参保登记数据：个人基本信息、身份证号、户籍地址、参保状态、人员类别（普通居民、低保对象、特困人员等）、缴费档次。
• 缴费核定数据：年度缴费批次、每人缴费金额、财政补助金额、缴费时间、是否到账。
• 报销结算数据：门诊记录、住院记录、发票金额、目录内费用、报销比例、实际报销金额、个人自付金额。
• 基础配置数据：各级医疗机构的报销比例参数、药品目录/诊疗项目目录、年度封顶线、起付线。

对比一下常见的电商项目，商品、订单、支付这种模型在业务上相对通用，但医保缴费和报销结算的数据规则往往带有很强的地区性参数，而且审批、校验、记录留痕的环节更多。比如报销申请就要经过提交材料、审核录入、核定金额、财务发放等多个状态节点。因此这个系统虽然叫“信息管理”，本质上是一个带流程性质的业务系统，做起来比普通CRUD要复杂一层。

1.2 这套技术组合的背后逻辑

为什么用SpringBoot加Vue加MySQL而不是其他组合？这个问题不只是选型偏好，背后有一套很实际的理由。

先从后端说。SpringBoot能够成为这类中小型管理系统最常被选择的基础框架，核心在于几个能力：Spring IoC容器管理对象，Starter机制把常用功能做成开箱即用的依赖，内嵌Tomcat让部署变成一条java -jar命令。相较早期用SSH或者JSP做的老系统，SpringBoot项目里不需要你手工写一堆XML配置，也不需要你把页面模板和后端逻辑搅在一起。再配合MyBatis或JPA操作MySQL，整个后端可以拆成清晰的层级：控制层接收请求、服务层处理业务、数据访问层操作数据库。

再从Vue的角度看。Vue在整个前端技术圈里一直以上手平滑、中文资料多著称，它的双向绑定和组件化非常适合这类页面多、表单多的管理系统。管理端要做几十个页面，如果全部采用传统模板渲染，光JS文件的维护就够喝一壶。Vue把页面拆成组件，左边菜单栏、顶部导航、权限路由、表格分页、表单弹窗这些都是可以复用的组件，开发效率和可读性都能往上走一大截。

最后是MySQL。有人说MySQL是不是太基础了，要不要换PostgreSQL。我的看法是，这类系统的数据量通常控制在几十万条以内，MySQL无论是在安装维护、备份迁移、还是新手上手成本上，都会比PostgreSQL更顺一些。它自带的数据类型、索引机制以及事务保证，已经足以应对参保记录、缴费记录、报销记录的存储和查询场景。在真实的政务系统选型里，你确实能看到Oracle或者国产数据库，但那是出于采购规范和历史原因，对一套开源学习项目来说，MySQL是性价比最高的存在。

用一个不那么精确但很好懂的类比：SpringBoot是店里的后厨，负责接单、洗菜、炒菜；Vue是前厅的点餐屏幕和餐桌，顾客直接看到菜单、下单、等菜；MySQL是后厨的储物仓库，所有食材和半成品都按规则码放在不同的货架上。前后端分离，就是前厅只管展示和交互，后厨只管把菜品做好，两个环节之间通过一道道菜单传递信息。

2. 技术选型与系统架构逐个盘

搞清楚系统要解决什么问题后，再看源码的时候就要把注意力放在结构上。很多同学拿到项目压缩包直接就是一顿点击启动，遇到报错就发在群里问。我非常不建议这种跑法。你要先在一个整体的高度上知道每个目录、每个配置文件是干什么用的，这样即便报错了也能自己判断问题出在哪个环节。

2.1 后端SpringBoot的分层与核心模块

这套系统的后端部分，典型的目录结构大概长这样：

src/main/java ├── com.xxx.medical │ ├── controller // 控制层，接收HTTP请求 │ ├── service // 业务层，处理核心逻辑 │ ├── mapper // 数据访问层，对接数据库 │ ├── entity // 实体类，对应数据表 │ ├── config // 拦截器、跨域配置、数据源配置 │ ├── common // 统一返回结构、异常处理、工具类 │ └── MedicalApplication.java // 启动类

controller这一层做得非常薄，只负责接到前端传过来的参数、调用service、把结果包装成统一结构返回。真正的业务判断都在service层，比如报销金额怎么算、参保状态能不能变更、重复缴费怎么拦截，这些逻辑都不应该塞在controller里面。数据层则通过MyBatis的接口跟实体对应，如果你拿到的是普通Maven项目，你会看到resources目录下还有一堆mapper XML文件，里面写的是SQL，这是MyBatis风格最常见的组织方式。

再来看后端提供哪些模块。核心模块大致可以分为：用户登录与权限、参保人信息管理、家庭关系管理、缴费批次管理、缴费记录管理、报销申请与审核、参保统计报表。其中每个模块都可以独立出控制器和服务，这样代码可读性高，后期如果要做微服务拆分，也能照着模块边界去切。

关于统一返回结构我多说一句。很多自己写的demo项目返回给前端的东西非常随意，有时直接返回一个实体对象，有时返回一个Map，有时又直接返回字符串，这样的话联调阶段会被反复扯皮。这类系统一般会封装一个Result对象，里面放着code、message、data三个字段。前端拿到响应之后先判断code是否等于200，再做后续操作。有一个统一的返回约定，前后端协作的沟通成本会低很多。

2.2 前端Vue的双角色界面

前端部分基于Vue开发的话，常见的项目结构是使用Vue CLI或Vite创建的单页应用。管理系统的页面通常分成两类使用场景：一类是系统管理员/经办人员使用的管理后台，另一类是参保居民自己使用的查询与申请界面。这两类角色的菜单、页面、功能都有很大的区别。

管理后台端一般包括：登录页、首页工作台、参保人管理、保障家庭管理、缴费管理、报销审核管理、系统用户管理和系统配置。页面以表格、搜索表单、状态筛选为主，并配合新增、编辑、删除、导出的操作弹窗。这个角色的核心诉求是“录入、批量处理、审核、留痕”。

居民用户端相对简单，一般包括：个人参保信息查看、家庭成员绑定、缴费记录查看、报销进度查询、报销申请发起。这个角色的核心诉求是“能不能少跑腿、能不能查清楚”。这样一套系统在设计的时候会把前端路由做权限控制，管理员登录后能看到管理菜单，普通居民登录后只能看到个人相关页面。

有一个很容易被忽略的细节：前端页面的信息展示和后端接口字段一定要对齐。如果后端返回的日期字段是时间戳，前端就要做格式化；如果后端返回的金额单位是“分”，前端展示就要除以100。这类项目跑通之后，你最常遇到的就是“接口没报错、但页面显示不对”的情况，基本都是字段名不一致或者单位没转换。

2.3 数据库表结构设计的关键

数据库设计是这类系统能不能做好的一半。打开SQL脚本或者数据库后，你需要重点关注几张核心表和表之间的关系。

第一张是系统用户表，用来存登录账号和密码，注意不要把参保人和登录用户混成一张表。系统用户表管的是“能进系统的人”，而参保人信息表存的是“医疗保障的对象”，一个人可能是管理员，同时也可能是参保家属，但这是两个维度，必须拆开。

第二张是参保人表，核心字段包括姓名、身份证号、性别、出生日期、户籍地址、参保状态、人员类别、联系方式等。身份证号是一个高权重字段，由于居民基本医疗按人管理，同一人重复参保或者跨地区重复参保都是要避免的事情，所以这张表上通常会对身份证号建唯一索引。

第三张是缴费记录表，关联字段包括参保人ID、缴费年度、缴费档次、个人缴费金额、财政补助金额、缴费状态、缴费时间。养老保险和医疗保险的缴费体系在细节上各有不同，但在管理系统层面都要能实现“按年度缴费、按人核销”的逻辑。

第四张是报销申请表，这个表是整个系统业务链条最长的表。字段包括参保人ID、医院名称、就诊开始时间和结束时间、总费用、目录内费用、起付线、报销比例、报销金额、个人自付金额、审核状态、审核人等。报销涉及的字段非常多，经常有人把本地自付和目录内费用搞混，这个在数据库层面就要保证计算逻辑正确。

另外还有字典表，比如医院等级字典、费用类别字典、人员类别字典。字典表的存在意义在于，避免在前端页面上写死各种下拉选项。你以后要改报销比例分类或人员类别名称，不需要动代码，改数据库里一条记录就行了。

2.4 前后端联调的核心约定

前后端分离项目的开发模式里，接口约定决定了整个团队的工作效率。这套源码里，后端接口一般会统一以/api开头，比如/api/insured/list、/api/payment/save、/api/reimburse/audit。前端在发起请求的时候会统一指定baseURL，开发环境通过代理转发，生产环境通过Nginx反向代理。

这里特别想提醒一句，很多新手在开发环境里直接把前端的请求地址写成http://localhost:8080，这样确实能通，但如果后端接口部署的地址以后变了，前端所有请求地址都要改，非常麻烦。正确做法是前端用相对路径/api开头，在vue.config.js或者Vite配置里加一个开发代理，把/api转发到后端的localhost:8080。这样你以后把前端打包扔到任何一台服务器上，只需要配置Nginx转发规则，不用改前端代码。

登录态的保持也是前后端协作的核心之一。常见方案是基于SpringBoot的拦截器加Token校验，前端登录成功后把Token存到本地或者请求头里。需要注意Token过期后前端要拦截到401状态码，自动跳回登录页，不要让用户一直停留在看起来还在线的界面上。

3. 本地跑通这套源码的完整步骤

很多文章到了架构讲解就停了，但我觉得真正费时间的是“怎么把它跑起来”。这里我按照我自己的实践，把从零到一跑通这套城乡居民基本医疗信息管理系统的过程拆成具体步骤，每个步骤里都有版本要求和注意事项。

3.1 环境准备：版本对齐是第一个坑

先确认你本机已经安装好了下面这些环境，版本不一定完全一致，但至少不能差得太离谱。

这些版本号里面最容易出问题的就是JDK和Node.js。有的电脑上装着JDK 17，但后端项目pom文件里编译版本还写的1.8，一启动就会报错说“无效的目标发行版”。还有的电脑上Node版本到了20，执行npm install的时候会报一些内部依赖错误，这种情况要么换Node 16左右的LTS版本，要么把npm源切到国内镜像再试。

3.2 后端启动：从建库到登录

第一步是建库。打开MySQL命令行或者图形化客户端，执行项目里的SQL脚本。这个SQL脚本可能是单个.sql文件，也可能是一堆SQL文件按模块拆开。执行之前先检查脚本开头有没有建库语句，比如CREATE DATABASE medical;，有的话你就只需要在客户端里选中作为默认数据库执行；没有的话你先手工建一个空库，然后切换过来执行。

第二步是改配置。找到后端项目里的application.yml或application.properties文件，把数据库地址、账号、密码改成你自己的。这里多说一句，如果你MySQL的密码含有特殊字符，比如@或者#，在YAML文件里不加引号会导致解析失败。建议密码里尽量不要用特殊字符，或者在YAML里给密码加单引号。还要注意URL里的时区参数，常见写法是：

spring: datasource: url: jdbc:mysql://localhost:3306/medical?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456

有人不写serverTimezone也能跑，但有可能会在时间字段读写的时候产生8小时的偏差。加上Asia/Shanghai就是告诉驱动用东八区时间，算是最省心的做法。

第三步是启动后端。用IDEA打开项目之后，等Maven把依赖拉完，直接运行启动类。如果你的项目不是IDEA打开而是命令行运行，可以在项目根目录执行：

mvn spring-boot:run

启动成功之后，控制台会出现Spring Boot的启动横幅和Tomcat端口号，默认是8080。为了确认接口真的可用，可以在浏览器里访问http://localhost:8080/api/user/info这类接口，如果返回的是JSON而不是404，说明后端业务接口已经在线了。

3.3 前端启动：代理与端口

前端部分用IDEA或VS Code打开以后，先看目录里有没有package.json。在项目根目录执行安装依赖：

npm install

如果网络慢，建议临时切换npm源，在国内环境下速度提升会非常明显：

npm config set registry https://registry.npmmirror.com

依赖安装完以后，执行：

npm run serve

如果是Vite项目，执行：

npm run dev

启动成功以后，控制台会显示一个本地访问地址，比如http://localhost:8081。注意前端端口和后端端口不要冲突，如果前端用了8080，后端也用了8080，那就是端口起了冲突，启动其中一个就会报Address already in use。前后端配置里通常会有一个用8080，另一个用8081或者8082，不要强行都改成一个地址。

打开前端地址，能看到登录页就说明前端起来了。输入系统初始化账号密码，如果后端也正常，就能跳转到首页。如果登录按钮一直转圈或者提示网络错误，先按F12打开浏览器的开发者工具看Network面板，检查请求是不是真的发出去、状态码是不是200、响应体里有没有报错。这一步是整个联调过程中排查问题最高频的手段。

3.4 目录结构速览与启动顺序总结

拿到源码后不要上来就跑，先把目录结构和依赖配置看一遍。我这里给出一个常见的目录速览：

medical-manage ├── backend // SpringBoot后端 │ ├── src │ ├── pom.xml │ └── sql │ └── medical.sql └── frontend // Vue前端 ├── src ├── package.json └── vue.config.js

启动顺序一定是先MySQL，再后端，最后前端。MySQL没起来就启动后端，后端会报数据库连接失败；后端没起来就启动前端，前端页面能打开，但所有接口都会失败。整个过程做一遍之后，你就能在本地跑通一套完整体验的前后端分离项目。

提示：首次启动不要纠结“为什么后端启动这么慢”，SpringBoot要扫描的组件比较多，加上Maven还会做依赖加载，这很正常。真正需要警觉的是日志里出现红字异常之后再判断问题类型。

4. 核心业务实现里的关键细节

项目能跑通之后，真正有价值的工作才开始。这里我挑几个我认为在这个项目中值得深挖的细节，也是面试或者答辩时容易被问到的点。

4.1 登录与权限：密码加密和拦截要一起看

登录模块是每个系统都有的，但很多项目在密码安全上做得不合格。这套系统的后端通常不会用明文存储密码，而是用MD5加盐或者BCrypt格式存储。最简单的观察方式是打开数据库用户表，看一下密码字段的值是不是一串固定长度且不规则的字符串。如果是，说明做了加密；如果直接是123456这种，说明没做加密，这是安全上的一个明显缺陷。

权限控制上，后端一般用拦截器统一处理。SpringBoot中的拦截器要注册到WebMvcConfigurer里去，常见做法是写一个LoginInterceptor，在里面判断请求头里的Token是否存在以及是否有效。对于免登录接口，比如前端获取验证码、用户登录，要在配置文件里排除掉对应的路径。这里有一个很容易踩的坑：拦截器路径写得太宽，把静态资源也拦截了，导致前端页面能打开但图片加载不出来；写得太窄，又会导致有些需要鉴权的接口被任意访问。

如果你要改进这套项目，把Token从固定字符串换成JWT是一个很好的升级点。JWT的好处是服务端不需要保存会话状态，Token本身就带着用户的ID和过期时间，但缺点是如果用户修改密码，之前签发的Token无法立刻失效。对这个项目来说，也可以选择把Token存到Redis里，方便主动踢人或统一失效，但需要额外引入Redis依赖，从零开始改造会有一点工作量。

4.2 报销结算的计算逻辑：比例参数不能写死在代码里

城乡居民基本医疗的报销计算，是整套系统里最有业务含金量的一段。

报销金额并不是简单的“总费用乘以统一比例”。真实的核算过程要考虑起付线、封顶线、目录内费用、报销比例等多个因素。用公式表示大概是：

报销额 = (目录内费用 - 起付线) × 报销比例 个人自付 = 总费用 - 报销额

而且报销比例不是固定的，跟医院等级有关，一级医院可能报销85%，三级医院可能报销70%；跟人员类别也有关，低保对象、特困人员往往有更高比例。设计的合理做法是，把这些比例配置放到系统参数表或者字典表里，后端在计算时从配置中去取，而不是在代码里硬编码。

很多刚入门的开发者拿到这类项目时会觉得“报销金额直接调一个接口算出来就行”。实际上，如果在代码里直接写if (hospitalLevel == 3) return 0.7，那以后医院等级调整比例、或者新增一档医院级别，都要改代码重新部署，这在真实项目里是不可接受的。你要做的应该是给报销比例增加一个可配置的表，前端管理员在后台能修改参数，后端计算时动态读取。这样既锻炼了你对数据建模的理解，也让项目在答辩时更有亮点。

4.3 数据权限与身份绑定

这个系统还有一个容易被忽略的问题：数据权限。

系统中的用户分为管理员和居民。管理员可以查看所有参保人的信息，但居民登录后应该只能看到自己及家庭成员的记录。如果后端接口只做了“登录验证”而没做“数据归属校验”，那一个居民用户就能遍历出所有人的身份证号和报销记录，这是严重的数据泄露风险。

正确做法是，查询参保人详情的接口除了要求登录，还要比对当前登录用户的ID是否等于被查询的参保人ID，或者是该参保人家庭关系中的成员。具体实现方式是在查询SQL里带上一个当前用户ID的过滤条件。这个细节在很多SSM项目中都没做，但它在真实的系统中是一个硬性需求。如果你是拿这个项目去面试或做毕业设计，把这个点做好，绝对是一个明显的加分项。

4.4 前端表格、校验与状态转换

再从前端角度说两个操作细节。

表格页面是一眼就能看到的普通管理页面，但真正写得好的表格远不止调一个后端列表接口、然后用循环渲染出来。你需要处理分页参数、加载状态、空数据展示、操作按钮的权限开关、搜索表单的重置。这套系统里，我建议你先重点看缴费记录列表页和报销审核列表页，这两个页面涉及最多的状态字段，比如待缴费、已缴费、待审核、已审核、已驳回，不同状态下按钮和标签颜色都不一样。

表单校验也是一个细节密集的地方。身份证号校验要兼容15位和18位，还要能识别最后一位X；手机号校验要符合国内号码规则；日期选择器要限制结束日期不能早于开始日期。这个系统里，身份证号是一个核心主键性质的字段，前端校验只是第一步，后端也必须做同样的校验，不能只信任前端传过来的数据。

5. 启动运行中的常见问题排查实录

我在这类项目上帮不少人排查过问题，下面这些场景是出现频率最高的，我把现象、原因和解决办法整理成一份速查表。

再补充一个我在实际过程中遇到过的“经典陷阱”：执行SQL脚本时，如果MySQL版本是8.0而你的脚本里用了老版本的字段类型或索引写法，执行到一半会报错。解决办法是先确认脚本针对的MySQL版本，如果脚本里出现了ENGINE=InnoDB DEFAULT CHARSET=utf8，在8.0里也能执行，但如果有PASSWORD()函数这类老语法，就需要手工调整。还有一次，我看到一个同学的数据库里所有表都建好了，但页面查询时报“表不存在”，原因是SQL脚本执行时连接到了默认的test库，建表都建到了另一个库里，后端配置的connection库和建表的库不是同一个。这种问题排查起来特别容易让人崩溃，所以建库之前一定要看清当前选中的数据库。

前端还有一个非常高发的点：页面一直白屏，打开控制台显示Cannot read properties of undefined。这种报错大部分是某个接口返回的数据结构和前端预期不匹配，比如后端返回了一条空数组，但前端还是直接取data.list再取第一项data.list[0].name。解决方式是前端做防御性判断，或者梳理接口文档，统一字段。

6. 从“能跑”到“会用”：后续扩展建议和个人经验

项目跑通、代码也看明白了，并不是终点。我建议你在这个基础上做一点自己的东西，哪怕只是很小的改动，也能让这个项目变成真正属于你的作品。

6.1 基于这套源码最值得加的三个功能

第一个值得加的是数据可视化看板。现在的系统里肯定有参保人数、缴费金额、报销金额这些数据，在首页用ECharts做几个统计图，比如按年月展示缴费趋势、按乡镇展示参保人数、按医院等级展示报销金额占比，项目的展示效果立刻上一个档次。数据可视化在前后端分离项目中不需要额外引入太重的内容，只需要后端写一个统计接口返回聚合数据，前端用图表组件渲染。

第二个值得加的是批量导入导出。医保系统中，从Excel导入参保人信息是非常刚需的操作。你可以用后端解析Excel，逐行校验数据格式，再批量插入数据库。同时把查询结果导出为Excel文件，这个功能在答辩现场演示的时候效果很好。用EasyExcel或者POI都可以实现，建议优先用EasyExcel，内存占用低且API更简单。

第三个值得加的是消息通知。缴费提醒、报销进度通知，这类场景可以通过系统站内信或者短信通知实现。作为学习项目，可以先做一个站内信模块的新增和已读功能，把通知表接到业务状态变更点上，比如报销审核通过之后自动写入一条站内信。这样你就把“流程”和“通知”结合起来了，而不只是做一个简单的数据库写入。

6.2 换业务域复用的思路

这套系统的开发模式也可以快速迁移到其他业务场景。把“参保人”换成“业主”，把“缴费记录”换成“物业费流水”，把“报销申请”换成“维修工单”，再把字段名称改一下，你就能很快搭出来一套物业管理系统。同理，换上教师、学生和课程数据，也能变成校园管理平台。原因在于这种系统的骨架是通用的：一套登录权限体系，加一套主数据和从属记录的管理模型，再加上一条状态流程。真正需要重写的是业务规则计算，比如报销比例、起付线、封顶线这种东西，换成其他行业就完全不通用了。

所以我在学习任何一套系统源码的时候，都会刻意把“通用骨架”和“行业规则”分开看。骨架帮你提升开发效率，而行业规则才是你和别人拉开差距的地方。

6.3 一点个人体会

做这类前后端分离的管理系统，我个人最大的体会是：跑通一个项目不等于学会一个项目。很多同学第一件事就是一键启动，看到界面出来就觉得完事了。但如果你真的把数据表一张接一张看过去，把报销计算的步骤用代码走读一遍，再跟着前端的路由和API请求把一条业务流串起来，这个项目对你的价值会翻好几倍。

我在实际做过的类似系统里踩过不少坑，其中印象最深的一次是上线时没留意前端代理配置，导致打包后的静态文件发到服务器上之后，所有请求都还在往localhost发。这个问题看起来低级，但在联调和部署阶段非常常见。后来我的习惯是：前端代码里永远不写死完整后端地址，本地用代理，生产用Nginx转发。这个习惯在这套源码上同样适用——你以后把它部署到任何环境，只要专配好反向代理，就不用翻着前端代码改请求地址。

这套项目本身不算大，但它把SpringBoot、Vue和MySQL的组合用法完整串联起来了。对想要打牢基础的人来说，静下心来把里面每一张表、每一个接口、每一步业务流转都吃透，比急着去学微服务和分布式架构要实在得多。最后再分享一个小技巧：拿到这类带源码的项目，先在SQL脚本里看表结构，再顺着“登录-参保登记-缴费-报销”这条主线去读代码，你的理解速度要比从代码逐行看快得多。