1. 项目概述与需求拆解1.1 这类系统的真实使用场景做了这么多年Java开发接过的管理系统项目少说也有几十个但高校医疗健康服务管理系统属于那种看起来简单、做起来繁琐、但非常锻炼人的典型项目。最近又帮几个毕设阶段的学生梳理了这个题目发现大家普遍卡在同一个地方不知道从哪儿下手或者把代码堆出来了但说不清楚为什么这么设计。先说说这个系统到底是什么。它本质上是一个面向高校场景的信息化管理系统服务对象有三类学生、教职工和校医院工作人员包含医生和护士外加上一个超级管理员角色。核心业务覆盖了体检预约与结果管理、门诊挂号与病历记录、健康档案维护、疫苗预约提醒、常见病统计报表等一套完整的高校医疗健康服务闭环。这个题目的价值在哪里首先是真实场景驱动高校确实有校医院校医院确实需要管体检、管门诊、管学生健康信息所以整个系统的需求是站得住脚的。其次是技术栈经典Java SpringBoot SSMSpring、SpringMVC、MyBatis是目前国内企业级Java开发的高频组合用它来写一个管理系统对将来找工作写简历、准备面试都有实际帮助。第三是复杂度适中既不会像电商系统那样涉及高并发、分布式也不会像单纯增删改查的课程作业那样没有区分度刚好适合毕业设计或者中级实训的深度。如果你正打算做这个题目或者已经拿到了相关的源码和文档接下来我按自己的经验和大家拆解一下整体怎么设计、核心环节怎么做、部署调试过程中有哪些坑、最后怎么往简历上写。这些东西在官方文档和课程PPT里是看不到的。1.2 为什么选择SpringBootSSM这套组合很多人在选题后第一个纠结的问题是框架到底怎么选SpringBoot到底是和SSM冲突还是共存这两个问题是新手最容易搞混的地方。先说明白一个概念SSM是Spring SpringMVC MyBatis三件套的组合名称它是一个架构风格不是一个人。SpringBoot则是Spring家族的快速开发脚手架它通过自动配置和约定优于配置的思路把SpringMVC、MyBatis这些组件整合进一个开箱即用的工程里。所以SpringBoot和SSM不矛盾一个常见的方式就是SpringBoot作为工程基础和启动器内部整合SpringMVC处理Web层请求、MyBatis负责数据库持久层这就是标题里JavaSpringBootSSM的完整含义。说人话就是SpringBoot管启动和组装SpringMVC管接收请求、转发页面或返回JSONMyBatis管把Java对象和数据库表之间来回转换。三者各司其职组合起来就是一个完整的前后端交互闭环。选择这套组合的理由很现实第一资料极其丰富。随便搜一下就能找到大量的案例、踩坑帖、视频教程遇到问题能快速找到答案效率比用那些冷门框架高太多。第二校招和面试认可度高。在技术评估中面试官看到SpringBoot MyBatis项目至少能确认你有扎实的企业级Java基础不会因为用了某些小众框架而觉得你项目经验有水分。第三项目结构和代码风格高度规范。SpringBoot的目录约定controller/service/mapper/entity已经是社区共识就算中途换人接手看代码也能较快上手。第四部署相对简单。内置Tomcat容器打包成一个Jar文件就能跑这对演示和答辩非常重要。你不会希望在答辩当天因为环境配置问题而演示失败。1.3 角色与核心业务流程梳理高校医疗健康管理系统并不复杂但角色划分务必清楚因为角色决定权限权限决定菜单菜单决定前端页面和后端接口。这个逻辑链条理不顺写出来的代码一定是乱的。常规的角色设计如下角色核心权限典型操作管理员用户管理、系统配置、数据统计创建校医账号、查看全校健康报表、管理院系信息校医医生/护士门诊处理、体检记录、健康档案、疫苗管理接诊、录入诊断结果、维护学生健康档案、记录疫苗接种批次学生/教职工个人信息维护、预约挂号、体检报名、报告查看在线预约体检时间、查看体检报告、预约门诊号、查看健康档案核心业务流程可以按场景来理解体检管理场景管理员或校医发布体检计划设置时间、批次、对象范围→ 学生登录系统查看通知 → 在线预约某个时间段 → 按期到校医院现场体检 → 校医录入各项检查结果 → 系统自动归档到该生的健康档案中同时生成体检报告供学生查询。门诊就医场景学生选择校医院科室和医生 → 预约挂号 → 按预约时间到诊 → 校医填写门诊病历主诉、检查、诊断、处方建议→ 系统记录就诊历史供后续复诊参考。健康档案场景新生入学后批量导入基础信息 → 每学期体检数据自动同步 → 每年的就诊记录都会追加到个人健康档案 → 支持按学号、姓名、院系等条件检索。理清楚角色和流程之后系统的结构框架就出来了一个后台管理端面向管理员和校医一个学生端面向学生用户。接下来才谈得上建表、写接口、做界面。2. 系统架构设计与数据库设计2.1 单体架构还是前后端分离拿到项目后第一个要做的决策是架构形态。常见的有两种传统单体后端渲染页面和前后端分离Vue/React 后端接口。如果是从零开始做我的建议是根据团队基础和学习时间来决定。如果你前端JavaScript功底一般时间又紧那直接采用单体架构用SpringBoot默认的Thymeleaf模板引擎或者干脆使用JSP管理后台模板把页面渲染放在后端。这样做的好处是部署简单、代码量少、整体的业务闭环感强缺点是前端交互比较朴素页面效果不如前后端分离产品精致。如果你对Vue有一定基础或者这套项目将来需要往更像真实项目的方向演进那可以考虑前后端分离后端用SpringBoot提供JSON接口前端用Vue Element UI搭管理后台页面。这个方案视觉效果更好但开发量和联调成本明显上升尤其是在做权限控制、路由守卫、Token刷新这些环节时需要额外花时间处理。很多成熟的毕设项目源码实际采用的都是SpringBoot Thymeleaf 前端模板的形式这相当于一个折中方案页面由后端渲染但引用了Bootstrap和各类后台模板框架视觉上不输给前后端分离开发效率又高得多。如果你拿到的源码是这个形态并不代表它落后恰恰说明它经历过实战筛选、更适合课堂环境。2.2 SSM核心协作关系与项目结构不管选哪种前端方案后端代码结构基本遵循分层思想。以最常见的目录结构为例src/main/java/com/xxx/hospital/ ├── controller/ # 控制层接收请求参数校验 ├── service/ # 业务层处理业务逻辑与事务 ├── mapper/ # 数据访问层MyBatis接口 ├── entity/ # 实体类与数据库表字段对应 ├── config/ # 配置类如拦截器、跨域配置 ├── common/ # 通用类统一返回结果、常量、工具类 ├── utils/ # 工具类 └── HospitalApplication.java # 启动类对应地resources目录下放着resources/ ├── application.yml # 核心配置文件 ├── mapper/ # MyBatis的XML映射文件 ├── static/ # 静态资源CSS、JS、图片 └── templates/ # 模板引擎页面如果采用服务端渲染每一层的依赖方向必须是单向的controller调用serviceservice调用mappermapper操作数据库。千万不能出现controller直接操作数据库这种越级访问短期看起来省事后期维护和调试会非常痛苦。这不只是规范问题也是答辩时老师常常追问的点。2.3 数据库表结构设计思路数据库设计是这类管理系统的重头戏。很多同学一上来就建个几十张表显得非常丰富实际上冗余严重、字段命名混乱、外键关系不清。做高校医疗系统试着按业务域来规划数据表用户与组织域user表公共用户信息账号、密码、姓名、性别、出生日期、联系电话、邮箱、角色、头像、状态student表学生扩展信息学号、院系、专业、班级、年级、入学年份staff表教职工扩展信息工号、所在部门、职称department表院系/部门信息医疗业务域health_record表健康档案主表用户ID、血型、过敏史、既往病史、家族病史、建档时间physical_exam_plan表体检计划表批次名称、适用对象、开始/结束时间、状态physical_exam_appointment表体检预约表计划ID、用户ID、预约时间段、状态physical_exam_result表体检结果表预约ID或用户ID、身高、体重、视力、血压、血常规等字段、总检结论、检查时间clinic_registration表门诊挂号表用户ID、科室、医生、挂号时间、号序、状态medical_record表门诊病历表挂号ID、主诉、现病史、检查结果、诊断意见、处理意见、复诊建议系统辅助域vaccination_record表疫苗接种记录用户ID、疫苗名称、接种时间、接种机构、批次号notification表通知公告表标题、内容、发布人、发布时间、可见范围按这个粒度整个系统大约10~15张表足够支撑核心业务。有几条实战经验值得分享一是用户表要通过role字段区分角色而不是为每个角色建独立的用户表。否则登录验证时要在多张表之间来回查账号体系也容易乱。二是学生和教职工信息用一张扩展表关联用户表也就是把公共字段放user表把个性化字段放各自的角色扩展表。这样既满足不同角色信息差异的需求又不会造成字段大量空置。三是体检结果表不要搞成一行一个指标的形式。有些同学喜欢把身高体重血压每一类指标拆成独立行加上指标类型字段美其名曰扩展性好。实际上对这类管理系统来说一行一条体检记录、按字段存各项指标才是最简单实用的方式。既方便录入也方便展示和统计。四是状态字段务必加而且用整型枚举而不是字符串描述。比如预约状态0表示待体检、1表示已完成、2表示已取消。用数字好在哪查询排序方便、存储空间小、前端渲染时映射一下文案即可还能避免用户手输造成的脏数据。3. 核心功能模块与实操要点3.1 登录认证与权限控制登录模块是每个评委都会问到的地方因为它直接关系系统的安全性。哪怕是一个毕设系统也不能写个用户名密码对上就放行的简单逻辑。建议用拦截器或过滤器实现登录校验用户登录成功后把用户ID和角色写入Session并生成一个会话标识。在拦截器中放行登录接口和静态资源其余接口全部校验会话是否存在。这样做用户没登录就访问系统内部页面的情况能被统一拦截。对于权限差异处理最简单可靠的方式是在后端做角色判断。比如管理员访问用户管理接口、医生访问体检结果录入接口分别用RequiresPermissions这类注解或手工判断完成。一个很常见的错误是只在菜单上做权限隐藏而接口不设防、直接通过URL就能访问其他角色的功能这是评审时容易暴露的低级问题。另外密码存储务必进行加密处理不推荐明文保存。可以用Spring Security允许的BCryptPasswordEncoder或使用MD5加盐方案。后者实现起来简单算法公开透明毕设项目中完全够用。不要嫌麻烦这是项目底线。3.2 体检预约与结果录入体检模块是这个系统的业务核心整个项目能不能立住就看这块做得好不好。体检计划的发布流程建议设计成管理员创建计划 → 设置批次名称如2025级新生入学体检、时间范围、面向的院系或年级 → 保存后状态为未开始 → 人工发布后才变为报名中。加一个发布动作非常关键不然你在调试时明明保存了计划但前端看不到又或者在写测试数据时把所有人未发布的计划都查出来了徒增麻烦。预约冲突处理是一个容易被忽略的点。体检时间段设置成半小时一个槽位每个槽位限定人数。例如某天上午8:30到11:30共6个槽位每个槽位最多20人达到上限就不能再约。实现上就是在预约插入前先统计该时段已预约数量用事务保证原子性。具体到预约接口的代码流程大致是这样前端提交体检计划ID和预约时间段后端校验当前时间是否在计划报名时间范围内统计该时间段已有预约数若等于容量上限则返回该时段已约满检查当前用户是否已预约过该计划避免同一计划重复预约新增预约记录状态置为已预约结果录入环节有一个实用性很强的细节体检结果除了一个总检结论字段还建议设计是否异常的标记。这个标记用于后续统计与筛选比如筛选全校血压异常的学生名单做健康干预。学生查看报告时系统根据标记直接用不同颜色展示标题体验比单纯一段文字好很多。3.3 门诊挂号与病历管理门诊模块的逻辑比体检简单但要注意号和病历的关系。我见过一些设计把挂号信息和病历信息放在一张表里导致学生挂号了但还没看病时那一行记录了只有挂号字段有值、病历字段全空。这种方式也不是不能用但推荐还是拆开成两张表更干净。挂号成功时生成一条挂号记录带有医生姓名、科室、号序和状态。医生开始接诊后点击开始就诊更新挂号状态同时创建一条病历记录后续把问诊信息填进去。接诊完成之后挂号状态置为已完成。这套逻辑清晰而且在统计医生工作量时也方便计算某医生完成的接诊人次。病历表单中建议包含以下字段主诉患者自己描述的主要不适现病史发病时间、经过、治疗情况既往史和健康档案中的既往史可以联动带出体格检查体温、脉搏、血压等诊断结果处理意见用药建议、复诊建议、转诊建议等门诊模块要特别注意数据回填。就诊时医生大概率需要看学生的历史病历和过敏史。所以病历页面要预留关联健康档案的入口直接通过学号调出该学生的档案信息。这个联动既是业务刚需也是答辩时可以重点展示的系统考虑周全的证据。3.4 健康档案与统计报表健康档案本质上是把用户的体检记录、门诊记录、疫苗接种记录进行聚合展示。实现上通常以user表为基础通过用户ID在右侧栏或新页面里展示三类记录基本健康档案血型、过敏史、既往病史等长期稳定信息历次体检汇总按时间倒序显示批次、总检结论、关键指标历次门诊记录按时间倒序显示科室、诊断、处理意见页面做好后很多开发就停了但其实报表统计才是这类系统的加分项。做一个简单的统计页面按院系统计新生体检完成率、按学期统计门诊就诊人次、按年级统计近视率、超重率等健康指标。实现方式不需要什么复杂算法就是SQL的GROUP BY和COUNT组合。比如统计各院系体检完成率SELECT d.name AS department_name, COUNT(DISTINCT s.id) AS total_student_cnt, COUNT(DISTINCT ea.student_id) AS examed_cnt, CONCAT(ROUND(COUNT(DISTINCT ea.student_id) / COUNT(DISTINCT s.id) * 100, 2), %) AS completion_rate FROM student s LEFT JOIN department d ON s.department_id d.id LEFT JOIN physical_exam_appointment ea ON s.id ea.student_id AND ea.status 1 GROUP BY d.id, d.name;这类SQL语句在答辩现场很能打动老师因为它是带业务含义的说明你真的理解数据、不是只做增删改查。另外用ECharts做一个图表展示页也很加分。后端提供统计接口返回JSON前端用ECharts渲染饼图、柱状图。这个功能工作量不大但视觉效果好对学生来判断系统完整性很有说服力。4. 从0到1项目部署与调试实录4.1 环境准备与本地运行在开始之前先把环境准备好避免在调试过程中反复折腾环境要求推荐配置JDK1.8 或 11SpringBoot 2.x 推荐1.8IDEIntelliJ IDEA 2020 或 Eclipse数据库MySQL 5.7 或 8.0数据库连接工具Navicat / DataGrip / 命令行终端项目管理Maven 3.6前端辅助工具Chrome浏览器F12调试必备拿到项目后不要急着运行建议先按这个步骤走解压项目工程文件用IDEA以Maven项目方式导入选择pom.xml文件等待Maven自动下载依赖首次下载通常需要几分钟到十几分钟视网络情况而定在MySQL中新建数据库比如hospital_db字符集选择utf8mb4执行项目中提供的init.sql或hospital_db.sql脚本完成建表和初始数据导入修改application.yml或application.properties中的数据库连接配置启动项目等待控制台输出Started ...字样浏览器访问http://localhost:8080端口以配置为准整个过程中排在最前面的坑有两个一是IDEA导入项目时把它当普通文件夹打开了没有识别成Maven项目二是数据库连接配置写错。这两类问题占了调试初期问题的八成以上。4.2 配置文件里的隐藏坑与应用启动细节配置文件是启动环节最容易出问题的地方。一个典型的application.yml核心配置如下server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hospital_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.hospital.entity configuration: map-underscore-to-camel-case: true这里有几个细节要特别注意第一serverTimezoneAsia/Shanghai必加。MySQL 8.0默认时区和Java默认时区不一致不加会在操作DATETIME字段时出现时间偏差或报错。第二useSSLfalse要检查否则连接到某些MySQL版本时会有SSL警告。第三MyBatis开启map-underscore-to-camel-case可以在数据库字段是create_time、Java属性是createTime的情况下自动对应减少编写映射的工作量。还有一点很多人会忘记在启动类上加MapperScan注解。没有这个注解MyBatis无法扫描到mapper包下的接口项目启动时大概率报Invalid bound statement错误。如果你使用的是XML映射方式还需保证XML文件中的namespace和mapper接口的全限定名完全一致。SpringBootApplication MapperScan(com.example.hospital.mapper) public class HospitalApplication { public static void main(String[] args) { SpringApplication.run(HospitalApplication.class, args); } }4.3 联调测试与核心业务流程演示系统能启动不代表业务流程都通了。在答辩前的联调测试中建议按照业务主线走一遍全流程流程一管理员登录 → 创建体检计划 → 发布计划 → 查看预约统计这个流程考察的是管理员角色下的计划管理和统计能力。流程二学生登录 → 修改个人信息 → 报名体检 → 查看体检结果 → 预约门诊挂号这条链路覆盖了学生端最核心的操作如果这里通了整个系统的核心业务逻辑基本没有问题。流程三医生登录 → 查看今日挂号列表 → 开始接诊 → 填写病历 → 提交诊断 → 查看历史档案这条链路验证的是医生角色的接诊闭环也是信息关联度最高的环节。联调时建议按顺序一套流程走完不要跳跃。因为在业务链路中前一个操作的输出往往是后一个操作的输入只要其中一个环节出问题后面都会显示为空数据。比如学生报名了体检但状态没有更新为已完成医生在录入结果时可能就看不到这个学生的预约记录。调试时最趁手的工具是浏览器F12开发人员工具重点看Network面板的请求状态码。返回200不代表业务对要看响应体里的业务编码和消息返回500再去查看IDEA控制台的异常堆栈。如果接口返回了异常但控制台没有打印错误检查一下是否在application.yml中关闭了异常输出或者被全局异常处理器吞掉了建议在全局异常处理器中把堆栈信息打印到日志里。4.4 项目文档LW与调试文档的使用价值标题里出现了LW和调试文档这其实是这类项目交付物的组成部分。LW一般是论文或者设计说明书的缩写在整个毕业设计中占据的分数往往不低。一套成熟的文档通常包含摘要与关键词项目背景与意义国内外研究现状或技术概述需求分析功能需求、非功能需求、用例图系统设计架构设计、数据库设计、接口设计系统实现核心模块展示与代码讲解系统测试功能测试用例、测试结果总结与展望如果你拿到了写好的LW不要照抄交差建议按这个顺序把它变成自己的东西通读一遍理解结构 → 找到每一章节和你所写代码的对应关系 → 在文档中替换或补充你自己的项目信息和测试数据 → 对着文档把核心模块的代码跑通一遍。论文写得再漂亮如果你在答辩时不知道为什么数据库设计时会把预约表和结果表拆开仍然很难应对追问。调试文档一般来说是给接手者或评审老师看的包括环境要求、启动步骤、初始账号密码、可能出现的问题对照表。个人使用调试文档时建议做两件事一是把初始账号密码改成自己熟悉的比如管理员、校医、学生测试账号各一个二是把隐藏的问题排查结论回填到文档末尾变成你自己的提问-解决清单答辩时这就是现成的素材。5. 开发与调试中的常见问题速查5.1 项目启动类问题这个部分按照出现的频率依次说明越靠前的越常见。端口被占用启动时控制台报Port 8080 was already in use多半是项目之前启动过或本机其他程序占用了端口。解决办法很简单关掉占用进程或修改server.port换一个端口。如果之前在IDEA里启动过还没停干净直接到服务窗口停掉旧进程。数据库无法连接报Access denied for user rootlocalhost或Unknown database。基本上离不开三个原因用户名密码写错、数据库名不存在、连接URL中主机端口不对。建议先用Navicat等工具手动测试能否用同样的账号密码连上库数据库层面通了再回来看项目配置。MyBatis映射文件报错报Invalid bound statement (not found)先检查mapper-locations路径是否匹配实际文件位置再检查MapperScan有没有扫描到对应的Mapper接口最后检查XML文件里的namespace是否正确。还有一个细节Maven项目在修改XML文件后有时没有重新编译到target/classes目录下此时执行clean再package或直接重启项目即可。5.2 业务运行类问题中文乱码分两层排查。如果数据库中是乱码先确认数据库和表字符集为utf8mb4连接URL中带上characterEncodingutf8。如果是页面显示乱码检查模板文件编码是否UTF-8以及HTTP响应头的Content-Type是否设置了charsetUTF-8。词义查询和Condition拼接问题做学生列表、体检记录的模糊查询时经常出现关键字为空时查所有数据关键字非空时按条件过滤的麻烦。MyBatis中注意写where标签配合if标签来自动处理前置AND/OR的关系不要手动拼接出多余的WHERE或AND。JSON序列化循环引用如果实体类之间有关联关系例如用户包含一份健康档案直接返回用户对象时可能报StackOverflowError。这也是一个问题高频区。常规解决思路是在需要返回的字段上加JsonIgnore注解、或者用DTO去承接返回数据不要直接把实体类原封不动地往接口外抛。Session失效或权限拦截太松有同学把Session超时时间设得极长实现永久登录这在演示时很方便但答辩老师多半会追问校验机制和安全性。建议Session超时设置为30分钟同时把记住我功能实现成基于Cookie的令牌自动登录如果确实需要的话而不是简单拉长会话生命周期。5.3 环境调试类问题Maven依赖下载慢或失败国内网络环境下在settings.xml中配置阿里云镜像地址依赖下载速度会有明显提升。如果个别依赖始终下载失败尝试清空本地仓库中对应的lastUpdated文件后重新导入。IDEA热部署不生效SpringBoot项目改代码后需要手动重启才能生效这很正常。如果使用了spring-boot-devtools还不生效检查IDEA设置里的Build project automatically选项是否勾选以及是否开启了Allow auto-make to start even if developed application is currently running。前端页面样式丢失检查静态资源路径特别是Thymeleaf页面中th:href{/css/style.css}这类写法是否正确。很多样式丢失问题都出现在把相对路径写成了/css/style.css导致在二级路径下找不到资源。6. 项目进阶从毕设到可落地的真实系统6.1 值得追加的三个实用功能把核心流程跑通只是及格线。如果你想在答辩中脱颖而出往下面三个方向扩展效果会比较明显。第一个方向是消息通知与提醒。体检计划发布后给学生推送一条站内或邮件通知体检报告生成后通知学生查看疫苗到货后给适合接种的学生群发消息。这部分不需要引入消息队列用一张notification表加上定时扫描即可实现。第二个方向是数据导出。给管理员做一个统计报表导出功能选好范围后一键导出Excel可使用Apache POI。上一届辅导员在学期末向学院递交学生体检汇总Excel这就是真实场景。有了这个功能系统就不只是看看数据而是真正帮人省力。第三个方向是基于时间段的号源容量控制。门诊挂号不只是剩一个号就是有号而是按科室、按医生、按时段分别设置容量。前端选择日期后再加载时段余量这一设计会明显提升系统的成熟感。6.2 简历上怎么描述这个项目做毕设或课设不只是为了交差怎么把项目写进简历、在面试中讲出来同样重要但很多同学恰恰在这一步吃了亏。简历项目描述不建议写基于JavaSpringBootSSM的高校医疗健康服务管理系统这种纯技术名词堆砌改为某高校医疗健康服务管理系统SpringBoot MyBatis MySQL这种结构更好。描述页建议从技术和业务两个维度展开技术维度负责系统整体架构设计与数据库表结构设计基于SpringBoot整合SSM框架实现用户权限控制、体检预约、门诊病历、健康档案等核心功能。业务维度实现了按院系统计体检完成率与健康指标异常分布支持Excel导出将校医院日常业务从线下纸质记录转为线上数字化管理。面试中被问到核心难点时可以从三个方面展开一是预约冲突处理是如何通过事务和容量判断来避免超约的二是多角色权限控制如何通过拦截器和角色判断保证不同用户只能访问授权功能三是MyBatis动态SQL如何解决了多条件组合查询和模糊匹配问题。这三个点能讲透项目深度和你的理解程度自然会被认可。6.3 运维与后续迭代思路这个系统做的是高校医院的业务要想真正上线使用还需要考虑不少在课程设计中不用太在意的问题服务器部署用什么系统、Jar包怎么用nohup后台启动、日志如何按天切割、数据库如何定时备份、体检报告PDF怎么打印盖章、能否对接学校统一身份认证系统等等。其中比较建议做的一步是修改application.yml为多环境配置。开发环境用本地数据库生产环境用服务器数据库通过spring.profiles.activeprod一键切换。这一步投入不大、但非常专业哪怕只是写到文档里体现你考虑过部署问题也比只能本地运行高一个段位。我在实际指导过程中常和学生说的是毕设项目不是越炫越好而是越能自圆其说越好。技术栈可以不前沿但核心模块必须完整业务流程必须自洽关键的设计判断必须讲得出理由。把上面这些问题都搞清楚之后你会发现答辩时老师问什么你都能接得住甚至会觉得怎么比我想象中简单。毕竟你对项目的理解已经到这个位置了。