做毕设最痛苦的事，不是代码写不出来，而是项目名字起好了，脑子还是一片空白。“SpringBoot+Vue web城乡居民基本医疗信息管理系统”，光看这个标题，你会猜想它是个多庞大的政务级系统。真把源码打开一看，落到技术上，就是一个标准到不能再标准的 Java 全栈信息管理系统：后端 SpringBoot 负责接口和业务规则，前端 Vue 负责页面交互，MySQL 存储数据。功能上绕不开增删改查、分页搜索、登录权限、统计报表这老几样。但它的价值恰恰就在这里——结构清晰、技术主流、流程完整，既能当毕设拿得出手，也能当课设交得上去，还能作为一个入门前后端分离开发的最佳练手项目。
这篇文章会把“城乡居民基本医疗信息管理系统”从立项、建表、写接口、调前端、打包部署到答辩展示，完整拆开揉碎给你看。我会重点讲清楚哪些设计是同类系统通用的套路，哪些坑是新手必踩的雷，还有答辩时怎么把话说得漂亮。无论你是打算拿这份源码直接二开，还是自己从零手写一遍，读完都能少走不少弯路。
1. 项目全貌拆解：这其实是个“标准政务业务系统”
1.1 功能地图与业务闭环
先说结论：城乡居民基本医疗信息管理系统，本质上是社保类业务系统的“缩略版”，真实世界里对应的东西就是城镇居民医保、新农合这些业务的后台管理系统。既然是“医保管理系统”，它的核心业务就是围绕“人”和“钱”两条线展开。
人这条线，管的是居民的基础档案——姓名、身份证号、户籍地址、参保状态。钱这条线，管的是缴费记录和报销记录——居民交了多少钱，生病住院花了多少钱，医保报了多少，个人自费多少。再往上一层，就是给管理员看的数据汇总，比如参保人数统计、各年度缴费金额汇总、报销支出统计。
所以功能模块通常就长这样：
- 系统登录：管理员账号登录、退出，可能区分超级管理员和普通操作员
- 居民信息管理：居民档案的增删改查、身份证号唯一性校验、条件筛选和分页
- 参保缴费管理：按年度登记参保记录，处理续保、停保，记录缴费档次和金额
- 报销审核管理：录入就诊报销单、核算报销金额、审核状态流转
- 慢病管理（可选）：登记特殊慢性病患者的备案信息
- 统计看板：参保人数、缴费总额、报销总额等可视化报表
- 系统管理：用户管理、角色分配、操作日志、数据字典
这个功能地图一列出来你会发现，它和电商系统、OA系统的后端逻辑几乎没有本质区别。凡是别人说“我会 CRUD”，指的就是这套东西。但医疗保险业务的特点在于，它有一个非常严格的“业务状态流”——居民从参保、缴费、就诊到报销，每一步都有明确的状态字段约束，这比单纯堆 CRUD 更接近真实企业项目。
1.2 为什么 SpringBoot + Vue 成了毕设第一梯队
十几年前做毕设，主流组合是 JSP + Servlet + MySQL，写出来的东西是前后端不分的“单体 JSP 页面”，看着就老。后来流行 SSM（Spring + SpringMVC + MyBatis）做后端，搭配 EasyUI 或 Layui 这类 jQuery 前端库，也算常见。而现在打开任何招聘软件，Java 后端岗位的技能要求里几乎都写着 SpringBoot；前端岗位里 Vue 或 React 至少会一个。所以 SpringBoot + Vue 等于踩在了当前毕业设计的“最大公约数”上。
对它个人学习者来说，最大的好处是前后端分离之后，职责非常清楚。后端写接口、处理业务逻辑，前端只管渲染页面、调接口、展示数据，通过 JSON 交互。调试的时候一旦数据不对，用浏览器 F12 看 Network 面板，接口是 200 还是 500，返回体里报什么错，一眼就能定位。这是 JSP 时代敢都不敢想的体验。
还有一个隐藏价值是技术栈的“可解释性”。答辩时你可以说，后端用 SpringBoot 的约定优于配置，简化了项目搭建；前端用 Vue 的组件化开发，实现了页面复用；数据库用 MySQL，通过外键和索引保证数据一致性。这三句话一出来，评委就知道你是真的做过，而不是照着网上的源码跑通就算完。
1.3 三类人应该怎么用这份源码
- 毕业设计（毕设）。你的任务是“在别人代码基础上做出自己的东西”。我建议先完整跑通，然后至少替换一个业务模块，比如给居民信息模块加上 Excel 批量导入导出，或者把统计报表从表格换成 ECharts 图表，然后写进论文的创新点里。
- 课程设计（课设）。课设的时间一般只有两三周，核心是“能跑、能演示、有文档”。这种情况下不需要做太多二次开发，把项目的业务逻辑、表结构、接口文档梳理清楚，再准备一份流畅的演示流程就够了。
- 纯粹学习（学习）。如果你是正处于 Java 入门到进阶阶段的新手，我的建议恰恰相反——不要直接改代码。先把表结构搞懂，再跟着代码走一遍从 Controller 到 Service 再到 Mapper 的数据流，最后关闭源码自己从空项目重新写一遍，哪怕只写一个模块。这个过程的价值是任何教学视频都替代不了的。
2. 系统设计与数据库建模：决定项目上限的关键环节
2.1 后端分层架构与项目结构
大多数这类系统源码都是标准的“四层结构”：Controller 层接收前端请求，Service 层处理业务逻辑，Mapper（DAO）层负责数据库操作，Entity 实体类对应数据表。额外的会有 Config 配置类、Common 公共类、DTO/VO 数据传输对象，还有一个放工具类（JWT、密码加密、日期处理）的 Utils 包。
项目目录结构一般这样命名：
src ├── main │ ├── java │ │ └── com.xxx.medical │ │ ├── controller # 接口入口 │ │ ├── service # 业务逻辑层 │ │ ├── mapper # MyBatis 数据访问层 │ │ ├── entity # 实体类 │ │ ├── dto / vo # 请求/响应对象 │ │ ├── config # 配置（跨域、拦截器、Swagger） │ │ ├── common # 统一返回体、异常处理 │ │ └── utils # 工具类 │ └── resources │ ├── mapper # MyBatis XML 文件 │ └── application.yml # 核心配置这里有一个非常关键的经验：永远不要把 Entity 直接返回给前端。原因很简单，前端不需要看到数据库字段的全部，比如密码的哈希值、逻辑删除标记 deleted，还有一些你不想暴露的内部字段。正确做法是建一个 VO（View Object），只封装前端需要的字段。很多新手写项目不区分 Entity 和 VO，图省事直接返回实体类，这在课堂作业里能跑，但放到实际项目里会被老同事骂死。
因此你会看到优秀的源码里总会有一个统一返回体，常见命名是 Result 或 R，结构类似：
public class Result<T> { private Integer code; // 200成功，500失败 private String message; // 提示信息 private T data; // 业务数据 }所有接口返回的都包一层 Result。这样做最大的好处是，前端 axios 拦截器可以统一处理错误码，而不是每个页面单独判断返回结构。这也是为什么你能从“它有没有统一返回体”判断一份源码到底写得好不好。
2.2 核心表结构设计思路
数据库设计是这类系统的灵魂。我见过的“烂代码项目”，居民信息、缴费记录、报销记录全部塞在一张表里，字段多得吓人，查询效率低下、逻辑混乱。而好的设计一定是“主表 + 子表”的多表结构。
核心表通常包括这五张：
- sys_user（系统用户表）
- resident（居民信息表）
- insurance_record（参保缴费记录表）
- medical_record（就诊报销记录表）
- chronic_disease（慢病登记表，可选）
下面是两张表的字段设计示例，你可以对照自己手里的源码看是不是这个套路。
居民信息表 resident：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| id_card | varchar(18) | 身份证号，必须唯一 |
| name | varchar(50) | 姓名 |
| gender | tinyint | 性别（1男 2女） |
| birth_date | date | 出生日期 |
| household_type | varchar(20) | 户籍类型（城镇/农村） |
| address | varchar(255) | 家庭地址 |
| phone | varchar(11) | 联系电话 |
| insurance_status | tinyint | 参保状态（0未参保 1正常 2停保） |
| create_time | datetime | 创建时间 |
| update_time | datetime | 更新时间 |
| deleted | tinyint | 逻辑删除标记 |
attention：逻辑删除字段 deleted 是这套设计的重头戏。真实业务里的居民档案是不能物理删除的，因为参保和报销记录都关联着居民，一旦删掉，历史数据就断了。所以设计上统一用 0 表示有效、1 表示已删除，查询时强制带条件WHERE deleted = 0。这也是答辩时一个很好的加分点。
参保缴费记录表 insurance_record：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| resident_id | bigint | 关联居民id（外键） |
| year | varchar(10) | 参保年度，如2025 |
| pay_level | varchar(20) | 缴费档次 |
| pay_amount | decimal(10,2) | 缴费金额 |
| pay_status | tinyint | 缴费状态（0未缴 1已缴） |
| operator_id | bigint | 操作人id |
| create_time | datetime | 创建时间 |
为什么缴费记录是单独一张表，而不是在居民表里加一个“缴费状态”字段？因为医保是按年度缴费的，一个居民会有 2024、2025、2026 多条缴费记录。如果把它塞进居民表，表结构会爆炸，也没法按年度统计缴费总额。这就是数据库第二范式在真实业务里的体现。
医疗报销表 medical_record 核心字段通常有：resident_id、hospital_name、visit_date、total_amount（总费用）、medical_expense（医保报销）、self_expense（自费）、reimburse_status（报销状态），其中 reimburse_status 一般用整型枚举，例如 0 待审核、1 已通过、2 已驳回。
2.3 权限与安全设计：医保系统最不能丢的一环
医疗数据属于个人敏感信息，哪怕只是个毕设，权限和安全的“骨架”也得摆出来。基础做法是三张表：用户表 sys_user、角色表 sys_role、中间表 sys_user_role。如果不做角色多对多，最少也要在用户表里加一个 role 字段区分管理员和普通操作员。登录校验方面，主流方案是 JWT，用户登录成功后签发一个 token，前端把 token 存在 localStorage，每次请求在请求头带上Authorization: Bearer <token>，后端通过拦截器验证 JWT 是否有效，然后从 token 里解析出用户信息。
@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains("/login")) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录或登录已过期"); } // 解析 token，校验签名和过期时间 Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); request.setAttribute("userId", claims.get("userId")); return true; } }再说密码存储。我见过特别多毕设项目的用户表密码是明文，比如 123456 直接存。真做了医保系统你会发现，明文存储一旦数据库泄露，所有账号都是裸奔状态。正确的做法是用 BCrypt 或 MD5 加盐。虽然 BCrypt 对新手来说要引入额外依赖，但在答辩时你可以明确地说“为了防止拖库导致密码泄露，我对敏感字段做了加密处理”，这在医疗类项目里是非常对口的加分点。
还有一个细节就是 XSS 防护。最近有个热搜词是“SpringBoot 项目全局过滤器处理上传 PDF 文件时 XSS 攻击”，说明很多人在文件上传和富文本过滤这块吃过亏。如果你的系统里有居民备注、审核意见这类可输入文本的字段，一定要在前端做输入校验或后端统一加过滤器，防止有人提交<script>标签。哪怕只是简单的字符串替换，也说明你有安全意识。搜索引擎热词里反复出现这类问题，恰恰说明它确实是这个领域的高频坑。
3. 核心功能模块的落地实现：从接口到页面的完整链路
3.1 登录认证与用户权限的落地
登录模块是所有管理系统的入口，也是代码量不大但细节极多的模块。流程上，前端引入 axios 后，在请求拦截器里统一注入 token：
axios.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config })后端方面，登录接口接收用户名密码，校验密码，成功就生成 JWT 返回。这里有一个特别推荐的细节——登录时顺便查一下用户的角色，把角色信息放进 token 或返回体里，前端拿到之后控制菜单显示。这样就能实现“管理员能看到系统管理菜单，普通操作员只能看到业务菜单”的差异化。
在这个环节上，很多初学者会纠结 Vue 路由的权限控制。实际上 Vue Router 有 beforeEach 路由守卫，可以每次跳转前判断有没有 token，没有就重定向到登录页。热搜词里“vue路由参数”和“vue安装及环境配置”说明大家经常卡在这一块，我建议你先不要过度设计动态路由，把“登录拦截、无权限跳转、退出清理 localStorage”这三件事做好就够了。
3.2 居民档案管理的分页与条件检索
居民信息管理是系统里使用频率最高的功能，核心需求就是“分页 + 多条件查询”。常见查询条件组合有：姓名模糊匹配、身份证号精确匹配、参保状态下拉筛选。
后端代码最常用的组合是 MyBatis 的 PageHelper 分页插件。用法三步走：
// 1. 引入依赖 mybatis-pagehelper // 2. 在 Service 中设置分页参数 PageHelper.startPage(pageNum, pageSize); // 3. 紧跟其后的第一条查询就是分页查询 List<ResidentVo> list = residentMapper.selectByCondition(query); PageInfo<ResidentVo> pageInfo = new PageInfo<>(list);这个插件在网上讨论得非常热烈，原因是它太方便了，但也容易误用。最重要的经验是PageHelper.startPage后面必须紧跟一条 Mapper 查询，中间不能夹带其它 SQL 操作，否则分页会失效或者作用到错误的查询上。我在项目里看见过有人在一个方法里先 query 了一次菜单列表再 query 居民列表，结果第一段查询也被拦截分页，Bug 就悄悄出现了。
分页接口的返回结构一般包含 total（总条数）、list（当前页数据）、pageNum（页码）、pageSize（每页条数）。前端用 Element UI 的 el-table 配合 el-pagination 组件，页码变化时重新请求接口。这个模式在前后端分离项目里是“肌肉记忆级”的操作，你一定要亲手敲一遍。
顺便说一个条件查询容易出的错：身份证号、手机号这类字段查询接口，不要把等值查询写成了 like 查询。既是精确匹配又是模糊匹配，用户把身份证号输入完整了反而查不到——因为数据库字段是 varchar(18)，你用了like '%部分号码%'看似没问题，但如果业务要求严格，甚至会有两个不同身份证号因包含关系被同时查出来。我建议身份证号一律用等值，姓名才用模糊匹配。
3.3 参保缴费和报销审核：业务规则的“状态机”设计
如果说增删改查是管理系统的标配，那参保登记和报销审核就是医保系统的“差异点”。这两块能看出一个开发者有没有真正想过业务闭环。
参保登记的流程大概是这样的：选择居民 -> 选择参保年度 -> 选择缴费档次 -> 生成缴费记录。这里就有业务规则：同一个居民同一年度不能重复参保。比如居民“张三”2025 年已经参保了，操作员再点一次参保，系统必须给出“该居民本年度已参保”的提示。这个校验在 Service 层做，不要依赖数据库唯一索引兜底。
再比如报销审核。一张报销单从提交到结束，要经历：待审核 -> 审核通过 / 审核驳回。已通过的记录在统计报表中计入医保支出；被驳回的记录有驳回原因字段。这就是一个典型的状态机流程。我强烈建议你在代码中写一个枚举类来定义这些状态：
public enum ReimburseStatus { PENDING(0, "待审核"), APPROVED(1, "审核通过"), REJECTED(2, "已驳回"); private final int code; private final String desc; }用枚举而不是魔法数字，好处是代码里不会出现if (status == 1)这样看不懂的硬编码。过两周你自己回来看代码，看到ReimburseStatus.APPROVED.getCode()，立刻知道这个 1 是什么意思。这就是可读性，也是答辩时能讲出深度的点。热搜词里“java基础”和“java面试题”老是出现，其实很多面试题考的就是你有没有这种代码洁癖。
再补充一个业务细节：报销金额核算。居民医保的报销规则一般不是“全额按比例报”，而是有起付线和封顶线的，比如“超过 500 元以上的部分按 60% 报销，最高报销 2000 元”。这样一个简单的报销核算逻辑，用代码实现起来就是一个纯函数：
public BigDecimal calculateReimbursement(BigDecimal totalAmount) { // 起付线500元 BigDecimal threshold = new BigDecimal("500"); BigDecimal ratio = new BigDecimal("0.6"); BigDecimal maxAmount = new BigDecimal("2000"); if (totalAmount.compareTo(threshold) <= 0) { return BigDecimal.ZERO; } BigDecimal eligible = totalAmount.subtract(threshold).multiply(ratio); if (eligible.compareTo(maxAmount) > 0) { return maxAmount; } return eligible.setScale(2, RoundingMode.HALF_UP); }这个逻辑放到 Service 层，比让前端传一个计算好的报销金额回来要可靠得多。同时也说明你不只是“会 CRUD”，而是真的理解了业务规则由后端收敛这条企业开发原则。
3.4 统计报表：让数据说话的最后一步
一个管理系统如果没有统计模块，总觉得差了最后一口气。医保系统的统计报表一般包括以下几类：
- 按年度统计参保缴费总人数、缴费总金额
- 按月份统计报销笔数、报销支出总额
- 按户籍类型统计参保覆盖率（城镇 vs 农村）
- 慢病病种分布统计
后端实现思路非常简单，就是“SQL 聚合”。比如统计历年缴费总额：
SELECT year, SUM(pay_amount) AS total_amount, COUNT(*) AS person_count FROM insurance_record WHERE pay_status = 1 GROUP BY year ORDER BY year DESC;做统计报表最需要注意的问题是金额精度。MySQL 的 decimal 类型传到 Java 后会变成 BigDecimal，前端拿到后如果是 JSON 序列化，BigDecimal 会被转成数字，一般没问题。但如果你用了 double 来接收金额字段，就可能出现 0.1 + 0.2 != 0.3 这种精度丢失问题。做医疗类管理系统，凡是涉及钱的字段，一律用 BigDecimal，别碰 double。
前端可视化方面，最简单的是用 ECharts 的柱状图、饼图展示。Vue 项目里安装 echarts 后用this.$echarts.init()渲染，通过后端接口拿到聚合数组，再 setOption 赋值。这一步视觉效果拔群，答辩演示时一打开看板，评委的注意力立刻就被抓住了。
4. 前后端联调、部署与环境配置
4.1 本地联调必做的两个配置
前后端分离项目第一次联调时，新手最常见的困扰就是跨域报错。前端跑在http://localhost:5173（Vite 默认端口），后端跑在http://localhost:8080，两个端口不同，浏览器默认会拦截跨域请求。你要做的不是在后端配置全局允许跨域，也不是在前端改什么神秘参数，而是用代理解决。
如果是 Vue CLI 创建的项目，在vue.config.js里配置：
module.exports = { devServer: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }意思就是前端发出的/api/login请求会被代理到http://localhost:8080/api/login，浏览器看到的还是同源请求。这是企业项目里非常标准的联调方式，比后端加@CrossOrigin或者全局 CorsFilter 要优雅得多。当然，后端也常配一个跨域过滤器兜底，两个都配也不冲突。
后端方面，强烈建议集成 Swagger（springfox 或 springdoc）。访问http://localhost:8080/swagger-ui.html，所有接口一目了然，还能直接在页面上测试。答辩时打开 Swagger 页面给评委看接口文档，又是一个稳赚好感分的小细节。
4.2 打包部署：从开发环境到“能演示”的最后一公里
很多同学项目在本地跑得飞起，一到要交给老师验收或者部署到云服务器就露怯。其实部署流程是固定的。
后端先打包成可执行 Jar。在 IDEA 里执行 Maven 的package命令，或者命令行mvn clean package -DskipTests，然后在target目录下生成.jar文件，通过java -jar 项目名.jar启动。如果你想让项目存活在服务器上而不是关掉终端就死，就用 nohup：
nohup java -jar medical-system.jar --server.port=8080 > app.log 2>&1 &前端就简单了，执行npm run build，生成一个dist目录。然后有两种部署方式。一种是直接把 dist 目录扔到 Nginx 的 html 目录下，在nginx.conf里配置将/api路径反向代理到后端 8080 端口。另一种是把前端打包好的静态资源复制到后端项目的src/main/resources/static目录下，这样后端 Jar 会同时提供接口和页面，访问起来相对省事，但不够“前后端分离”，所以我不太推荐第二种。
Nginx 配置中最容易踩的坑是 Vue Router 的 history 模式刷新 404。因为前端路由是前端自己控制的，后端服务器不知道/resident这个地址，刷新时会直接报 404。解决方案是在 Nginx 里加一行try_files $uri $uri/ /index.html;，让所有不存在的路径都回到 index.html，由前端路由接管。这个坑几乎每个部署 Vue 项目的人都遇过，写进博客绝对能帮一批人。
4.3 环境配置常见报错速查
这部分我直接整理成表格，都是我亲眼见过同学栽进去的“高频事故”。
| 症状 | 原因 | 解决方案 |
|---|---|---|
启动报Access denied for user 'root'@'localhost' | 数据库账号密码或权限不对 | 检查 application.yml 中的账号密码，或执行授权 SQL |
接口查询报错Table doesn't exist | 数据库只导入了结构，没导入数据 | 用 Navicat 导入完整的.sql文件，数据表和测试数据一起导 |
| 能登录但查询中文全是乱码 | 数据库字符集不是 utf8mb4 | 创建库时指定DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，连接 URL 加characterEncoding=utf8 |
连接 MySQL 8.x 报Public Key Retrieval is not allowed | 连接 URL 缺少允许公钥检索参数 | 在 JDBC URL 末尾加allowPublicKeyRetrieval=true |
| 后端端口被占用 | 上次启动没停干净或其它程序占用 | Windows 用 `netstat -ano |
| npm install 卡死或慢 | 网络问题或镜像源问题 | 换成淘宝镜像源npm config set registry https://registry.npmmirror.com |
| 前端请求接口一直 404 | 代理没配置或接口路径拼接错误 | 检查代理配置是否生效，统一在 axios 中配置 baseURL |
这里单提一下 MySQL 8 的时间时区问题。连接 URL 里经常要写serverTimezone=Asia/Shanghai，否则会报The server time zone value '�й���ʱ��' is unrecognized。一劳永逸的办法是在 MySQL 命令行里执行set global time_zone = '+8:00'，或者建库时直接指定字符集和排序规则。这些都是老生常谈的问题，但每年毕设季都有大量人卡在这一步，可见搜索引擎里 “mysql安装配置教程”、“mysql设置默认值为0” 这类热搜词为什么一直居高不下。
5. 答辩展示与源码二开的正确姿势
5.1 答辩演示只讲一条业务主线
很多同学答辩时习惯按菜单顺序逐个功能演示——登录一下、点点居民信息、点点缴费、点点报销，像逛淘宝一样没重点。评委听下来只觉得“哦，是个系统”，但不知道你到底做了什么。
我的建议是“业务主线演示法”。开场就说清楚一句话：“本项目围绕城乡居民医保的核心业务闭环展开，即居民参保 -> 缴费 -> 就诊 -> 报销。” 然后顺着这条线往下走：
- 第一步，登录系统，展示如何区分管理员与普通操作员权限
- 第二步，新增一个居民信息，强调身份证唯一性校验和逻辑删除设计
- 第三步，为该居民办理年度参保缴费，展示重复参保校验
- 第四步，录入一条就诊报销记录，走审核流程，展示状态流转
- 第五步，打开统计看板，说明刚才的操作如何反映在缴费总额或报销支出里
五个步骤串起来，就是完整的数据闭环。评委看一眼就会觉得“这个学生懂业务”，而不是只会点按钮。
评委常见的几个提问也要提前准备一下：
- “分页是怎么实现的？” 答：PageHelper 插件，startPage 后由插件拦截 SQL 自动拼接 limit。
- “为什么用 JWT 而不用 Session？” 答：Session 依赖服务器端存储，分布式扩展时有问题；JWT 无状态，服务端不用存会话，适合前后端分离。
- “两个用户同时操作同一张报销单怎么办？” 答：可以加乐观锁字段 version，更新时校验版本号。哪怕没实现，能说出这个方案也很加分。
- “数据库删除数据会不会导致关联记录丢失？” 答：采用逻辑删除，业务数据以留痕为准。
5.2 拿到一份源码后，第一步该做什么
最后聊聊源码消化的问题。不知道为什么，很多人拿到源码第一反应是“先跑起来”，跑完就扔在一边。但如果你真的想把这个项目变成自己的东西，我建议按照这个顺序来：
先别急着运行。用 Navicat 打开数据库，把每张表看一遍，手动画出 ER 图，搞清楚表与表之间的外键关系。这一步能筛掉一半走马观花的人。然后是全局搜索“TODO”，看看作者留了什么没做完的活，这些地方往往是你下手改代码的最佳切入点。再往后才是运行项目，打断点从登录接口跟到数据库返回，把这个数据链路彻底走一遍。
我自己遇到过很多来问“我把源码改了但报错了”的同学，一查原因，连表结构都没看就直接改代码，字段名对不上，当然报错。所以我的个人原则是：拿到一份新项目源码，不是在 IDEA 里打开就完事；先画 ER 图，再谈改代码。按这个顺序，你能把一份毕设源码学出至少三倍的价值。
这几年我调试过的毕设项目没有一百也有几十个，最大的感觉是，信息管理系统这类项目看起来简单，但它对企业级开发的核心要素其实都有涉及：分层思想、表关系设计、权限控制、状态流转、前后端交互、部署上线。把这个项目真正吃透，SpringBoot 和 Vue 的基础框架就在你的脑子里了。以后再做任何管理系统，无非是换业务表、换状态流程而已。最后再分享一个实际操作中的小技巧：本地开发时连数据库，别用 root 账号，单独建一个普通用户授权业务库权限，这样既安全又避免误删系统库；生产环境部署时关闭 Swagger 和 Actuator 的敏感端点，细节做到位，项目才算真正收尾。
