1. 项目全景毕业生信息招聘平台到底在解决什么问题1.1 这个选题为什么值得做每年到了大四下学期很多计算机相关专业的同学就开始为毕业设计发愁。选什么题目、做什么技术栈、写多少代码、答辩怎么讲一环扣一环。而我今天要聊的“毕业生信息招聘平台”这个题目属于典型的管理信息系统MIS类毕业设计它最大的优势是业务场景极其清晰、用户角色明确、数据处理流程完整既有足够的代码量支撑论文字数又不会复杂到让人在两个月内赶不完。从实际需求来看每年高校毕业季就业信息分散在各个渠道——学校就业网、企业官网、辅导员转发的群消息、各类招聘App学生找起来零散企业招人也缺乏一个能直接触达应届生的窗口。毕业生信息招聘平台的出现本质上就是把“学生—企业—学校管理者”三方角色放到同一个系统里让职位发布、简历投递、信息审核、数据统计形成闭环。这个场景不虚拟、不悬浮甚至很多高校确实需要这样一个内部平台所以无论是开题答辩还是评审老师提问它都站得住脚。1.2 三方角色与核心业务流程拆解任何以“平台”为后缀的系统第一件事就是要理清角色边界否则后面代码做到一半就容易面目全非。按照毕业设计的常规设计这个系统分成三种登录身份学生用户注册账号、完善个人信息、填写或上传简历、浏览职位、按条件搜索职位、投递简历、收藏职位、查看投递反馈状态。企业用户注册并提交企业资质信息、等待管理员审核、审核通过后发布职位、管理已发布职位下架/重新发布、查看收到的简历、对学生简历进行标记处理。管理员用户学生信息管理、企业注册审核、职位审核过滤违规或无效信息、岗位分类管理、系统数据统计注册量、职位量、投递量等。这样梳理下来核心业务流就很清晰了企业发布职位 → 管理员审核通过 → 学生浏览搜索投递 → 企业查看简历并反馈 → 学生查看反馈结果。整条链路对应了数据库里的各类单据表和状态字段后续设计表结构的时候就是沿着这条链路展开的。1.3 功能清单与交付物的对应关系很多同学做一个毕设只盯着“代码写完就行”忽略了最后交付物之间的耦合关系。实际上“毕业论文PPT源代码演示视频”这几样东西应该是互相咬合的整体不是各做各的。以我辅导过的此类项目为例它们的对应关系大概是这样的交付物对应内容演示/阐述要点毕业论文需求分析、概要设计、数据库设计、系统实现、测试论文里的架构图对应系统实际模块源代码前端工程、后端工程、SQL脚本、配置文件关键代码要能对应论文中的核心算法或设计演示视频按业务流程录制的系统实操最好对应论文的“系统实现”章节逐模块操作PPT背景、技术栈、功能演示、创新点、总结每页不超过3个要点图表优先这样理解之后你做每一个交付物的时候都有了“锚点”不会出现论文里画了三层架构图而实际代码只有一张学生表的情况。我在实际带项目的过程中见过太多“代码与论文严重分离”的例子结果答辩时一问就露馅。所以做这个项目第一建议就是先把业务流程和模块边界钉死再动手写代码。2. 技术选型毕设系统的架构该怎么定2.1 后端技术栈的选择逻辑对于毕业生信息招聘平台这种典型 CRUD 系统技术选型不需要追求花哨但一定要能体现“工程化”的思维。目前这类毕设最主流的方案是Spring Boot MyBatis/MyBatis-Plus MySQL Redis Vue Element UI。我来分别说下为什么要这样组合以及它们各自承担什么职责。后端框架用 Spring Boot核心原因是它简化了 Spring 家族的大量配置。Spring Boot 内置的自动装配机制意味着你不需要写繁琐的 XML 配置文件一个SpringBootApplication注解就能启动整个服务。这对毕设节奏来说非常友好—毕竟我们的重点是业务实现而不是花大量时间在环境配置上。持久层框架方面我建议用 MyBatis-Plus 而不是原生 MyBatis。MyBatis-Plus 提供BaseMapper接口像selectById、selectList、insert这些常规操作直接继承就能用能大幅减少重复的 SQL 编写。但是需要注意不要因为有了 MyBatis-Plus 就完全放弃手写 SQL像多表关联查询比如“职位表 join 企业表 join 投递表”还是需要手写 XML 映射这部分也是论文里“复杂查询优化”可以展示的内容。Redis 在系统里的定位是缓存和会话管理。应届生招聘平台的访问特点是职位列表与某类热门职位的浏览量大但数据变更频率低非常适合缓存到 Redis 中。另外图片验证码的存储、高频访问的分页数据缓存都可以由 Redis 承担。这样设计之后论文里就能写“基于缓存机制优化系统访问性能”的具体实践而不是空谈性能。2.2 数据库设计从ER模型到建表细节数据库设计是整个系统的命门。很多同学一上来就建表结果建到一半发现外键关系对不上或者字段冗余严重。我这里把核心表结构列出来大家可以对照自己的系统裁剪。第一张表是t_user用户表这是所有角色的底座。设计上我建议用role字段区分三种身份student/company/admin而不是拆成三张表分别存学生、企业和管理员。原因在于三种角色在登录认证和基础信息上有高度共性拆表会导致每次登录都要判断走哪张表增加冗余逻辑。但需要注意的是学生的扩展信息学号、毕业年份、学历、专业和企业扩展信息公司名称、统一社会信用代码、公司简介差异很大所以还需要关联独立的扩展表。以学生用户表为例合理的结构包含id、username、password、email、phone、role、status是否锁定、create_time等基础字段。扩展的信息可以放在t_student_info表关联user_id字段包括real_name、student_no、school、major、education、graduation_year等。这样既保证了用户认证的通用性又保留了角色差异化数据的空间。第二张核心表是t_job职位表它承载了系统里最关键的业务数据。字段至少包括id、company_id关联企业、job_name、job_type岗位分类、salary_min、salary_max、city、job_description职位描述、requirement任职要求、publish_status草稿/待审核/已发布/已下架、view_count浏览量、create_time、update_time。这个publish_status字段非常重要它配合管理端的审核功能构成了完整的职位生命周期管理流程。第三张表是t_resume简历表建议采用“表单式简历为主附件上传为辅”的设计思路。表单字段包括user_id、real_name、phone、email、education、work_experience、project_experience、skill_tags等同时提供一个attachment_url字段存 PDF/Word 版本简历的路径。这样既方便学生在系统里快速投递结构化简历也照顾到企业查看原始简历的需求。第四张表t_delivery投递记录表负责整个投递行为的状态流转。关键字段有id、student_id、job_id、company_id、status、create_time、update_time。status字段建议用整型数字枚举0表示待处理、1表示已被查看、2表示已通过初筛、3表示已发面试邀请、4表示不合适。这样学生端和企业端都可以通过状态码轻松筛选投递记录界面上用 Tag 显示不同颜色。剩下的辅助表还包括t_collection职位收藏表、t_job_category职位分类表、t_company企业信息表、t_audit审核记录表等。设计表的整体原则是能通过字段区分的不要拆表能用逻辑删除的不要物理删除能建联合索引的尽量建联合索引比如投递表的student_id job_id联合索引。2.3 前后端分离与项目目录规划毕业生信息招聘平台这种毕设规模工程的规范化程度直接决定了后期开发效率和代码可读性。做过实际项目的同学都清楚最痛苦的不是写功能而是功能写完想改的时候找不到代码在哪。所以项目目录从一开始就要规划好。一个后端工程的标准结构大致是src/main/java/com/example/recruit/ ├── config/ // 配置类拦截器、跨域、Redis序列化等 ├── controller/ // 控制层接收前端请求 ├── service/ // 业务层接口定义 实现类 │ └── impl/ ├── mapper/ // MyBatis数据访问层 ├── entity/ // 数据库实体类 ├── vo/ // 视图对象封装响应给前端的数据 ├── dto/ // 数据传输对象接收前端请求参数 ├── common/ // 通用工具统一返回结果、异常处理、分页对象 └── RecruitApplication.javavo和dto这两个包非常容易被人忽略但对毕设论文而言它们恰恰是体现代码规范性的亮点。比如学生在前端提交职位搜索表单时可能带有keyword、city、salaryRange等多个参数用一个JobSearchDTO去接收就比散装参数上浏览器传参干净得多。而在响应端你也不需要把整个t_company表的所有字段暴露给前端用一个CompanyVO只返回需要的字段即可。前端工程使用 Vue CLI 或 Vite 搭建目录上按views页面组件、components通用组件、router路由配置、api接口请求封装、storeVuex/Pinia状态管理、utils工具函数等模块划分。api目录建议按业务模块拆文件比如user.js、job.js、resume.js、admin.js每个文件统一封装对应模块的 axios 请求方法。这样前后端接口一旦约定好前端开发完全就是填文件调函数的事情。3. 核心模块实现从登录鉴权到数据统计3.1 登录认证与JWT令牌机制毕业生信息招聘平台里有三种角色所以登录认证的核心是登录接口必须能识别用户角色并在后续请求中持续保持权限范围。实现思路是这样的用户输入账号密码后后端通过BCryptPasswordEncoder对密码进行校验——数据库里存的是 BCrypt 加密后的密文而不是明文这是基本安全底线。校验成功后生成一个 JWTJSON Web Token令牌令牌中包含userId、username、role三个关键信息并以签名保证不可篡改。之后前端每次请求都在请求头加上Authorization: Bearer token后端通过拦截器解析令牌、获取当前用户身份。这里要特别强调的是 Redis 与 Token 的配合。我在实际项目中习惯于把 JWT 的过期时间设置得较短比如2小时同时在 Redis 中维护一个login:token:userId的键值为当前有效 token。一旦用户退出登录或管理员强制下线直接删除 Redis 中对应的键就能让 token 立即失效。这个机制对比单纯的 JWT 有一个明显的优势JWT 本身是无法撤销的如果不引入 Redis你很难做到“服务端主动让一个已登录用户下线”。在权限控制层面先做一个实现HandlerInterceptor接口的AuthInterceptor在preHandle方法中解析 token、校验角色。然后通过注册类将该拦截器加入到 WebMvcConfigurer 中并按照接口路径前缀配置白名单。比如/api/auth/login、/api/auth/register以及/api/job/**查看职位公开接口放行而/api/admin/**只允许roleadmin的令牌访问。这样系统的安全边界就清楚了。3.2 职位发布与检索模块的实现细节职位发布与检索是招聘平台的核心业务也是最容易出 bug 的地方。先看企业端发布职位的流程企业用户在前端表单填入职位信息点击提交后后端JobService首先校验企业资质是否完整企业名称、统一社会信用代码等是否已填写然后构造Job实体将publish_status置为1待审核插入数据库。管理员审核通过后状态变为2已发布此时该职位才能被学生端检索到。职位检索模块需要实现多条件组合查询。这里我用 MyBatis-Plus 的LambdaQueryWrapper来实现动态条件拼接LambdaQueryWrapperJob wrapper new LambdaQueryWrapper(); wrapper.eq(Job::getPublishStatus, 2); if (StringUtils.hasText(searchDTO.getKeyword())) { wrapper.and(w - w.like(Job::getJobName, searchDTO.getKeyword()) .or().like(Job::getJobDescription, searchDTO.getKeyword())); } if (StringUtils.hasText(searchDTO.getCity())) { wrapper.eq(Job::getCity, searchDTO.getCity()); } if (searchDTO.getMinSalary() ! null) { wrapper.ge(Job::getSalaryMin, searchDTO.getMinSalary()); } if (searchDTO.getMaxSalary() ! null) { wrapper.le(Job::getSalaryMax, searchDTO.getMaxSalary()); } wrapper.orderByDesc(Job::getCreateTime);这段代码的中心思想就是有参数才拼接条件避免了多条件查询时常见的if-else多层嵌套地狱。检索结果使用分页插件PageHelper或 MyBatis-Plus 内置的分页功能返回统一的分页对象总条数、当前页数据、总页数等前端即可轻松渲染长列表。另外一个细节值得在论文里写热门职位的列表数据可以设置 Redis 缓存。缓存 key 形如hotJob:list:0:10第0页每页10条缓存失效时间设为5分钟。因为职位信息的更新频率较低而列表浏览频率很高缓存命中后能明显降低数据库的压力。需要留意的是企业端一旦修改了职位信息必须主动删除对应的缓存 key保证数据一致性。3.3 简历管理与投递状态流转逻辑学生端的简历填写是整个系统中“面向学生的核心功能”。我的建议是简历表单做成多区块分段编辑模式比如“基本信息”“教育经历”“项目经历”“技能标签”这几个 Tab。后端提供保存草稿和提交完整版两个接口。在用户投递职位时系统校验简历完整度——比如是否有联系方式、是否有教育经历、是否有项目描述若缺失则提示学生完善后方可投递。投递操作本身是典型的“先校验后写记录再更新计数”流程Transactional public Result? deliver(DeliverDTO dto) { Job job jobMapper.selectById(dto.getJobId()); if (job null || job.getPublishStatus() ! 2) { return Result.error(职位不存在或已下架); } // 防止重复投递 Long count deliveryMapper.selectCount( new LambdaQueryWrapperDelivery() .eq(Delivery::getStudentId, dto.getStudentId()) .eq(Delivery::getJobId, dto.getJobId())); if (count 0) { return Result.error(您已投递过该职位请勿重复投递); } Delivery delivery new Delivery(); delivery.setStudentId(dto.getStudentId()); delivery.setJobId(dto.getJobId()); delivery.setCompanyId(job.getCompanyId()); delivery.setStatus(0); deliveryMapper.insert(delivery); // 职位浏览量/投递量1 jobMapper.increaseApplyCount(dto.getJobId()); return Result.success(); }注意这里Transactional注解标明了事务边界。一旦后续代码出现异常会触发事务回滚不会出现“投递记录写入成功但职位投递量没加”的数据不一致问题。这个是论文写“数据一致性保证”的直接素材也是答辩时老师爱问的一个点。企业端查看简历列表时同样用delivery表和resume表做关联查询。企业每查看一条简历建议将对应delivery.status从0更新为1已被查看这样学生在端上看到的投递进度就会变成“企业已查看待筛选”信息透明度提升了不少。3.4 管理员审核模块与数据统计报表管理员模块的核心价值是平台治理它让系统不再是直连的“学生—企业”双边市场而是有监督和审核机制的可管可控平台。企业注册审核和企业发布职位审核我在设计上统一走一个t_audit审核日志表。管理员登录后看到待办列表点进详情查看企业资质图片或职位描述选择通过/驳回并填写驳回原因。审核结果通过一个定时机制或实时接口更新到对应业务表中。这套流程在论文中对应“业务流程再造”或者“闭环管理设计”也是系统特色里可以写的一笔很多同类毕设只是做了简单的 CRUD但它不是它有完整的审核链。数据统计报表使用 ECharts 在前端做可视化图表展示。后端提供四个统计接口近12个月学生注册量趋势按月份分组统计t_user表的创建时间职位发布量 Top 5 企业排行t_job按company_id分组统计各岗位类别投递占比联表t_job_category与t_delivery网站数据总览总学生数、总企业数、总职位数、总投递数这些统计接口需要注意 SQL 的写法效率。比如按月份分组统计可以使用 MySQL 的DATE_FORMAT(create_time, %Y-%m)函数格式化日期再配合GROUP BY分组。不要傻乎乎地在 Java 里把所有数据查出来再遍历算时间又慢又难看。写 SQL 时加个EXPLAIN观察执行计划确保统计查询走了索引。4. 毕业论文、PPT与演示视频的打磨经验4.1 论文各章节该怎么布局才不容易被挑刺毕业论文本质上是对你整个毕业设计工作的书面呈现所以它的章节顺序和系统开发流程是一一对应的。很多同学写论文喜欢从网上找个模板直接往上套内容这种做法最大的问题是内在逻辑断裂。我的建议是严格按照下面的结构来第一章 绪论写项目背景、研究意义、国内外招聘平台发展现状综述。注意这部分不要长篇大论堆概念重点突出“针对普通高校毕业生的招聘管理与数据服务存在哪些不足”从而引出本系统的必要性。第二章 相关技术介绍逐项说明 Spring Boot、MyBatis、MySQL、Redis、Vue.js 等技术的核心特点和选型理由。在这一章里加入“技术选型对比表”是非常加分的设计——比如用表格对比 Spring Boot 与 SSH/SSM 在自动化配置、开发效率、生态支持方面的差异。第三章 系统需求分析画用例图、功能模块图、业务流程图。用例图建议用 PlantUML 或者 Draw.io 来画尽量规范非功能需求部分包括系统安全性、可靠性、易用性、可维护性每一小点要有对应设计支撑。第四章 系统设计重点是架构图、总体功能模块设计、数据库ER图和数据表设计说明。表结构描述要用规范的表格列出字段名、类型、约束和说明不要截图数据库可视化工具的界面。第五章 系统实现分角色展示核心功能的实现界面和关键代码。注意这里展示的代码一定要是真实项目代码的精简版并加上注释。页面截图要处理干净不要留浏览器的书签栏或者其他个人信息。第六章 系统测试写测试方法和测试用例结果。分别列出功能测试用例表、性能测试结果如接口响应时间压缩前后的比较、兼容性测试说明。论文里的图表统一编号也很重要插图用“图4-1 系统总体架构图”这样的格式表格用“表4-2 用户表设计”这样的格式每一个图表在正文中必须有引用。这是高校论文格式规范的硬性要求提前对照本校规范做才能避免后期返工。4.2 PPT的展示逻辑与答辩节奏控制做答辩 PPT 的时候最容易出现的毛病就是“把论文粘贴到 PPT 上”。实际上答辩 PPT 的核心作用不是罗列细节而是在最短时间内向评委证明你做了什么、怎么做出来的、结果是什么样的。我建议 PPT 控制在 15-20 页以内按这样的节奏推进封面页题目、姓名、导师→ 目录页 → 项目背景与意义1-2 页→ 核心功能展示3-5 页每页展示一个模块的截图简述→ 系统架构与技术栈1-2 页→ 数据库设计1 页 ER 图核心表结构说明→ 创新点与难点解决2 页→ 系统测试结果1 页→ 总结与展望1 页。其中“创新点与难点解决”是答辩提分的核心页面需要重点打磨。比如你可以写“为了提升投递效率设计了基于 Redis 的职位缓存机制接口响应时间平均下降 60%”这样具体的数字远比空洞的“系统性能良好”有说服力。答辩的时候还有一个细节老师特别喜欢打断演示、追问细节。所以 PPT 上任何一张截图你自己都要提前准备好它的“背景故事”——这段代码是怎么实现的、这个状态是如何转换的、这个异常是怎么处理的。我接触过不少学生PPT 做得非常漂亮但到了提问环节就开始含糊其辞。如果时间允许建议准备一份儿“答辩自问自答清单”把老师最可能问的 10 个问题写下来逐条演练。4.3 演示视频录制别让细节毁掉整体印象演示视频是今年很多学校线上答辩或提交毕设材料的必备材料它看似只是一个“录屏”但录得好不好直接影响老师对你项目完成度的第一印象。我用过几款录屏工具这里做个简单对比参考工具适用场景注意事项OBS Studio免费、开源、画质调节灵活需要自行设置输出分辨率建议 1080pBandicam操作简单、自带鼠标特效免费版会挂水印需要激活Screen Recorder系统自带Win11/Mac 自带录制画质固定无额外调参选项录制内容建议按业务流程走三条主线第一条是学生端流程——注册登录、完善简历、搜索职位、投递简历、查看进度第二条是企业端流程——企业注册、等待审核、发布职位、查看收到的简历第三条是管理端流程——登录后台、审核企业、审核职位、查看数据统计图表。三条线正好覆盖系统的全部核心功能每一段都配合旁白讲解操作意图。录视频时有几个非常关键的经验录制前把浏览器窗口调整好不要出现重叠窗口或多余标签页。提前清理浏览器的无关书签和插件显得整洁专业。旁白的语速要平缓每做一个操作前先说出“我要做什么”然后再操作。比如“现在我以学生身份登录系统进入简历管理页面”这样录出来的视频逻辑节奏感会更强。操作过程中如果点错了不要慌张不要一错就切掉重录尽量在同一个视频片段里自然地纠正错误。万一录到一半发现出现关键问题宁可重新录制该段也不要留给后期剪辑——大多数同学没有时间精剪视频。另外演示视频的分辨率至少设置为 1920×1080视频时间控制在8-12分钟比较合适。太长显得拖沓太短则可能遗漏功能展示的完整性。视频末尾还可以放一个简单的字幕总结比如“以上就是本系统的完整演示谢谢观看”观感会专业很多。5. 开发调试中容易踩的坑与排查经验5.1 前后端分离联调过程的经典问题前后端分离模式下最常见的坑就是接口请求跨域问题。浏览器默认会拦截跨源请求所以你需要在后端配置跨域规则。做法是在后端写一个CorsConfig配置类使用CorsRegistry注册允许跨域的路径规则Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }配置好后前端 axios 里还要确保携带了withCredentials: true否则 cookie 等凭证信息不会随请求发送。我见过一个项目前端登录成功后回调里说“欢迎您”但后续所有请求都报 401起初以为是 token 没存对排查了大半天才发现是跨域配置中allowCredentials(true)跟allowedOriginPatterns(*)的兼容性问题。另一个频繁出现的坑是前端拿到的数据格式和后端返回的统一结构不一致。建议后端设计一个统一的ResultT响应类包含code、message、data三个字段。所有接口都返回这个结构不要有的接口直接返回裸对象、有的返回 Page 对象。这样前端 axios 拦截器里就可以统一处理错误提示和 token 过期跳转省去了每个页面单独写 try-catch 的麻烦。5.2 业务逻辑中的边界问题边界问题在招聘平台里非常典型。举几个我自己辅导项目时遇到过的例子第一个问题是重复投递。学生手一抖连续点了两次投递按钮系统就生成了两条投递记录。除了在接口代码里加重复性校验也就是前面的selectCount逻辑前端按钮在提交后也应该立刻置灰禁用并显示“已投递”。前后端双层防护才能万无一失。第二个问题是职位下架后已有投递记录的处理。企业将职位下架后学生端应该看不到该职位但历史投递记录依然需要保留给企业和学生查询。这就要求列表查询时使用job.publish_status关联过滤但详情页查询投递记录时不能过滤否则学生会在“我投递的职位”里看到一片空白造成困惑。解决方式是投递记录的列表接口返回job的快照信息职位名称、薪资范围即使职位已下架快照仍然能正常展示。第三个问题是时间字段的时区处理。数据库使用 MySQL 时create_time默认是数据库服务器的当前时间如果你本机服务器时区设置不对插入的时间记录可能和实际时间差8个小时。解决办法是在数据库连接 URL 中加上serverTimezoneAsia/Shanghai参数并在 JDBC 连接串里显式指定characterEncodingutf8避免中文乱码和时间错位。5.3 接口响应速度与安全性细节代码写完后我习惯对整个系统做一轮简单的性能体检。核心关注两个指标普通列表接口的响应时间应该控制在 200ms 以内、涉及复杂多表查询的接口响应时间应该控制在 1s 以内。如果发现某个接口响应特别慢优先排查两件事SQL 是否命中索引、是否因为 N1 问题导致一条记录一次查询。N1 问题在 MyBatis-Plus 里特别容易发生。比如你查出一页 10 条投递记录然后遍历每条记录去查对应职位的名称这样就是 1 次查询 10 次子查询。优化的办法是用 SQL 联表查询一次取出所需的数据或者使用 MyBatis 的collection标签进行关联映射。SQL 优化这个点我在论文里特地写了一段因为它是体现系统设计深度的有力证据。在安全层面密码必须 BCrypt 加密存储这是底线中的底线千万不要用 MD5 加一个固定盐值就完事MD5 在今天的算力下存在彩虹表碰撞风险。前端登录页面加入人机验证比较好简单图片验证码即可防止刷接口暴力破解。管理员接口一律要求 token 中roleadmin不能只靠前端路由隐藏页面来“保护”。5.4 配置与部署的经验备忘项目收尾阶段要将系统在答辩现场运行或录制视频这时环境一致性就成了最现实的痛点。建议所有依赖都固定在明确版本pom.xml或package.json里的依赖版本不要用SNAPSHOTMySQL 使用 8.0 以下或以上的版本要注意驱动差异。把整个项目的环境搭建过程数据库建库脚本、Redis 启动、后端启动命令、前端启动命令整理成一个README.md文件。这不仅是交付物的专业度体现更重要的是万一你换了电脑演示照着 README 操作几分钟就能把环境恢复起来。部署方面推荐一个低成本方案本地开发用 IDEA 启动 Spring Boot 服务 npm run serve启动前端开发服务器联调完成后将前端的 API 请求地址从http://localhost:8080改为相对路径或通过开发服务器的代理转发演示时会更加稳定。整个部署不要上云服务器——除非你有多余的时间去处理公网安全组、域名备案等额外事务否则会拖累答辩进度。我在实际带项目的过程中还有一个私藏经验每次改完代码或跑完一轮测试都用 git 提交一次。哪怕只有一个人开发Git 也相当于一个“后悔药”存档点。答辩前万一哪次改动把系统搞坏了一条git revert就能回退到之前稳定运行的版本这种安全感能让你的答辩准备从容很多。这也算除了代码本身之外毕设让你提前养成的最有价值的职业习惯了。