做毕设选题目的时候很多同学会陷入两个极端要么选一个纯仿电商的商城系统烂大街不说答辩老师一眼就能看出是不是自己写的要么选一个看起来很高大上的分布式微服务项目结果做了一半发现根本撑不起来最后三天赶工交给代做。今天我想聊的这类高校健康信息管理平台也就是标题里那个SpringBootVue的高校疫情防控web系统管理平台恰好卡在一个很微妙的位置——它不冷门也不烂大街业务逻辑足够完整技术栈正好覆盖主流框架很适合用来做毕设、课设甚至作为你简历里的一个实战项目来写。先说说我为什么对这类项目有发言权。早年间我帮不少同学审过毕业设计自己也带过几个类似的课设小组。这类健康管理系统表面上是信息管理CRUD但仔细拆开看它涉及多角色权限、流程审批、数据统计、异常预警层层都有实际业务逻辑而不是单纯把数据库表格搬到网页上。这恰恰是很多同学做项目时最吃亏的地方也是我想详细展开的价值点。这篇文章我不打算写成一份从零开始的教学文档而是从一个过来人的角度把这个系统从选题定位、技术栈选择、表结构设计、核心功能实现到权限体系、答辩演示细节完整地走一遍。你不需要真的照着复刻每一行代码但你看完以后至少能搞清楚这个系统到底在做什么、每一块该怎么写、写到什么程度才能在答辩的时候站稳脚跟。1. 选题看着简单但评审老师真正在考察的是这三件事很多同学选这类题目的时候想的都是就是学生填个表、辅导员看一眼、管理员导出个Excel嘛。如果你真按这个理解去做最后交上去的东西大概率是一堆没有任何业务逻辑的增删改查答辩的时候老师问一句你这个系统解决了什么痛点你就答不上来。我带你换个视角看看评审老师拿到这个题目时心里其实是在考察哪几件事。1.1 业务闭环是否完整一个能拿得出手的管理系统一定是有业务闭环的不是孤立的CRUD页面。就以这个健康管理系统为例它的核心闭环是学生提交健康信息、系统自动做异常判断、辅导员逐条审批或批量处理、异常情况自动生成预警记录、学院管理员查看统计报表、必要时下发通知公告。每一步都是上一步的延续上一环节产生的数据驱动下一环节的展示而不是各写各的页面。我见过不少同学做这类系统前端搞了七八个页面后端写了二三十个接口看起来工作量很大但数据之间根本没有关联。比如学生提交了一个异常报告辅导员端没有任何待办提醒比如管理员能看到全校的汇总数但点进去看不到具体是哪些学生。这就是典型的只有页面没有系统评审老师随便点两下就发现问题了。1.2 技术覆盖面是否合理毕设阶段的系统技术选型不是越复杂越好而是覆盖面要刚好够看。SpringBoot负责后端接口和业务逻辑、Vue负责前端交互和状态管理、MySQL负责数据持久化这个组合本身就是一个完整的技术展示面。更为重要的是在这个项目里你能自然地用上一些面试和答辩中的高频知识点MyBatis-Plus的多表查询与条件构造器、JWT的登录认证与Token鉴权、Vue Router的路由守卫、ECharts的数据可视化、以及MySQL的索引设计和聚合查询。这些技术点不是堆上去的而是业务真的需要。比如审批列表需要分页和条件筛选你得会用MyBatis-Plus的Page对象比如不同角色看到不同菜单你得会用路由守卫做前端拦截配合后端接口做二次鉴权。这些东西在简历上写熟悉SpringBootVue全栈开发的时候才能经得起追问。1.3 现场演示是否顺畅毕设答辩本质上是一场带解说功能的现场演示。系统功能做得再深如果演示环节不顺畅——比如切换角色要重新登录、统计数据还没加载出来、异常触发条件造不出来——都会直接扣分。所以随着开发进行你要有意识地预留演示数据设计好演示路径。哪些页面先展示、点击哪些按钮能最快看到效果、用什么账号登录能看到最完整的数据心里要有一份演示脚本。顺着这个角度看你就明白了这个题目的核心不是会写代码而是懂业务、有闭环、能演示。接下来的技术选型、表结构、功能实现全都是围绕这三点展开的。2. 技术栈定型的逻辑为什么锚定SpringBootVue而不是别的组合技术选型这一步决定了你后面三个月是轻松还是痛苦。我在帮同学审项目的时候最怕看到的就是技术选型花里胡哨、实际开发寸步难行的组合。这里我把每一个关键选型和它的理由拆开讲清楚。2.1 后端定型SpringBoot 2.7 Java 8 MyBatis-Plus选SpringBoot几乎没什么悬念它是目前Java后端开发的事实标准资料多、社区大遇到问题搜一下就有解决方案。版本上我建议用SpringBoot 2.7.x配合Java 8不要一上来就上Java 17和SpringBoot 3.x。原因是毕业设计的开发周期本来就紧很多第三方资料、网上的现成代码片段都是基于老版本的用新版本容易遇到兼容性坑没必要给自己添麻烦。持久层框架我强烈推荐MyBatis-Plus。原因很简单单表CRUD不用写SQL一个BaseMapper接口全搞定复杂的多表联查、条件统计又有现成的LambdaQueryWrapper可以用开发效率比原生MyBatis高很多。而且MyBatis-Plus的分页插件做得非常成熟配合Page对象一行代码就能完成分页查询。这些在答辩的时候都是可以拿出来讲的实践细节。再说数据库连接池和工具类。连接池直接用Druid阿里的因为它自带监控页面答辩的时候可以打开监控页面展示SQL执行情况——这个小亮点很多同学根本不知道。工具类方面Hutool是我每次做项目都会引入的日期处理、Excel导出、随机数据生成一个库全搞定。这里面的逻辑是把通用性问题交给成熟的工具库把精力留给真正的业务代码。2.2 前端定型Vue 2 Element UI还是Vue 3 Element Plus前端这块是很多同学的纠结区。我的态度很明确如果你之前没怎么写过Vue选Vue 2 Element UI如果你已经比较熟悉Vue 3的组合式API那就选Vue 3 Element Plus。两个都行但千万不要混着用。我为什么通常建议Vue 2 Element UI因为网上现成的后台管理模板、组件示例90%都是基于这个组合的。你随便找一个开源的后台管理布局登录页、侧边栏、路由菜单、动态面包屑这些就全有了你要做的只是往里面填业务页面。Vue 3虽然是趋势但Element Plus的组件行为有一些细微变化比如表单校验规则、对话框的销毁逻辑对新手来说遇到问题更不好查。当然如果你已经能熟练写组合式APIVue 3的setup语法写起来确实更清爽值得尝试。2.3 认证授权方案JWT而不是Session这里我要专门说一下认证方案。很多课设项目用的是Session Cookie这个方案本身没错但它的痛点在于后端需要维护会话状态前端的请求还得处理Cookie携带的问题而且在演示的时候如果开了两个浏览器标签页还要考虑会话是否共享。JWTJSON Web Token的方案则完全不一样用户登录成功之后后端返回一个Token前端存在本地之后的每一次请求都在请求头里带上这个Token后端解析Token就能知道是谁在调用接口。这个方案无状态、跨域友好、前后端分离时特别好用这是它作为毕设选题加分项的核心原因。当然JWT也有一些要处理好的细节比如Token过期时间设置多长、用户退出时要不要让Token立即失效、以及如何在前端响应401状态码时自动跳转到登录页。这些细节后文我会展开它们是答辩时老师非常喜欢追问的点。2.4 数据库与中间件只用MySQL够不够MySQL是常规选择不需要犹豫。带不带Redis是另一个问题——我的建议是除非你确实需要缓存热点数据或者要用Redis做某些特殊功能比如验证码存储否则可以不加。毕设阶段加Redis会多出很多序列化、过期策略、缓存一致性之类的额外复杂度性价比不高。把MySQL的表结构和索引设计做好已经够你展示数据库能力了。所以整合起来看后端SpringBoot MyBatis-Plus JWT前端Vue Element UI数据库MySQL构建出了一个典型的全栈技术栈。这套技术栈不重但每一层都有的讲、有得用而且面试的时候通用性强。想通这一点你后面做功能的时候就不会频繁推翻重来。3. 数据模型设计五张核心表把整个业务闭环撑起来数据模型是系统的地基。很多同学一上来就建了二十几张表字段随意关联混乱写到后面自己都搞不清楚哪张表存了什么。我建议你先画一张业务关系图把角色、行为和状态流转理清楚再反推表结构。对于这个健康管理系统核心表其实只需要五张剩下的都可以围绕它们扩展。3.1 用户表与角色表单表 角色字段就够了用户表sys_user是系统的基础字段包括id、username登录名、password加密后、real_name真实姓名、role角色、college学院、grade年级、class_name班级、phone、status启用状态、create_time。用role字段区分学生、辅导员、管理员三种角色不要单独建角色表和用户角色关联表。为什么这么设计因为这个系统的角色是固定的三种不存在动态权限分配的需求。如果你建了shiro或者Spring Security那套完整的RBAC模型表会多出三四张而实际用到的权限逻辑却非常简单这就是过度设计。答辩的时候如果有人问你为什么不做角色表你就说固定角色、权限清晰、单表查询效率更高完全站得住脚。性别、年龄这些字段要不要加建议加一个gender就够年龄不要存存出生日期或者干脆不存。因为年龄是实时变化的存字段就得维护徒增成本。3.2 健康上报主表核心是唯一索引和状态字段健康上报表health_report是整个系统的数据核心。字段建议这样设计id、user_id关联学生、report_date上报日期、body_temperature体温、health_status健康状况枚举正常/感冒/咳嗽等、is_contact_risk是否接触异常人员、is_out_school是否离校、location_code当前所在地、status审核状态待审批/已通过/已驳回、approve_remark审批备注、create_time、update_time。这里有两个特别容易踩的坑我要重点说。第一个坑是上报日期的唯一性控制。同一名学生同一天只能提交一条上报记录这个约束不能只靠后端代码判断因为并发情况下会有重复提交的问题。正确做法是在表上建唯一索引例如(user_id,report_date)这样即使代码漏判了数据库也会拦住第二天的重复记录。这个细节在答辩中属于加分细节可以主动提。第二个坑是状态字段的流转设计。health_status保存的是学生填写的健康状况描述而status保存的是辅导员审批后的结论两者不能混淆。有些同学会把学生填的正常和审批的通过混在一个字段里逻辑就乱套了。健康状态是客观事实审批状态是处理结果一定要分开。3.3 审批记录表让每一次操作都留下痕迹审批记录表approve_record设计得很简单id、report_id关联上报记录、approver_id审批人、approve_status通过/驳回、approve_remark审批意见、create_time。有的同学会问health_report表里已经有status字段了为什么还要单独建这张表原因有两个。第一审批是一个历史行为需要可追溯。辅导员今天驳回了学生修改后再次提交这时候你就需要知道之前发生过什么。如果只在report表里改status历史信息就丢了。第二筛选数据的场景不一样。你要查某个学生最近一周的审批记录、某个辅导员今天审批了多少条用这张单独的表性能更好逻辑也更清晰。3.4 通知公告表与异常记录表通知公告表notice用来发消息字段就是 id、title、content、publisher_id、publish_time。这个比较简单不多说。异常记录表abnormal_record是系统里比较有亮点的设计。它不需要用户手动填写而是通过定时任务或者提交时的逻辑判断自动生成。判断规则可以有很多种体温大于37.3度、健康状态选了发热、接触过风险人员、当前所在地是风险地区等等。每次上报提交时后端自动判断这些规则如果命中就写一条异常记录同时给该学生的辅导员生成一条待办事项。这背后其实就是一个简单的规则引擎思路把异常判断逻辑从提交接口里抽出来独立成一个判断方法后续要加规则只要改这一个地方就够了。这类自动触发的功能在毕设里很加印象分因为大多数人只做了人工填表没有做系统自动处理和推送。3.5 五张表之间的关系如何看待总结一下这五张表的关系sys_user是主体health_report记录行为approve_record记录处理动作abnormal_record记录自动判断结果notice用于信息触达。你向评审老师讲的时候不要一张表一张表念字段而是画一张这样的关系图三言两语讲清楚数据流转学生登录后填写health_report提交时触发异常判断逻辑写入abnormal_record辅导员登录看到待审批列表处理时写入approve_record系统管理员负责看统计和发公告。这套讲解方式既体现你的全局思维又避免挨个字段念经的尴尬。顺便说一句建表的时候所有时间字段统一用datetime类型不要用timestamp。datetime在查询展示的时候更直观不容易遇到时区问题而timestamp取值范围有上限还会自动转换时区排错的时候容易懵。这是我在实际项目中换来的经验。4. 核心功能模块的落地实现上报、审批、统计三条链路表结构设计好之后系统的骨架就清晰了。接下来的核心就是围绕三条业务链路把功能一个个实现出来。我会把每条链路的关键逻辑和代码写法讲透。4.1 上报链路前端表单校验 后端防重复 自动异常判断学生端的核心页面是每日健康上报。前端用Element UI的Form表单做字段对齐上面的health_report表体温、健康状态、是否接触风险人员、是否离校、所在地、备注。这里前端的重点不是好看而是校验完整性。体温必须限定在合理范围比如35度到42度之间否则用户误填一个0后端接口做了多少个判断都没意义。后端的核心代码要处理三件事。第一是防重复提交先查询今天是否已经上报过如果已经存在直接返回今日已上报的提示。第二是参数合理性校验用JSR 303的注解NotNull、DecimalMin等做基础校验加上自定义的业务判断。第三是触发异常判断逻辑这就是上面的规则引擎思路。我贴一段核心逻辑的伪码你感受一下结构Transactional public ReportResult submitReport(ReportDTO dto, Long userId) { // 1. 校验当天是否已上报配合数据库唯一索引双保险 LocalDate today LocalDate.now(); Long count reportMapper.selectCount( new LambdaQueryWrapperHealthReport() .eq(HealthReport::getUserId, userId) .eq(HealthReport::getReportDate, today)); if (count 0) { return ReportResult.fail(今日已上报请勿重复提交); } // 2. 保存上报记录 HealthReport report new HealthReport(); BeanUtils.copyProperties(dto, report); report.setUserId(userId); report.setReportDate(today); report.setStatus(ApproveStatus.PENDING); reportMapper.insert(report); // 3. 自动异常判断 if (isAbnormal(report)) { saveAbnormalRecord(report); // 4. 生成辅导员的待办通知 notifyAdvisor(userId, report); } return ReportResult.success(); }你那句如何检测同一用户同一日期的重复记录如果不加数据库唯一索引即使代码查过了也会有并发缝隙所以selectCount只是第一层数据库唯一索引才是硬约束。这块逻辑虽然简单但能展开讲并发防护、数据库约束、事务管理三个知识点是答辩的好素材。还有一个小细节上报成功之后学生的首页最好显示今日已上报明天继续的状态卡片并展示最近七天的上报记录。这个功能用ECharts画一条体温折线图就非常直观既能体现数据可视化能力又让学生用户有获得感。4.2 审批链路待办列表 批量处理 记录留痕辅导员登录后首页就是待审批列表。这个列表的SQL并不复杂用LambdaQueryWrapper查health_report表条件是status 待审批同时关联查询上报学生的姓名、班级。这里要注意分页因为一个辅导员管几百个学生一天的上报数据可能有几百条不分页的话页面会非常卡。MyBatis-Plus的分页插件提前配置好写起来非常顺手PageReportVO page reportMapper.selectPage( new Page(current, size), new LambdaQueryWrapperHealthReport() .eq(HealthReport::getStatus, ApproveStatus.PENDING) .orderByAsc(HealthReport::getReportDate) );审批操作分为通过和驳回。通过就更新report表的status同时插入approve_record驳回则要填写驳回原因方便学生端看到后重新提交。这里有一个提升效率的设计支持勾选多条记录批量审批通过一条一条点对于数据量大的场景实在太痛苦。批量处理的实现也简单前端传入id列表后端循环处理或者用updateBatchById但每一条都要写入审批记录所以不能用一个简单的update语句完成循环逐条处理反而更好。审批链路里最容易忽略的是待办数量提醒。辅导员登录后侧边栏或者首页上最好有一个小红点显示今日还有N条待审批。实现方式就是在辅导员登录后的首页查询接口中加一个count查询前端拿到数字后展示。这个体验细节很加分因为用户一眼就知道自己今天还有多少活要干。4.3 统计链路ECharts可视化 按维度钻取管理员的看板是这个系统的门面也是答辩时最吸引老师目光的部分。统计维度可以有以下几种全校当日上报率已上报人数/应上报人数、各学院上报率排行、各年级异常人数、近两周体温趋势、异常类型分布。上报率的SQL我建议写成按班级或学院分组聚合配合日期筛选。示例逻辑是SELECT college, COUNT(DISTINCT user_id) AS reported_count FROM health_report WHERE report_date ? GROUP BY college值得注意的是前端展示这些数据用的是ECharts。饼图展示异常类型占比柱状图展示各学院上报率折线图展示近7天体温平均值趋势。这些图表不用做得特别炫但你要在答辩的时候说清楚每一个图表对应哪一个管理需求比如这个柱状图是让管理员快速定位上报率偏低的学院点进去可以钻取到具体班级。钻取功能如果做了是很大的加分项。实现方式不复杂柱状图绑定了点击事件点击某个学院下方表格切换成该学院的班级维度数据再点击某个班级就能看到该班具体学生名单和上报状态。这就是一层一层下钻的分析思路比平铺直叙的报表高级得多。4.4 三个链路之间怎么串起来其实这三条链路不是割裂的学生提交触发自动异常判断异常生成后辅导员审批审批通过后进入统计报表的数据源。为了打磨这条业务流你需要真的花心思串联一些细节。比如统计图表上的数字点进去要能看到对应的学生记录驳回的记录学生修改后重新提交状态要从新走一遍待审批流程而不能延续旧的审批状态。这些数据流转的小细节做得越干净答辩的时候被追问的概率就越低。有一个环节我建议你刻意留一个未完成但有思路的功能点比如导出报表或者批量导入学生信息。不要做得很完整留一个待优化空间让评审老师有针对性地提问你刚好可以借此展示你的技术方案——这种留白的答辩策略在实战中反而容易拿高分因为老师很难从完美且复杂的项目中找到提问点。5. 三种角色的权限体系从登录认证到接口鉴权的完整链路权限体系如果做得不好系统就是一堆页面拼凑做得好了则是体现后端安全意识和架构能力的关键模块。这里从登录到接口鉴权把整条链路理清楚。全文不涉及Spring Security这类重量级框架用JWT 拦截器足以覆盖需求而且代码可控性更高。5.1 登录逻辑登录、签发Token、前端存储登录接口接收用户名和密码先查用户表确认账号存在、状态未禁用然后比对密码注意密码存储要加密推荐BCrypt它是Spring Security自带的一个加密工具单独引进来也行。验证通过后用JWT工具类生成TokenToken的payload里放userId和role过期时间设置为24小时。响应给前端两样东西Token和用户基本信息用户名、角色、姓名。这里有一个需要明确的细节不要把密码放在JWT的payload里。因为JWT本身只做签名不做加密payload部分是Base64编码的可读信息任何拿到Token的人都能解码看到里面的内容。正确做法是只放用户标识和角色其他信息需要时从数据库查。前端的处理是登录成功后把Token存在localStorage里然后通过Axios的请求拦截器统一在请求头里加Authorization字段。同时Axios的响应拦截器要处理401状态码——Token过期或无效时统一跳转回登录页。5.2 后端鉴权拦截器 角色判断后端写一个LoginInterceptor实现HandlerInterceptor接口在preHandle里统一拦截需要认证的接口。逻辑顺序是从请求头取出Token、校验签名和过期时间、解析出userId和role、放入ThreadLocal或Request域中供后续业务代码使用、再让请求继续往下走。对于角色级别的接口鉴权我是这样实现的。给需要特定角色访问的接口定义一个自定义注解比如RequireRole(ADMIN)然后在拦截器里根据当前请求的路径匹配注解如果注解要求的角色和Token解析出来的角色不一致直接返回403。这个方法比Spring Security的注解简单直观而且代码量小答辩的时候能说得清逻辑。各个角色的数据访问范围也要在代码层面对齐学生只能查自己的上报记录查询条件强制带上userId辅导员只能查自己名下学生的记录用户表里加一个advisor_id字段关联辅导员管理员有全部数据权限。这里最怕的就是只靠前端路由隐藏页面、接口没有任何保护别人拿到接口地址直接访问就能看到所有数据。后端的接口鉴权做扎实是系统安全性的底线。5.3 前端权限与路由守卫后端做了接口鉴权前端也要配合做页面级别的权限控制。登录成功后前端根据用户角色动态生成路由表。可以把所有的业务页面路由都定义好但用Vue Router的beforeEach守卫来判断当前用户角色是否能访问某个页面或者更优雅一点用addRoute在登录后动态注册对应角色的路由。前端还有一个细节不要只控制页面跳转按钮级别的控制也很重要。比如普通学生不应该看到批量审批的按钮这个判断可以用自定义指令实现。不过要注意前端的按钮控制只是为了用户体验后端必须同样有校验不能指望前端藏着就行。5.4 权限体系里的常见坑和应对这里列举几个我见过的高频问题Token过期后前端没有跳转登录页导致用户操作着操作着页面突然报一堆奇怪的接口错误。解决办法是写一个全局的401拦截统一处理。修改密码或退出登录后旧的Token仍然有效存在安全隐患。对这个需求可以引入Token黑名单把退出的Token加入一个Redis或用数据库表维护的失效列表如果不想引Redis也可以把Token的过期时间缩短配合前端定时刷新机制。用户修改了角色后旧Token里的角色信息可能还没更新导致接口权限不对。解决办法是每次请求时用userId查一次最新角色或增加Token刷新机制。处理的时候不用太过纠结因为这些都是你讲出来老师会觉得你想过的点做完核心功能之后挑一两个你认为好解释的去实现。6. 开发过程中最常踩的坑和答辩演示时的加分细节最后这部分我想从自己实际带项目、看项目的经验里提炼几个最常见的踩坑点和答辩加分细节。这部分也许是最杂的但也是最实用的建议你在做项目的过程中反复对照。6.1 前后端联调时最容易出Bug的四个地方第一是跨域问题。前后端分离部署在不同端口开发环境下前端用axios请求后端接口浏览器默认会拦截跨域请求必须后端配置CORS或前端使用代理解决。我建议后端统一加一个CorsFilter因为部署到服务器之后前后端大概率还是不同端口配置一次在哪都能用。第二是日期格式问题。前端传2024-05-20这样的字符串后端如果用的LocalDate接收需要配合DateTimeFormat注解或者全局Jackson配置。返回给前端时LocalDateTime默认格式可能是一长串数字也要统一格式化成yyyy-MM-dd HH:mm:ss。这块不处理好页面上的时间显示就会乱掉。第三是空值处理问题。统计图表用的数据如果某一天没有上报记录查询出来的集合可能就是空的前端的ECharts拿空数组直接初始化会报错或显示空白。后端做聚合查询时要补全缺失日期或者前端做空数据处理避免图表区域一片空白。第四是事务边界问题。审批批量处理时如果处理到第三条失败了前两条已经更新了数据就不一致。批量操作一定要加Transactional做事务管理任何一个操作失败就整体回滚。6.2 演示时的细节测试数据至关重要答辩演示的成败一半在你代码写得好不好一半在你的测试数据造得好不好。很多同学最后几天随便点了两三条数据就开始演示效果惨不忍睹。我的建议是提前造一套符合真实场景的模拟数据。比如5个学院、每个学院2个专业、一个专业两个班、每个班20个学生近15天的上报记录其中让少数学生有异常记录个别班级有连续未上报记录辅导员账号三四个管理员账号一个密码统一用简单的。这套数据用SQL脚本写好答辩前重新导入一次数据库保证演示的时候界面是丰富的图表是有波动的待办列表是有数据待处理的。造数据还有一个技巧让学生账号里面有一个今天还没上报的账号这样答辩时你可以现场演示学生端填写提交然后切到辅导员端看到这条记录出现在待办列表里审批通过后切到管理员端看到统计数字产生了变化。一整套演示动作行云流水说服力非常强。6.3 答辩前预期准备的问题清单答辩本质上是一场预期的问答提前准备问题比临场发挥靠谱得多。我总结了一些围绕本系统的高频问题你可以对照准备为什么选用JWT而不是Session无状态认证的优势在哪同一学生同一天重复提交你是如何防止的代码层面和数据库层面分别是怎样兜底的异常记录是如何自动生成的以后要新增判断规则怎么改成本最低三个角色之间数据权限的隔离是怎么实现的如果直接把接口URL拿出来访问能绕过前端拿到数据吗你的统计报表数据是实时的还是缓存的如果数据量大查询性能怎么优化上传文件的场景里面如果有做文件存在哪里如何防止上传恶意文件每一个问题不需要回答得多深但至少要能讲两三句具体的实现细节。最怕的是回答得含糊、只会说这个我用了MyBatis-Plus评委追问两句就接不上话。6.4 最后再分享一个让项目质感提升的小技巧这个项目做完之后我强烈建议你写一个README文件放在项目根目录。里面写清楚项目简介、技术栈列表、如何初始化数据库、启动步骤、默认账号密码、项目结构说明、以及核心功能的实现思路。不要小看这个动作不少同学的项目代码写得很不错但评审老师拿到手上根本不知道怎么启动、有哪些账号体验分直接下降。一个清晰的README配合一套能跑的模拟数据在答辩和课设检查的时候简直是给评审老师的快速上手说明书观感完全不一样。如果你学有余力还可以挑一个模块做单元测试比如健康上报的防重复提交逻辑、异常判断规则。不要全做集中做一两个核心业务就行。答辩时你说我对核心逻辑写了单元测试这个维度已经击败了90%的课设项目了。做这类系统最忌讳的就是好高骛远。先把SpringBootVueMySQL这条主线跑通把健康上报、审批流、统计看板这三条链路做扎实然后围绕它们把权限细化、把异常判断自动化、把演示数据准备齐全——做完这些你的项目在毕设答辩中的表现一定不会差。希望这篇文章能帮你把思路理清楚少走一点我当年走过的弯路。