这个题目我记得特别清楚我当年帮过的学弟里至少有五个人拿着相似的系统来问过我怎么改。大学志愿填报系统乍一看是个挺老的毕设题目但它恰恰是 Spring Boot Vue 全家桶项目里麻雀虽小、五脏俱全的典型代表——登录权限、数据检索、复杂条件筛选、业务状态机、报表统计一个不少。给正在做选题的计算机专业同学一句实在话这类系统开发的难点从来不在功能多难写而在你对自己写出来的代码能不能讲清楚。这篇文章我就以志愿填报系统为载体把从选型到部署、从数据库设计到二次开发答辩的思路完整拆给你看。1. 这题为什么是安全牌——毕设选题定位与受众分析先把话放前面大学志愿填报系统在每年的计算机毕业设计榜单里属于经久不衰的常青树。原因很简单它足够标准——有明确的用户角色划分学生、管理员、有核心业务流分数录入、院校检索、志愿填报、录取结果、有数据关联复杂度院校—专业—分数线—招生计划之间的多表关系。对导师来说这类系统的工作量可评估、代码可验收、论文有得写对学生来说技术栈不偏门、参考资料多、遇到问题搜得到。这个项目的受众我基本可以分成三类。第一类是基础一般、想求稳的同学你们要的是把一个完整项目跑通、讲清拿个中等偏上的分数第二类是有一定基础、想冲优秀的同学你们关心的重点应该是怎么在标准功能之外加一点别人没有的东西第三类是在职考研或者转行的朋友你们更在意这个项目写到简历上能不能真正体现业务理解。三类人的侧重点完全不同后面我会分别说。有人可能会问这类系统网上不是一抓一大把吗会不会撞车我的回答是撞车不可怕可怕的是你连自己项目的业务逻辑都讲不顺。选题的新颖度在本科毕设里占的权重远没有你想象的高真正拉开差距的是你对系统设计的理解深度——能不能说清楚数据库为什么这么建、某个接口为什么这么设计、遇到并发或数据不一致问题怎么处理。这篇文章要帮你建立的正是这个层面的能力。2. 技术选型为什么是 Spring Boot Vue——选型逻辑拆解这个组合能被成千上万的毕设采用不是没有道理的。我从前后端两个方向拆开说。2.1 Spring Boot 的选择原因与版本避坑Spring Boot 的定位非常清晰让 Spring 应用开箱即用。传统的 SSM 框架Spring Spring MVC MyBatis配置繁琐光 XML 配置文件就能写上百行而 Spring Boot 通过自动配置和起步依赖把绝大部分配置都收进了 starter 里。对毕设来说这意味着你不需要去理解 Spring IoC 容器底层是怎么注册 Bean 的也能把项目跑起来——当然我强烈建议你至少搞懂Autowired、Service、RestController这几个注解背后的含义因为答辩时老师几乎必问。版本是第一个坑。很多人直接去 Spring Initializr 生成项目默认给你拉最新的 Spring Boot 3.x。但 Spring Boot 3.x 有一个关键变化它基于 Jakarta EE 9把原本的javax.servlet包换成了jakarta.servlet这导致网上大量旧教程里的代码没法直接复制。更麻烦的是Spring Boot 3.x 要求 JDK 17如果你机器上还是 JDK 8项目直接起不来。我的建议是毕设优先选 Spring Boot 2.7.x。原因有三第一网上 90% 的教程、博客、CSDN 文章都是基于 2.x 写的你遇到问题搜索时能找到直接能用的答案第二2.7 是 2.x 的最后一个大版本稳定性和生态兼容性都经过了充分验证第三它对 JDK 8 的支持非常友好而绝大多数学校的实验环境默认装的还是 JDK 8。等答辩结束、你真正工作了需要上 3.x再迁移也不迟。2.2 Vue 2、Vue 3 与 Element UI/Element Plus 的搭配Vue 的选择就更讲究了。前端框架跟后端不一样Vue 2 和 Vue 3 之间的差异不是简单的版本号升级而是底层响应式原理的重写——Vue 2 用Object.defineProperty实现响应式Vue 3 改用了 Proxy。这直接影响到你写代码的方式和踩坑的方向。我的建议是分两种情况如果你前端基础一般选 Vue 2 Element UI更稳。Element UI 是目前中文后台管理系统中生态最成熟、案例最多的 UI 组件库几乎你能想到的表单、表格、分页、弹窗场景都有现成示例。Vue 2 的文档和社区资源也最丰富遇到问题基本都能搜到答案。如果你前端有一定基础想学点新的选 Vue 3 Element Plus。Element Plus 是 Element UI 的 Vue 3 版本组件更现代TypeScript 支持也更好。但要注意Vue 3 配套的生态工具链比如 Vite、Pinia跟 Vue 2 时代Webpack、Vuex的配置方式差别很大你有额外的时间成本去适应。另一个容易忽略的是 Node.js 版本。Vue 项目在创建和构建时对 Node 版本有要求——Vue CLI 4.x 建议 Node 12Vite 5.x 需要 Node 18。如果你电脑上装的是新版本的 Node跑老项目时经常会出现依赖安装失败或者构建报错这时候我建议用 nvmNode Version Manager来管理多版本 Node哪个项目需要哪个版本就切换哪个版本。2.3 前后端分离架构的开发和联调方式前后端分离是这套技术栈的核心所在。所谓分离就是前端只负责页面渲染和用户交互后端只负责提供接口和数据两边通过 HTTP/JSON 进行通信。这带来的一个实际问题是联调阶段怎么协同我的做法是前后端各开一个本地服务——后端 Spring Boot 默认跑在8080端口前端 Vue 开发服务器跑在8081端口然后在前端配置一个代理转发把/api开头的请求转发到后端的8080。这样开发时前端不需要关心后端的真实地址上线后只需要改代理配置为同一个域名下的反向代理即可。这类配置在 Vue CLI 的vue.config.js里写devServer.proxy在 Vite 里写server.proxy都是非常固定的写法。3. 软件建模是地基——志愿填报系统的核心表结构设计这一节我建议你拿出笔记本。很多做毕设的同学最容易犯的错就是代码写了一大堆但数据库表设计得一塌糊涂——字段命名随意、缺少外键关联、没有考虑数据的一致性。在答辩时数据库设计往往是老师第一个追问的方向因为它直接体现了你对业务的理解深度。3.1 角色权限模型用户表与角色表的经典设计志愿填报系统通常分为两个角色学生和管理员。有些系统还会加一个院系管理员之类的中间角色但核心的权限模型就两套。我的建议是不要做成单表权限即直接在用户表里加一个role字段就完事而是做用户表 角色表 用户角色关联表的三表结构。这样设计的理由很朴素虽然现在系统里只有两种角色但你要考虑扩展性——比如将来要加一个教师角色来查看学生志愿情况或者加一个数据分析员来浏览填报统计数据。如果直接在用户表里加字段每次加角色都得改表结构而用关联表只需要往角色表里插入一条记录再配置权限即可。用户表sys_user的核心字段大致如下id主键自增或雪花算法生成username用户名唯一索引password密码注意一定要加密存储建议使用 BCrypt 算法real_name真实姓名phone手机号student_no学号/考生号score高考分数province生源地省份status状态启用/禁用create_time/update_time创建与更新时间这里我特别想提醒两个细节。第一password字段长度要设得足够长BCrypt 加密后是 60 个字符很多同学设成 32 或 50存数据时会莫名其妙报错第二score和province这两字段放在用户表里而不是单独建一个学生信息表是因为一个小系统里不需要把用户基础信息和业务信息拆得太碎——当然如果你有多个业务模块都要用到学生信息那可以考虑拆开这个度需要自己掌握。3.2 核心业务表院校、专业、分数线与招生计划志愿填报系统的核心业务是让学生能在海量院校和专业中进行检索、筛选和填报那么支撑这项业务的数据模型就至少要包含四张表院校表school、专业表major、院校专业关联表school_major和分数线表admission_line。院校表主要存学校的基本信息id、school_name学校名称school_code院校代码province所在省份city所在城市level办学层次本科/专科type院校类型综合类、理工类、师范类等nature办学性质公办/民办tags标签985/211/双一流等可以用逗号分隔存储也可以用单独的标签表address、website、introduction地址、官网、简介专业表相对简单核心字段是id、major_name专业名称category学科门类工学、理学、管理学等code专业代码分数线和招生计划是业务最重的两张表。我建议把招生计划和历年录取分数线合并成一张招生计划-录取分数线表enrollment_plan因为它们在业务上是一体的某年、某校、某专业招生多少人、录取最低分是多少。这样可以避免多表联查时的复杂 join。字段大致为idschool_id关联院校 IDmajor_id关联专业 IDyear年份plan_count招生计划人数min_score最低录取分avg_score平均录取分可选max_score最高录取分可选min_rank最低录取位次这个字段建议保留因为志愿填报中位次比绝对分数更有参考价值3.3 志愿表与录取状态业务状态机的落库方式最后是志愿表volunteer。这一块是很多同学容易设计得过于简单的部分——有的同学直接建一张表存学生 ID 和一堆院校 ID 的拼接字符串。这种设计在演示时看起来也能跑但经不起推敲你很难回答怎么统计每个院校被填报了多少次怎么实现同一学生不能重复填报同一院校这类问题。我的做法是设计成主从表结构志愿主表volunteer存储一次填报行为的整体信息。字段包括id、student_id、batch批次如本科一批、本科二批、status填报状态草稿/已提交、create_time、submit_time。志愿明细表volunteer_item存储这个志愿下的具体院校和专业。字段包括id、volunteer_id、school_id、major_id、order_no这个志愿的优先级顺序如第1志愿、第2志愿、is_adjusted是否服从调剂。为什么要拆成两张表因为一次志愿填报可以包含多个院校志愿每个院校志愿又可以被多个专业志愿填充这本质上是一对多的嵌套关系。主从表结构天然适配这种模型而且如果后续要增加调整志愿顺序删除某一志愿的功能操作都极其直观。录取状态则可以通过在志愿明细表上加一个admit_status字段来记录。这个字段的设计建议用数字枚举int而不是字符串保证数据的一致性和查询效率——比如0表示未录取、1表示已投档、2表示已录取、3表示已退档。这就是典型的状态机业务模型答辩时你可以顺带讲讲状态的流转规则很容易让老师觉得你有工程意识。4. 后端接口与业务实现——重点模块的代码思路与实战数据库设计好之后后端开发其实就变成了对表做增删改查 加一些业务限制。但要说清楚系统值多少分你得把其中三个核心模块的代码思路吃透登录认证、院校检索、志愿填报的业务校验。4.1 基于 JWT 的登录认证——从 Session 到 Token 的演进很多老教程教你用 Session 的机制做登录——用户登录成功后后端把用户信息存进 Session然后给前端返回一个JSESSIONID的 Cookie下次请求时带上这个 Cookie后端从 Session 里取用户信息。前后端分离后Session 机制遇到的典型问题是跨域场景下的 Cookie 携带和多端适配。所以现在的标准做法是用 JWTJSON Web Token。简单说JWT 是一个自包含的 Token 字符串由三部分组成Header声明算法、Payload存放用户信息如userId、role、Signature用密钥对前两部分签名。后端登录成功后签发这个 Token 给前端前端存在localStorage里之后每次请求都在Authorization请求头里带上后端通过拦截器校验 Token 是否合法。JWT 的好处在于服务端无状态——不需要额外存储用户会话Token 本身就是通行证。我在实际项目里通常会封装一个JwtUtil工具类提供generateToken和parseToken两个方法然后在拦截器中统一校验。这里有个非常实用的技巧拦截器里放行的白名单路径如/api/auth/login、/api/school/list要用 List 配置好否则一刷新页面就发现前端请求全被拦了后端报 401。4.2 院校检索接口——如何优雅地实现多条件组合筛选院校检索是学生端用得最多的功能它的核心逻辑是前端传过来一堆可选的筛选条件省份、办学层次、院校类型、标签、分数等后端要根据这些条件的组合动态拼接 SQL 来查询。这里有两种实现思路。第一种是用 MyBatis 的动态 SQL通过if标签来拼接查询条件第二种是用MyBatis-Plus 的QueryWrapper在代码层面构建查询条件。我建议用后者理由很简单QueryWrapper 的可读性更好代码量更少而且不容易出现 XML 里标签嵌套混乱的问题——当然如果你们学校强制要求 MyBatis 的 XML 写法那还是得练熟动态 SQL。我给你一个多条件筛选的核心思路示例简化伪代码public PageResultSchoolVO searchSchools(SchoolQueryDTO query) { LambdaQueryWrapperSchool wrapper new LambdaQueryWrapper(); // 省级筛选不传就忽略 if (StringUtils.hasText(query.getProvince())) { wrapper.eq(School::getProvince, query.getProvince()); } // 办学层次筛选 if (StringUtils.hasText(query.getLevel())) { wrapper.eq(School::getLevel, query.getLevel()); } // 标签筛选用 like 匹配逗号分隔的标签 if (StringUtils.hasText(query.getTag())) { wrapper.like(School::getTags, query.getTag()); } // 分数筛选要求招生计划表中最低录取分小于等于考生分数 // 这里需要关联子查询或两步查询 wrapper.orderByDesc(School::getCreateTime); return page(query.getPageNum(), query.getPageSize(), wrapper); }这里有一个关键点按分数筛选院校不能直接用单个学校表字段查因为是否有资格报考某个学校取决于该学校在你所在省份、对应年份的录取分数线而那张表的数据跟学校表是一对多的关系。简单高效的实现方式是先查出符合条件的学校 ID 集合再在分数线表中用IN查询匹配如果数据量较大可以适当考虑在分数线表上建联合索引school_id year province。4.3 志愿填报的业务校验——定时器和状态约束的双保险志愿填报接口是整个系统中最容易产生脏数据的环节需要同时考虑业务约束和并发场景。业务约束至少包括三个方面第一同一学生不能重复提交同一志愿需要给volunteer_item表加唯一索引第二同一批次下只能提交一个志愿主记录第三填报时必须满足分数要求不低于所填院校的录取最低分。并发场景的典型问题是假如某个学生手速极快连续点击两次提交按钮后端同时收到两个请求就可能产生两条相同内容的志愿记录。解决方案有几种最简单的做法是在提交接口里加一个事务并在查询志愿表时加上悲观锁SELECT ... FOR UPDATE更贴近实际的做法是在数据库层面加唯一索引并在插入时捕获DuplicateKeyException返回友好提示。还有一个容易被忽略的点填报的起止时间控制。系统应该有一个配置表或者配置类用来维护填报开始时间和填报结束时间提交接口在执行业务逻辑前先校验当前时间是否在窗口内。如果不在直接拒绝请求。这类时间窗口约束通常会配合定时任务学生端的页面上展示倒计时后端接口则做最终的兜底拦截。// 提交志愿时的校验逻辑顺序 public void submitVolunteer(VolunteerDTO dto) { // 1. 时间窗口校验 checkSubmitWindow(); // 2. 分数约束校验 checkScoreQualification(dto); // 3. 重复提交校验唯一索引兜底 checkDuplicateVolunteer(dto); // 4. 保存主表和明细表事务 volunteerService.saveWithItems(dto); }5. 前端核心页面与组件——真实可用且能讲出东西的实现前端这块很多同学容易走入两个极端要么只用自带模板啥代码也不写答辩时一问三不知要么过于沉迷炫酷的动画特效忽略了系统本身的业务属性。我的看法是前端部分的价值不在于视觉多惊艳而在于组件用得到位、数据交互合理、代码有设计感。5.1 基于 Vue Router 的权限路由控制志愿填报系统的前端通常包含这几个页面登录页、院校列表页、院校详情页、志愿填报页、志愿查看页、管理后台各页面。如果只是把所有路由一股脑注册进去谁都可以通过 URL 直接访问管理后台的地址这显然是不合理的。我的做法是基于路由守卫beforeEach做登录校验和角色校验。在路由配置中给每个路由增加meta字段用来标注需要的角色{ path: /admin, component: Layout, meta: { roles: [ADMIN] }, children: [ { path: school, component: SchoolManage, meta: { roles: [ADMIN] } } ] }然后在router.beforeEach这个全局前置守卫中从 Vuex/Pinia 里读取当前用户的角色信息判断是否允许进入目标路由router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (!token to.path ! /login) { next(/login); // 未登录跳登录页 } else { const role store.state.user.role; if (to.meta.roles !to.meta.roles.includes(role)) { next(/401); // 无权限跳提示页 } else { next(); } } });这段代码值得你在答辩时主动提——它很直观地体现了你对前端安全的理解即使实现上仍然需要后端接口做最终鉴权但至少你已经知道要控制路由访问。5.2 表格 分页 筛选条件联动院校列表页是整个系统里用户停留时间最长的页面。我的布局建议是顶部放筛选条件省份下拉框、办学层次单选、院校类型下拉、关键词搜索中间是表格内容区底部是分页组件。筛选条件变化或点击搜索时重新请求分页数据。这里有个细节很重要分页组件切换页码时要把当前筛选条件一起传给后端否则会出现第 2 页数据跟第 1 页筛选条件不符的混乱。所以我的习惯是把搜索条件和分页信息封装成同一个对象通过一个统一的fetchList()方法发送请求async fetchList() { const params { pageNum: this.pageNum, pageSize: this.pageSize, province: this.filters.province, level: this.filters.level, type: this.filters.type, keyword: this.filters.keyword }; const res await getSchoolList(params); this.tableData res.data.records; this.total res.data.total; }5.3 志愿填报的交互设计——一个反直觉的体验细节志愿填报页面是这个系统中交互最复杂的地方因为一个志愿主记录下面有多所院校每个院校下面还有多个专业再加上是否服从调剂的选项如果交互设计不合理用户会非常难受。我的设计思路是用卡片式列表代替复杂的多级表格。每个院校志愿可以用一张独立的卡片展示卡片内包含院校信息、多个专业选择和服从调剂开关增加志愿时动态插入新卡片。这样可以灵活处理不固定数量的志愿项也方便用户调整顺序。这里有个反直觉的体验细节供你参考添加志愿按钮的位置。很多时候我们习惯把按钮放在页面底部或右上角但在这个业务场景里用户是一路从上面往下填的如果按钮在顶部填完第 3 个志愿后想添加第 4 个就得滚回顶部去点按钮。把按钮同时放在列表底部会友好很多。这类交互细节虽然不直接参与评分但答辩时展示出来导师会觉得你是真的从用户体验角度思考过。6. 开发环境搭建与避坑实录——从创建工程到调通接口的完整路径这一节我要讲的实际踩坑最多。很多同学不是写不出代码而是代码写了但环境跑不起来或者本地跑得好好的一部署就各种崩溃。我把从零搭建这个项目的关键步骤和坑都梳理一遍。6.1 用 IDEA 创建 Spring Boot 项目打开 IDEA选择File - New - Project - Spring Initializr这里有个重点Server URL 选默认的或者国内镜像源不然下载依赖时会超时。接下来的关键配置Group一般填com.example或者你的域名倒写Artifact填项目名例如volunteer-systemJava Version选 8如果你用 Spring Boot 2.7.xDependencies选择Spring Web、MyBatis Framework、MySQL Driver、Lombok如果计划用 MyBatis-Plus不能在这里直接选需要后补依赖很多同学在这一步选了最新版的 Spring Boot比如 3.2.x然后用 JDK 8 编译直接报错。版本对应关系一定要提前确认Spring Boot 2.7.x 对应 Java 8 或 11Spring Boot 3.x 必须 Java 17。6.2 Vue 工程的创建与 npm 依赖安装前端我没有用 Vite而是讲 Vue CLI 的方式因为用的人更多。在命令行里执行npm install -g vue/cli vue create volunteer-web创建过程中会让你选择预设preset和配置选项我建议手动选择Manually select features勾上 Vue Router 和 Vuex其他默认即可。创建完成后进入项目目录cd volunteer-web npm install # 安装依赖这里最常见的坑是一个node-sass的编译报错——node-sass需要用 node-gyp 去编译原生模块如果你的 Node 版本太新比如 18编译成功率较低。解决办法是换成sassDart Sass在 package.json 里把依赖从node-sass改成sass重新安装即可。现在的 Element Plus 或 Element UI 版本对 Dart Sass 都是兼容的。6.3 前后端联调的正确姿势联调时最常见的报错是跨域CORS。前端跑在http://localhost:8081后端跑在http://localhost:8080从浏览器发送fetch请求时浏览器的同源策略会拦截跨域请求。解决跨域有三种常用方式后端加CrossOrigin注解、后端配置CorsFilter、前端开发服务器配置代理。我的做法是优先用后端配置全局 CORS因为更直观可控——生产环境中后端接口可能会被多个前端调用后端统一放行比每个前端各配代理要省事Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }还有一个让新手特别崩溃的场景前端接口通了但数据是乱码或者后端返回的 JSON 里中文变成问号。这个问题大概率不是后端代码的问题而是 MySQL 连接串里没有设置编码。在application.yml里的 JDBC URL 后追加jdbc:mysql://localhost:3306/volunteer?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiserverTimezone这个参数也很重要不设置的话高版本 MySQL 驱动会报时区错误。这两个参数是毕设项目出现频率最高的两个坑提前配好能省下半天时间。7. 部署方案与加分项扩展——从跑通到拿高分的进阶路线很多人做完项目就停下来我觉得有点可惜。如果时间允许我建议你在基础功能之上做两件事一件是给自己的系统加一个值得一提的小功能另一件是把部署和演示的流程打磨得顺畅自然。这两件事对答辩印象分的提升远比想象中大。7.1 本地打包与部署上线部署方式我推荐用前后端分离的方式分别部署后端打成 jar 包前端构建出静态文件然后用 Nginx 做反向代理。后端打包前要注意application.yml里的配置——数据库连接应该从 localhost 改为你的服务器地址或者用环境变量注入然后执行mvn clean package -DskipTests构建成功后在target目录下会生成一个volunteer-system-0.0.1-SNAPSHOT.jar在服务器上运行java -jar volunteer-system-0.0.1-SNAPSHOT.jar前端构建npm run build构建成功后dist目录里的文件就是纯静态文件把它们整体放到 Nginx 的html目录下然后在 Nginx 配置里把/api开头的请求反向代理到后端服务的8080端口server { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }用 Nginx 代理的好处是前后端共享同一个域名和端口不存在跨域问题也最贴近真实的生产部署形态。7.2 加分项一Excel 批量导入院校数据这是一个性价比极高的扩展。手写十几条院校数据没问题但要给系统填充几十上百所真实院校的模拟数据手工录入不现实。你可以用 Easy Excel阿里的开源库实现一个管理员专用的Excel 导入接口管理员下载模板、填好数据、上传后由后端批量解析并写入数据库。这个功能的代码量很小但它在答辩现场非常出效果——你当着老师的面导入一个包含 50 所院校的 Excel 表格系统瞬间全部展示出来冲击力远超你在库里手插十条数据的演示。而且 Easy Excel 有完善的文档按文档写不会出大错。7.3 加分项二基于分数和位次的冲稳保推荐逻辑志愿填报系统的业务核心是帮用户选出合适的学校。你可以在基础检索之外加一个智能推荐模块用户输入自己的分数和省份系统通过当前年份的招生计划和历年录取数据计算出三类结果——冲一冲录取概率 30%-60%、稳一稳60%-85%、保一保85% 以上。计算逻辑可以做得非常朴素取目标院校近三年的最低录取位次取用户当前位次的折中百分位结合一个简单的权重大小给出概率估计。这个模块在技术上并不难就是多表查询和简单算术但它的业务价值叙事非常好——你可以在论文里写法系统从数据驱动的角度为考生提供填报参考这句话在导师那儿是非常加分的。7.4 加分项三基于 Redis 的缓存与接口性能优化如果毕设系统中涉及热点数据查询比如院校列表是高频访问的可以使用 Redis 缓存院校列表和分数线数据。当数据变更时主动删除缓存当缓存不存在时再查数据库回填。这个功能的工程价值比院校检索更值得讲——你可以在答辩时淡定地说因为考虑到多用户同时查询会造成数据库压力我引入了 Redis 做热点数据缓存有效降低了数据库查询的 QPS。这就把一个普通的增删改查项目拔高到了具备高并发优化意识的层次。8. 写在最后——关于自己做项目的一点实在建议做完这个项目我最大的三条教训想直接分享给你。第一代码可以抄但要抄得明白。你能把一个开源项目跑起来并不代表你理解它。每一个接口、每一张表、每一个组件都值得你问一句它为什么这么设计。这个问题问多了你才会真正形成自己的判断力。第二日志和异常处理不要省。我刚写这个系统时接口一报错就靠前端控制台猜后来老老实实后端加了RestControllerAdvice全局异常处理器并在关键方法里打了日志排错效率提升了一大截。这种工程习惯在毕设代码里非常显眼也是很多同学容易欠缺的部分。第三演示脚本一定要提前演练。很多同学功能做完了但演示时卡壳——数据库连不上、浏览器缓存了旧页面、点添加志愿时表单校验不通过……这些问题十有八九是环境问题而不是代码问题。我建议你在答辩前完整走一遍演示流程从登录开始到搜索院校、添加志愿、提交、管理员审核每一步都验证一遍再把数据库重启、后端重启、前端重新构建这几个操作各做一次确保换台电脑也能正常演示。好了关于基于 Spring Boot Vue 的大学志愿填报系统我踩过的坑、绕过的弯、总结出来的经验基本都在这了。剩下的事就得你亲手去做了——当你能把整个项目从头到尾跑通并且能对每个设计决策都讲出为什么的时候你就不会再担心答辩而是会期待答辩。祝顺利。
