尧图网页设计 
做Java Web方向毕业设计的同学应该都有同感SpringBootVue早就成了标配组合但真正把项目做出“业务深度”的其实不多。今天拆一个我经手过的完整毕设项目——基于SpringBootVue的在线英语阅读分级平台包含前后端源码、SQL脚本和接口文档。它不是一个堆功能的CRUD项目而是有一条完整的业务闭环用户先做分级测评系统根据等级推荐匹配难度的英语文章阅读过程中可以划词查询、加入生词本读完做练习题系统根据正确率再动态调整推荐等级。这套逻辑做透了答辩评委基本挑不出大毛病。文章会从数据库设计讲到接口实现、前端排版、部署踩坑最后附上答辩高频问题清单。不管你打算直接参考还是二次开发这篇都能帮你省掉大量查资料的功夫。1. 在线英语阅读分级平台该怎么拆先把技术选型和业务闭环理清楚做毕设最忌讳一上来就写代码先把项目“画像”想清楚后面每一步都是顺的。这个项目的核心不是“英语阅读”也不是“文章展示”而是“分级”这两个字——怎么判断用户的英语水平怎么给文章定难度级别怎么把合适的内容推给合适的人。这三个问题才是抽答辩时最能体现你思考深度的东西。1.1 分级平台到底在解决什么问题市面上的英语学习产品很多但多数是“所有用户看同一批内容”要么太简单让人失去兴趣要么太难直接劝退。分级阅读的思路是参考蓝思值Lexile和CEFR欧洲语言共同参考框架给文章打上难度标签给用户打上水平标签然后做匹配。体现在这个项目里就是新用户注册后先做一套分级测评系统通过答题正确率和题目难度系数算出初始等级文章表里每条内容都有level字段范围1-6也可细分到A1-C2共12档但毕设6档足够展示逻辑首页不再是“最新文章列表”而是“根据我的等级推荐的文章列表”等级越高看到的文章难度越大读完后有阅读理解题系统记录成绩并在下次推荐时微调等级权重。说白了业务的“心脏”是一个简单但说得通的推荐逻辑。评委看重的不是你用了多高深的算法而是你有没有“根据数据驱动内容展示”的意识——这比堆十个功能模块都有说服力。1.2 技术选型为什么锁定SpringBootVue这套组合后端用SpringBoot 2.x MyBatis-Plus MySQL 8.0前端用Vue 2或Vue 3皆可 Element UI Axios再加一个Vue Router做页面路由这个组合我愿称之为“毕设黄金阵容”。选它有几个现实原因。第一SpringBoot把SSM时代的XML配置全部干掉自动配置机制让项目能在十分钟内从零跑起来这对时间紧张的毕设来说太重要了。第二MyBatis-Plus提供了单表CRUD的现成方法例如selectById、selectPage这类封装省去的代码量足够让你把精力花在业务设计上。第三Vue的组件化开发模式跟后台管理页面的契合度特别高——一个侧边栏组件、一个表格组件、一个弹窗组件写完能复用整个项目工作量比JSP时代砍半不止。第四网上资料最多、遇到bug最好查光是“SpringBoot跨域怎么解决”这种问题就有几百篇现成答案选冷门框架等于给自己挖坑。至于HTML和CSS在这个项目里分量一点都不轻。Vue负责的是页面结构和数据绑定但阅读页面的排版体验——字号、行间距、背景色、生词高亮这些全得靠CSS一笔一笔调。我见过太多只写了“功能能用”就交差的项目首页样式惨不忍睹答辩时老师打开页面就皱眉头。这个项目的阅读页需要细致打磨后面第4节我会具体讲怎么调。1.3 模块拆分用户端和管理端各做什么项目分成两个大模块按角色拆功能别做成一个大杂烩。用户端核心功能注册登录用户名邮箱密码MD5加盐存储别用明文这属于安全基础分。分级测评10道单选题题目自带难度系数提交后自动算分定级。文章阅读分级推荐列表、文章详情页、阅读计时、划词翻译。阅读练习每篇文章配套3-5道阅读理解题做完判分计入记录。生词本阅读中点击单词加入生词本列表展示可标记“已掌握”。个人中心我的等级、阅读统计篇数、时长、正确率、历史记录。管理端核心功能文章管理增删改查、设置level标签和tag题材分类、上下架。题目管理维护测评题库和阅读练习题支持批量导入。用户管理查看用户列表、等级分布、重置密码。数据概览用图表展示注册人数、各等级人数占比、文章阅读排行。这11个功能基本覆盖了一个完整产品的最小闭环不会显得单薄也不会因为过度膨胀导致无法按期交付。2. 数据库设计5张核心表撑起整个分级业务表结构设计决定了一个项目后面写代码是丝滑还是痛苦。这个项目的表不用多但每张表的字段都要能回答一个核心问题。我直接分享我最终落地的方案。2.1 用户与测评user表和level_test_record表用户表是基础注意几点密码字段长度要设计成255因为用了MD5加盐之后长度会超过32level字段允许为空为空表示还没测评前端要用这个状态判断“是否要引导用户去测评”。CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 用户ID, username varchar(50) NOT NULL COMMENT 用户名, password varchar(255) NOT NULL COMMENT 密码加盐MD5, email varchar(100) DEFAULT NULL COMMENT 邮箱, level tinyint(4) DEFAULT NULL COMMENT 测评等级1-6NULL未测评, created_at datetime DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY idx_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;测评记录表的用途是“留痕”——用户每次测评的结果都要存下来这样在后端根据答题记录动态调整等级时有据可查。CREATE TABLE level_test_record ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, score int(11) NOT NULL COMMENT 测评得分100制, result_level tinyint(4) NOT NULL COMMENT 测评结果等级1-6, detail_json text COMMENT 答题明细每题得分JSON格式, test_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 测评时间, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT分级测评记录表;这里有个细节detail_json字段很多人不会加但它有价值。第一后台可以分析用户错的题集中在哪个难度区间进而更精确地定级第二答辩时老师如果问“你的定级依据是什么”你直接把答题明细JSON调出来展示比凭空解释有力得多。2.2 文章与题库article表、question_bank表和reading_record表文章表是这个项目内容侧的基石。content字段用MEDIUMTEXT存储的是HTML片段因为前端阅读页需要用富文本方式渲染你不能让用户看到的是一大坨换行符都被吃掉的纯文本。word_count字段可以在读入时用后端统计好省得前端再算。CREATE TABLE article ( id bigint(20) NOT NULL AUTO_INCREMENT, title varchar(200) NOT NULL COMMENT 文章标题, content MEDIUMTEXT NOT NULL COMMENT 正文HTML格式, summary varchar(500) DEFAULT NULL COMMENT 摘要/导语, level tinyint(4) NOT NULL COMMENT 难度等级1-6, tag varchar(50) DEFAULT NULL COMMENT 题材标签科技/文化/故事/科普..., word_count int(11) DEFAULT 0 COMMENT 单词数, view_count int(11) DEFAULT 0 COMMENT 阅读次数, status tinyint(4) DEFAULT 1 COMMENT 1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_level_tag (level, tag) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT文章表;联合索引idx_level_tag很关键。推荐列表的SQL核心条件是where level? and tag?这个联合索引能让查询速度有质的提升数据量超过几千条之后区别明显。这是我在优化阶段加上的不是初始设计就有。题库表存测评题和阅读题用type字段区分题目用途1代表分级测评题2代表阅读练习题。每道题至少四个选项correct_index存正确答案序号difficulty系数从1到5递增。CREATE TABLE question_bank ( id bigint(20) NOT NULL AUTO_INCREMENT, type tinyint(4) NOT NULL COMMENT 1-测评题 2-阅读题, article_id bigint(20) DEFAULT NULL COMMENT 关联文章ID阅读题用, difficulty tinyint(4) DEFAULT 3 COMMENT 难度系数1-5, question varchar(500) NOT NULL COMMENT 题干, option_a varchar(255) DEFAULT NULL, option_b varchar(255) DEFAULT NULL, option_c varchar(255) DEFAULT NULL, option_d varchar(255) DEFAULT NULL, correct_index tinyint(4) NOT NULL COMMENT 正确选项0-A 1-B 2-C 3-D, PRIMARY KEY (id), KEY idx_type (type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT题库表;阅读记录表记录用户和文章的交互。核心字段是last_position存用户读到第几分钟或第几个字符位置用于“继续阅读”功能。reading_status存状态0未完成、1已完成阅读、2练习题已通过。这个表是数据统计报表的数据来源也能支撑“我的阅读历史”页面。CREATE TABLE reading_record ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL, article_id bigint(20) NOT NULL, last_position int(11) DEFAULT 0 COMMENT 阅读进度字符位置, reading_status tinyint(4) DEFAULT 0 COMMENT 0未完成 1已完成 2练习题通过, exercise_score int(11) DEFAULT NULL COMMENT 练习题得分, read_duration int(11) DEFAULT 0 COMMENT 累计阅读时长秒, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY idx_user_article (user_id, article_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT阅读记录表;注意联合唯一索引idx_user_article它保证了“一个用户对同一篇文章只有一条记录”业务上用insert...on duplicate key update的写法去更新进度而不是每次阅读都插一条新记录。这个问题在毕设里非常经典很多人做成了一篇文章读五次生成五条记录。2.3 SQL脚本编写导入顺畅是基本素养很多同学交付SQL脚本时就是一句“直接导入即可”结果别人一导入就报错。好的脚本必须在最前面加三个东西DROP DATABASE IF EXISTS、CREATE DATABASE、USE DATABASE。这样别人不管在什么环境下执行都能一遍过。字符集统一用utf8mb4因为要存HTML片段里面可能有特殊符号utf8mb4兼容性最好。还要准备足够的种子数据——用户2个、文章10篇覆盖6个等级、测评题10道、阅读练习题20道让演示时页面不空。demo用户账号密码在脚本注释里写明方便老师一键登录查看效果。3. 后端接口设计从统一返回结构到分级推荐逻辑接口设计直接决定前端联调时的心情。我的习惯是先定统一返回格式再写业务接口最后补全局异常处理。顺序反了就容易出现每个接口返回格式不一致、前端解析写好几套逻辑的悲剧。3.1 统一返回结构一个Result类解决前后端协议问题前后端交互最稳妥的做法是定义一个泛型Result类所有接口返回对象都是这个结构的实例Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端Axios统一拦截只有code为200时才放行数据否则直接弹出message提示。这样登录过期、参数错误这类问题不需要每个页面单独处理一次封装全局生效。3.2 全局异常处理把报错信息变成人话SpringBoot里可以用RestControllerAdvice加ExceptionHandler做全局异常捕获。数据库主键冲突转成“用户名已存在”空指针记录日志同时返回“系统繁忙”。这一步属于答辩加分项因为很多同学做到这一步就交差了而你会说“我的项目里有全局异常处理保证任何异常前端都能收到可读的提示”评委一听就知道你有工程意识。3.3 核心推荐逻辑别整协同过滤先做好内容匹配推荐算法是这个项目的重头戏。如果你的简历还没到“机器学习”这个高度千万别硬说“我用了协同过滤”——评委追问你Spark和用户矩阵怎么构建你很容易卡壳。务实的做法是“基于等级标签的匹配推荐”逻辑清晰、代码量少、演示效果好。我的实现分三步第一步读取用户当前等级。如果用户没测过分默认给3级并页面上引导去测评。第二步从文章表拉取当前等级±1范围内的文章。比如用户是3级就拉level在2到4之间的文章这个缓冲区间让推荐结果有梯度又不至于太难。第三步按标签偏好加权排序。用户阅读历史中如果科普类最多就在候选文章里把tag科普的文章排前面。核心Service代码如下Override public ListArticleVO recommendArticles(Long userId, int limit) { // 1. 获取用户信息没测评默认等级3 User user userMapper.selectById(userId); int level (user.getLevel() null) ? 3 : user.getLevel(); // 2. 候选范围等级±1 LambdaQueryWrapperArticle wrapper new LambdaQueryWrapper(); wrapper.between(Article::getLevel, level - 1, level 1) .eq(Article::getStatus, 1); ListArticle candidates articleMapper.selectList(wrapper); // 3. 统计用户历史阅读中最偏好的两个标签 ListString favoriteTags readingRecordMapper.selectFavoriteTags(userId, 2); if (favoriteTags.isEmpty()) { // 无历史记录直接按浏览量排序返回 return candidates.stream() .sorted((a, b) - b.getViewCount() - a.getViewCount()) .limit(limit) .map(ArticleVO::new) .collect(Collectors.toList()); } // 4. 偏好标签加权其余保持原有顺序 candidates.sort((a, b) - { int scoreB favoriteTags.contains(b.getTag()) ? 1 : 0; int scoreA favoriteTags.contains(a.getTag()) ? 1 : 0; if (scoreB ! scoreA) { return scoreB - scoreA; } return b.getViewCount() - a.getViewCount(); }); return candidates.stream().limit(limit).map(ArticleVO::new).collect(Collectors.toList()); }这个方法解决的问题是“冷启动”和“可解释性”。冷启动在于没有历史数据时按浏览量兜底可解释性在于“因为我常看科普类所以优先给你推科普”这个理由在答辩现场一说评委立刻秒懂。3.4 测评接口得分计算与等级映射公式测评接口POST /api/test/submit接收参数是用户答案数组。设计上我建议在Service层做四件事遍历答案比对correct_index统计正确数对每道题按难度置信度加权。难度系数是1-5答对难度5的题权重是答对难度1题的2.5倍这样得出来的总分能体现“不是只会简单的题”映射等级。简单做法60分以下定1级60-70定2级70-80定3级80-90定4级90以上根据题目难度再细分到5/6级更新user表的level字段同时插入一条测评记录。等级映射的区间我调了好几轮。最初直接按分数砍段结果发现很多用户测出来全是3级缺乏区分度。后来加了“难度权重”后区分度明显好了因为高分基本上是靠难题拉上来的而不是靠简单题堆出来的。3.5 接口文档不要临时写用Apifox一套维护接口文档不要写Word版效率太低而且改动不同步。用Apifox在线协作把每个接口的URL、请求参数、返回值示例维护进去生成在线分享链接放进README。前端联调时照着文档写Axios几乎不用来来回回找你问“这个接口返回什么字段”。这个习惯还有一个隐藏好处答辩的时候老师如果问“你项目里文档齐全吗”你把Apifox的接口清单页面直接展示出来上面十几条接口记录整整齐齐这比CTRLC搜出来的项目要有说服力得多。4. 前端实现阅读排版是这个项目的门面我在前面说过这个项目的前端不是普通后台管理页面能糊弄过去的。用户打开网站第一眼看的是首页然后点进文章阅读——如果阅读页的排版让人不舒服整个产品的品质感就垮了。这里把CSS的功力全部拿出来。4.1 Vue页面结构与路由设计views目录建议这样组织功能边界清晰src/views ├── home/ 首页推荐列表 ├── article/ 文章详情阅读页 ├── test/ 分级测评页 ├── vocab/ 生词本 ├── profile/ 个人中心 ├── admin/ 管理后台 │ ├── article/ 文章管理 │ ├── question/ 题目管理 │ └── user/ 用户管理路由守卫是本项目前端的核心逻辑之一。main.js或router/index.js里加beforeEach钩子如果访问的文章列表页和测评页需要登录先检查localStorage有没有token没有就重定向到登录页。这个逻辑简单但必加否则未登录用户直接访问页面后端接口虽然会拦截但前端报错提示很难看。4.2 阅读页排版一行CSS都别将就文章阅读页是整个HTMLCSS最能出彩的地方。我调试了很久最终沉淀了一套参数直接分享你参考。字体方面body字号不能小于16px阅读类页面建议18px行高1.8以上。英文阅读用衬线字体更舒服我选了Georgia作为正文字体栈这是欧美纸质媒体常用的字体后台管理页面才用无衬线字体。太长的行会让视线换行困难所以内容区最大宽度控制在680px左右左右留白充足类似报纸的栏宽。段落间距margin-bottom设1.5em。生词高亮用mark标签背景色方案默认浅黄色背景鼠标悬浮时加深并弹出释义tooltip。CSS实现不复杂.mark-word { background: #fff7d6; border-radius: 3px; padding: 0 4px; cursor: pointer; position: relative; transition: background 0.2s; } .mark-word:hover { background: #ffec9e; } .word-tip { display: none; position: absolute; bottom: 140%; left: 50%; transform: translateX(-50%); background: #333; color: #fff; padding: 8px 12px; border-radius: 6px; white-space: nowrap; font-size: 14px; z-index: 99; } .mark-word:hover .word-tip { display: block; }这里有个细节单词释义的tooltip是绝对定位的如果文章容器设置了overflow:hidden提示框会被裁掉。我踩过这个坑阅读容器不要设overflow:hidden有需要的话改用min-height约束布局。夜间模式是这个项目的一个亮点功能花不了多少代码但观感提升巨大。思路是在html上切换一个data-theme属性CSS变量控制配色:root { --bg-color: #ffffff; --text-color: #333333; } html[data-themedark] { --bg-color: #1e1e1e; --text-color: #cccccc; }阅读页body直接用var(--bg-color)当背景色切换只需要一段JavaScript改变data-theme属性的值。演示时一键切换深色模式老师一般都会觉得“这个项目做得很细”成本不过三五十行代码。4.3 划词取词与生词本交互用户阅读时想查单词最顺手的交互是“划词悬浮释义”。实现思路监听mouseup事件用window.getSelection()获取选中的文本判断是英文单词后调后端词典接口把释义放进浮层。生词本按钮做成浮层里的一个小加号点了调POST /api/vocab/add接口把当前单词收进生词本。前端的关键代码是mouseup事件处理document.addEventListener(mouseup, (e) { const selection window.getSelection(); const text selection.toString().trim(); if (!text) return; // 只处理纯英文单词 if (!/^[a-zA-Z]$/.test(text)) return; // 计算弹窗位置基于选区边界 const rect selection.getRangeAt(0).getBoundingClientRect(); this.showTip(text, rect); });这里要注意事件监听加在document上而不是文章内容容器上。因为用户可能在文章末尾的练习题区域也选中单词全局监听才能覆盖所有情况。同时要防止弹窗里的文字被再次选中触发死循环弹窗本身不要用可选中文本。生词本页面用虚拟滚动渲染列表单词多的时候性能不崩。我实测过加入200个生词后普通v-for渲染还是有微微卡顿换成简单虚拟滚动后流畅多了。这个优化点写进项目文档里也是一个加分项。5. 本地运行全流程从SQL导入到前后端联调这个项目交付给别人或者演示时能不能一键跑起来决定了可信度。我把从零到运行的完整流程记录出来你照着这个顺序操作基本不出错。5.1 环境准备清单JDK 1.8或11不要用17以上部分依赖不兼容Node.js 14或16版本太高可能导致node-sass这类库编译失败建议16稳妥MySQL 5.7或8.0注意8.0的驱动和时区配置略有不同Maven 3.6IDEA自带的也可以用可选Redis但毕设不强制如果用的话注意配置RedisTemplate的序列化方式。流程是先用IDEA打开后端文件夹等待Maven依赖下载完再用VSCode或WebStorm打开前端文件夹执行npm install。注意国内网络环境用npm install常会因为镜像源问题卡死解决办法是npm config set registry https://registry.npmmirror.com/ 先切换镜像源再装。5.2 数据库导入与配置文件修改数据库导入没什么技术含量但很多人就是卡在这一步。打开MySQL客户端Navicat或命令行执行CREATE DATABASE IF NOT EXISTS english_reading DEFAULT CHARSET utf8mb4; USE english_reading; SOURCE /你的路径/english_reading.sql;SQL脚本里我习惯把前面三段创建库、选库、建表全写进去但这里演示的是手动一步步执行等文件导入成功后用SELECT COUNT(*) FROM article;验证一下有没有数据。一般正常的脚本导入后article表至少10条记录user表有2个演示账号admin/admin123管理员、demo/demo123普通用户。然后改后端的application.ymlserver: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/english_reading?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath*:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplserverTimezoneAsia/Shanghai必须写否则MySQL 8.0下会报时区错误。map-underscore-to-camel-case是MyBatis-Plus的默认行为但我还是显式写上让读者看得清楚。5.3 前后端联调开发环境代理与生产构建开发阶段的联调有一个坑要注意前端页面跑在9528端口后端接口在8080端口直接请求必然跨域。两种解决方式后端用CrossOrigin注解是最快的但只适合调试推荐前端配置代理Vue CLI项目的vue.config.jsconst { defineConfig } require(vue/cli-service) module.exports defineConfig({ transpileDependencies: true, devServer: { port: 9528, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } })这样前端请求/api/auth/login会被自动转发到后端8080端口同时把/api前缀剥掉。生产部署时可以把前端npm run build生成的dist目录下的静态资源直接放进后端的src/main/resources/static目录这样打成一个jar包启动同一个端口同时提供页面和接口省去配Nginx的麻烦。6. 我踩过的坑时区、跨域、路由白屏、端口占用毕设开发周期里一定会碰到几类高频问题。这些问题光靠查报错信息很难一次解决我把经验总结成速查表按症状排错会快得多。6.1 数据库连接失败时区与驱动冲突报错信息一般是“The server time zone value is unrecognized”或者“Public Key Retrieval is not allowed”。前者就是application.yml里少了serverTimezone配置加上就好。后者是MySQL 8.0的驱动默认不允许远程公钥检索url后面追加allowPublicKeyRetrievaltrue即可。连接用的驱动类名8.0以下是com.mysql.jdbc.Driver8.0及以后是com.mysql.cj.jdbc.Driver写错了也会报ClassNotFound。6.2 跨域请求失败Network Error但后端日志正常前端浏览器控制台报跨域但后端的SQL查询日志正常执行说明后端接口本身没问题纯粹是浏览器策略拦截了响应。处理方案首选前端代理如果后端非要自己解加一个全局CorsFilter要比每个Controller都加CrossOrigin更一劳永逸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); } }这里注意一个细节setAllowCredentials(true)之后allowedOrigin不能写*必须写allowedOriginPattern(*)这是SpringBoot 2.4之后的一个兼容性调整很多旧教程没更新就踩坑了。6.3 Vue路由白屏history模式和404开发模式一切正常build部署到服务器后刷新页面就404或白屏。这是Vue Router的history模式在后端没有配置路由回退导致的。解决办法有两种要么改用hash模式URL会带个#号丑但省事要么在后端加一个转发控制器让所有非/api的路径都转发到index.htmlController public class SpaForwardController { RequestMapping(value /{path:[^\\.]*}) public String forward() { return forward:/index.html; } }这个控制器的正则要匹配“不包含点的路径”避免css和js资源文件被拦截转发否则会出现页面白屏但浏览器控制台报静态资源404的错误。6.4 端口被占用启动报端口8080被占用Windows系统常见的坑。打开命令提示符执行netstat -ano | findstr 8080找到占用端口的PID后taskkill /F /PID 进程号。搞不定就直接换端口在application.yml里把server.port改成8081或别的。7. 答辩高频问题与两个加分的扩展方向功能全部实现、项目顺利跑起来之后接下来的重头戏是答辩。这里把我总结的评委高频问题和应答思路整理出来再分享两个能体现你思考深度的扩展点。7.1 评委最爱问的问题及应答思路“你的分级标准是怎么定义出来的”如果你说“我拍脑袋定的1到6级”这题就挂了。好的回答是“参考了蓝思阅读分级和CEFR框架1-2级对应初级阅读者能读懂短句和基础词汇3-4级对应中级阅读者需要理解复合句5-6级对应高级阅读者涉及抽象概念和复杂逻辑。同时用测评题的难度系数来量化定级答对高难度题的得分权重更高。”逻辑闭环就出来了。“为什么不用协同过滤推荐”如果你用了Iterm-CF这类算法评委一定会追问“用户-物品矩阵怎么构建的数据稀疏怎么解决”大部分毕设根本没有大量数据支撑这个算法很容易露馅。实话实说“当前数据规模下协同过滤面临冷启动问题所以我采用基于内容的匹配推荐先用等级过滤再用标签加权。如果后续数据量上来可以引入协同过滤作为补充。”这个回答既承认当前方案的合理性又展示了迭代意识评委挑不出毛病。“你的安全措施有哪些”至少能答出三层密码加盐MD5存储、全局异常处理不泄露堆栈信息、前端路由守卫控制未登录访问。再补一句“管理端接口有权限拦截器只有管理员角色才能调用”这就比大部分只会说“我做了登录功能”的同学高一档。“项目的亮点是什么”别只说功能多。围绕“数据驱动”讲平台记录每道阅读题的作答结果反向修正用户的等级标签从而让推荐越发精准。这个机制是一个完整的数据闭环功能多不等于有亮点数据驱动才是有说服力的亮点。7.2 两个值得投入的扩展方向扩展方向一用Redis缓存热门文章列表。当前文章推荐每次都查数据库数据量小时没问题但可以给热门文章列表加缓存设定10分钟过期。这样既提升首页性能又能把Redis写进简历贴合企业级项目的实际做法。实现代码不超过30行但简历上加一句“熟悉Redis缓存应用”还是有分量的。扩展方向二给管理端加批量导入。当前文章只能一条条添加太费劲。可以做一个JSON文件批量导入接口按Excel或JSON格式整理文章数据上传后自动解析写入。这个功能看似不起眼但能体现“你考虑过真实运营场景”——管理员每天要上传大量文章批量导入是刚需。扩展点写进项目总结里比空谈技术栈有价值。最后再分享一个实用的小技巧项目里所有的前端请求封装成统一的request.js模块API接口按模块建文件比如article.js、user.js、test.js。这不止让代码看着专业更重要的是你做扩展时不用到处定位代码一个接口一个文件改起来思路特别清晰。我当时按照这个习惯维护后期加功能和改bug的效率高出一大截——这个项目从框架搭建到最终交付大概五周时间其中约有一周花在打磨阅读页排版和推荐逻辑上没有这段打磨项目不会有现在这样的完整度答辩的时候也不会那么有底气。 SpringBoot+Vue在线英语阅读分级平台：从测评到推荐全解析
做Java Web方向毕业设计的同学应该都有同感SpringBootVue早就成了标配组合但真正把项目做出“业务深度”的其实不多。今天拆一个我经手过的完整毕设项目——基于SpringBootVue的在线英语阅读分级平台包含前后端源码、SQL脚本和接口文档。它不是一个堆功能的CRUD项目而是有一条完整的业务闭环用户先做分级测评系统根据等级推荐匹配难度的英语文章阅读过程中可以划词查询、加入生词本读完做练习题系统根据正确率再动态调整推荐等级。这套逻辑做透了答辩评委基本挑不出大毛病。文章会从数据库设计讲到接口实现、前端排版、部署踩坑最后附上答辩高频问题清单。不管你打算直接参考还是二次开发这篇都能帮你省掉大量查资料的功夫。1. 在线英语阅读分级平台该怎么拆先把技术选型和业务闭环理清楚做毕设最忌讳一上来就写代码先把项目“画像”想清楚后面每一步都是顺的。这个项目的核心不是“英语阅读”也不是“文章展示”而是“分级”这两个字——怎么判断用户的英语水平怎么给文章定难度级别怎么把合适的内容推给合适的人。这三个问题才是抽答辩时最能体现你思考深度的东西。1.1 分级平台到底在解决什么问题市面上的英语学习产品很多但多数是“所有用户看同一批内容”要么太简单让人失去兴趣要么太难直接劝退。分级阅读的思路是参考蓝思值Lexile和CEFR欧洲语言共同参考框架给文章打上难度标签给用户打上水平标签然后做匹配。体现在这个项目里就是新用户注册后先做一套分级测评系统通过答题正确率和题目难度系数算出初始等级文章表里每条内容都有level字段范围1-6也可细分到A1-C2共12档但毕设6档足够展示逻辑首页不再是“最新文章列表”而是“根据我的等级推荐的文章列表”等级越高看到的文章难度越大读完后有阅读理解题系统记录成绩并在下次推荐时微调等级权重。说白了业务的“心脏”是一个简单但说得通的推荐逻辑。评委看重的不是你用了多高深的算法而是你有没有“根据数据驱动内容展示”的意识——这比堆十个功能模块都有说服力。1.2 技术选型为什么锁定SpringBootVue这套组合后端用SpringBoot 2.x MyBatis-Plus MySQL 8.0前端用Vue 2或Vue 3皆可 Element UI Axios再加一个Vue Router做页面路由这个组合我愿称之为“毕设黄金阵容”。选它有几个现实原因。第一SpringBoot把SSM时代的XML配置全部干掉自动配置机制让项目能在十分钟内从零跑起来这对时间紧张的毕设来说太重要了。第二MyBatis-Plus提供了单表CRUD的现成方法例如selectById、selectPage这类封装省去的代码量足够让你把精力花在业务设计上。第三Vue的组件化开发模式跟后台管理页面的契合度特别高——一个侧边栏组件、一个表格组件、一个弹窗组件写完能复用整个项目工作量比JSP时代砍半不止。第四网上资料最多、遇到bug最好查光是“SpringBoot跨域怎么解决”这种问题就有几百篇现成答案选冷门框架等于给自己挖坑。至于HTML和CSS在这个项目里分量一点都不轻。Vue负责的是页面结构和数据绑定但阅读页面的排版体验——字号、行间距、背景色、生词高亮这些全得靠CSS一笔一笔调。我见过太多只写了“功能能用”就交差的项目首页样式惨不忍睹答辩时老师打开页面就皱眉头。这个项目的阅读页需要细致打磨后面第4节我会具体讲怎么调。1.3 模块拆分用户端和管理端各做什么项目分成两个大模块按角色拆功能别做成一个大杂烩。用户端核心功能注册登录用户名邮箱密码MD5加盐存储别用明文这属于安全基础分。分级测评10道单选题题目自带难度系数提交后自动算分定级。文章阅读分级推荐列表、文章详情页、阅读计时、划词翻译。阅读练习每篇文章配套3-5道阅读理解题做完判分计入记录。生词本阅读中点击单词加入生词本列表展示可标记“已掌握”。个人中心我的等级、阅读统计篇数、时长、正确率、历史记录。管理端核心功能文章管理增删改查、设置level标签和tag题材分类、上下架。题目管理维护测评题库和阅读练习题支持批量导入。用户管理查看用户列表、等级分布、重置密码。数据概览用图表展示注册人数、各等级人数占比、文章阅读排行。这11个功能基本覆盖了一个完整产品的最小闭环不会显得单薄也不会因为过度膨胀导致无法按期交付。2. 数据库设计5张核心表撑起整个分级业务表结构设计决定了一个项目后面写代码是丝滑还是痛苦。这个项目的表不用多但每张表的字段都要能回答一个核心问题。我直接分享我最终落地的方案。2.1 用户与测评user表和level_test_record表用户表是基础注意几点密码字段长度要设计成255因为用了MD5加盐之后长度会超过32level字段允许为空为空表示还没测评前端要用这个状态判断“是否要引导用户去测评”。CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 用户ID, username varchar(50) NOT NULL COMMENT 用户名, password varchar(255) NOT NULL COMMENT 密码加盐MD5, email varchar(100) DEFAULT NULL COMMENT 邮箱, level tinyint(4) DEFAULT NULL COMMENT 测评等级1-6NULL未测评, created_at datetime DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY idx_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;测评记录表的用途是“留痕”——用户每次测评的结果都要存下来这样在后端根据答题记录动态调整等级时有据可查。CREATE TABLE level_test_record ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, score int(11) NOT NULL COMMENT 测评得分100制, result_level tinyint(4) NOT NULL COMMENT 测评结果等级1-6, detail_json text COMMENT 答题明细每题得分JSON格式, test_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 测评时间, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT分级测评记录表;这里有个细节detail_json字段很多人不会加但它有价值。第一后台可以分析用户错的题集中在哪个难度区间进而更精确地定级第二答辩时老师如果问“你的定级依据是什么”你直接把答题明细JSON调出来展示比凭空解释有力得多。2.2 文章与题库article表、question_bank表和reading_record表文章表是这个项目内容侧的基石。content字段用MEDIUMTEXT存储的是HTML片段因为前端阅读页需要用富文本方式渲染你不能让用户看到的是一大坨换行符都被吃掉的纯文本。word_count字段可以在读入时用后端统计好省得前端再算。CREATE TABLE article ( id bigint(20) NOT NULL AUTO_INCREMENT, title varchar(200) NOT NULL COMMENT 文章标题, content MEDIUMTEXT NOT NULL COMMENT 正文HTML格式, summary varchar(500) DEFAULT NULL COMMENT 摘要/导语, level tinyint(4) NOT NULL COMMENT 难度等级1-6, tag varchar(50) DEFAULT NULL COMMENT 题材标签科技/文化/故事/科普..., word_count int(11) DEFAULT 0 COMMENT 单词数, view_count int(11) DEFAULT 0 COMMENT 阅读次数, status tinyint(4) DEFAULT 1 COMMENT 1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_level_tag (level, tag) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT文章表;联合索引idx_level_tag很关键。推荐列表的SQL核心条件是where level? and tag?这个联合索引能让查询速度有质的提升数据量超过几千条之后区别明显。这是我在优化阶段加上的不是初始设计就有。题库表存测评题和阅读题用type字段区分题目用途1代表分级测评题2代表阅读练习题。每道题至少四个选项correct_index存正确答案序号difficulty系数从1到5递增。CREATE TABLE question_bank ( id bigint(20) NOT NULL AUTO_INCREMENT, type tinyint(4) NOT NULL COMMENT 1-测评题 2-阅读题, article_id bigint(20) DEFAULT NULL COMMENT 关联文章ID阅读题用, difficulty tinyint(4) DEFAULT 3 COMMENT 难度系数1-5, question varchar(500) NOT NULL COMMENT 题干, option_a varchar(255) DEFAULT NULL, option_b varchar(255) DEFAULT NULL, option_c varchar(255) DEFAULT NULL, option_d varchar(255) DEFAULT NULL, correct_index tinyint(4) NOT NULL COMMENT 正确选项0-A 1-B 2-C 3-D, PRIMARY KEY (id), KEY idx_type (type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT题库表;阅读记录表记录用户和文章的交互。核心字段是last_position存用户读到第几分钟或第几个字符位置用于“继续阅读”功能。reading_status存状态0未完成、1已完成阅读、2练习题已通过。这个表是数据统计报表的数据来源也能支撑“我的阅读历史”页面。CREATE TABLE reading_record ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL, article_id bigint(20) NOT NULL, last_position int(11) DEFAULT 0 COMMENT 阅读进度字符位置, reading_status tinyint(4) DEFAULT 0 COMMENT 0未完成 1已完成 2练习题通过, exercise_score int(11) DEFAULT NULL COMMENT 练习题得分, read_duration int(11) DEFAULT 0 COMMENT 累计阅读时长秒, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY idx_user_article (user_id, article_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT阅读记录表;注意联合唯一索引idx_user_article它保证了“一个用户对同一篇文章只有一条记录”业务上用insert...on duplicate key update的写法去更新进度而不是每次阅读都插一条新记录。这个问题在毕设里非常经典很多人做成了一篇文章读五次生成五条记录。2.3 SQL脚本编写导入顺畅是基本素养很多同学交付SQL脚本时就是一句“直接导入即可”结果别人一导入就报错。好的脚本必须在最前面加三个东西DROP DATABASE IF EXISTS、CREATE DATABASE、USE DATABASE。这样别人不管在什么环境下执行都能一遍过。字符集统一用utf8mb4因为要存HTML片段里面可能有特殊符号utf8mb4兼容性最好。还要准备足够的种子数据——用户2个、文章10篇覆盖6个等级、测评题10道、阅读练习题20道让演示时页面不空。demo用户账号密码在脚本注释里写明方便老师一键登录查看效果。3. 后端接口设计从统一返回结构到分级推荐逻辑接口设计直接决定前端联调时的心情。我的习惯是先定统一返回格式再写业务接口最后补全局异常处理。顺序反了就容易出现每个接口返回格式不一致、前端解析写好几套逻辑的悲剧。3.1 统一返回结构一个Result类解决前后端协议问题前后端交互最稳妥的做法是定义一个泛型Result类所有接口返回对象都是这个结构的实例Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端Axios统一拦截只有code为200时才放行数据否则直接弹出message提示。这样登录过期、参数错误这类问题不需要每个页面单独处理一次封装全局生效。3.2 全局异常处理把报错信息变成人话SpringBoot里可以用RestControllerAdvice加ExceptionHandler做全局异常捕获。数据库主键冲突转成“用户名已存在”空指针记录日志同时返回“系统繁忙”。这一步属于答辩加分项因为很多同学做到这一步就交差了而你会说“我的项目里有全局异常处理保证任何异常前端都能收到可读的提示”评委一听就知道你有工程意识。3.3 核心推荐逻辑别整协同过滤先做好内容匹配推荐算法是这个项目的重头戏。如果你的简历还没到“机器学习”这个高度千万别硬说“我用了协同过滤”——评委追问你Spark和用户矩阵怎么构建你很容易卡壳。务实的做法是“基于等级标签的匹配推荐”逻辑清晰、代码量少、演示效果好。我的实现分三步第一步读取用户当前等级。如果用户没测过分默认给3级并页面上引导去测评。第二步从文章表拉取当前等级±1范围内的文章。比如用户是3级就拉level在2到4之间的文章这个缓冲区间让推荐结果有梯度又不至于太难。第三步按标签偏好加权排序。用户阅读历史中如果科普类最多就在候选文章里把tag科普的文章排前面。核心Service代码如下Override public ListArticleVO recommendArticles(Long userId, int limit) { // 1. 获取用户信息没测评默认等级3 User user userMapper.selectById(userId); int level (user.getLevel() null) ? 3 : user.getLevel(); // 2. 候选范围等级±1 LambdaQueryWrapperArticle wrapper new LambdaQueryWrapper(); wrapper.between(Article::getLevel, level - 1, level 1) .eq(Article::getStatus, 1); ListArticle candidates articleMapper.selectList(wrapper); // 3. 统计用户历史阅读中最偏好的两个标签 ListString favoriteTags readingRecordMapper.selectFavoriteTags(userId, 2); if (favoriteTags.isEmpty()) { // 无历史记录直接按浏览量排序返回 return candidates.stream() .sorted((a, b) - b.getViewCount() - a.getViewCount()) .limit(limit) .map(ArticleVO::new) .collect(Collectors.toList()); } // 4. 偏好标签加权其余保持原有顺序 candidates.sort((a, b) - { int scoreB favoriteTags.contains(b.getTag()) ? 1 : 0; int scoreA favoriteTags.contains(a.getTag()) ? 1 : 0; if (scoreB ! scoreA) { return scoreB - scoreA; } return b.getViewCount() - a.getViewCount(); }); return candidates.stream().limit(limit).map(ArticleVO::new).collect(Collectors.toList()); }这个方法解决的问题是“冷启动”和“可解释性”。冷启动在于没有历史数据时按浏览量兜底可解释性在于“因为我常看科普类所以优先给你推科普”这个理由在答辩现场一说评委立刻秒懂。3.4 测评接口得分计算与等级映射公式测评接口POST /api/test/submit接收参数是用户答案数组。设计上我建议在Service层做四件事遍历答案比对correct_index统计正确数对每道题按难度置信度加权。难度系数是1-5答对难度5的题权重是答对难度1题的2.5倍这样得出来的总分能体现“不是只会简单的题”映射等级。简单做法60分以下定1级60-70定2级70-80定3级80-90定4级90以上根据题目难度再细分到5/6级更新user表的level字段同时插入一条测评记录。等级映射的区间我调了好几轮。最初直接按分数砍段结果发现很多用户测出来全是3级缺乏区分度。后来加了“难度权重”后区分度明显好了因为高分基本上是靠难题拉上来的而不是靠简单题堆出来的。3.5 接口文档不要临时写用Apifox一套维护接口文档不要写Word版效率太低而且改动不同步。用Apifox在线协作把每个接口的URL、请求参数、返回值示例维护进去生成在线分享链接放进README。前端联调时照着文档写Axios几乎不用来来回回找你问“这个接口返回什么字段”。这个习惯还有一个隐藏好处答辩的时候老师如果问“你项目里文档齐全吗”你把Apifox的接口清单页面直接展示出来上面十几条接口记录整整齐齐这比CTRLC搜出来的项目要有说服力得多。4. 前端实现阅读排版是这个项目的门面我在前面说过这个项目的前端不是普通后台管理页面能糊弄过去的。用户打开网站第一眼看的是首页然后点进文章阅读——如果阅读页的排版让人不舒服整个产品的品质感就垮了。这里把CSS的功力全部拿出来。4.1 Vue页面结构与路由设计views目录建议这样组织功能边界清晰src/views ├── home/ 首页推荐列表 ├── article/ 文章详情阅读页 ├── test/ 分级测评页 ├── vocab/ 生词本 ├── profile/ 个人中心 ├── admin/ 管理后台 │ ├── article/ 文章管理 │ ├── question/ 题目管理 │ └── user/ 用户管理路由守卫是本项目前端的核心逻辑之一。main.js或router/index.js里加beforeEach钩子如果访问的文章列表页和测评页需要登录先检查localStorage有没有token没有就重定向到登录页。这个逻辑简单但必加否则未登录用户直接访问页面后端接口虽然会拦截但前端报错提示很难看。4.2 阅读页排版一行CSS都别将就文章阅读页是整个HTMLCSS最能出彩的地方。我调试了很久最终沉淀了一套参数直接分享你参考。字体方面body字号不能小于16px阅读类页面建议18px行高1.8以上。英文阅读用衬线字体更舒服我选了Georgia作为正文字体栈这是欧美纸质媒体常用的字体后台管理页面才用无衬线字体。太长的行会让视线换行困难所以内容区最大宽度控制在680px左右左右留白充足类似报纸的栏宽。段落间距margin-bottom设1.5em。生词高亮用mark标签背景色方案默认浅黄色背景鼠标悬浮时加深并弹出释义tooltip。CSS实现不复杂.mark-word { background: #fff7d6; border-radius: 3px; padding: 0 4px; cursor: pointer; position: relative; transition: background 0.2s; } .mark-word:hover { background: #ffec9e; } .word-tip { display: none; position: absolute; bottom: 140%; left: 50%; transform: translateX(-50%); background: #333; color: #fff; padding: 8px 12px; border-radius: 6px; white-space: nowrap; font-size: 14px; z-index: 99; } .mark-word:hover .word-tip { display: block; }这里有个细节单词释义的tooltip是绝对定位的如果文章容器设置了overflow:hidden提示框会被裁掉。我踩过这个坑阅读容器不要设overflow:hidden有需要的话改用min-height约束布局。夜间模式是这个项目的一个亮点功能花不了多少代码但观感提升巨大。思路是在html上切换一个data-theme属性CSS变量控制配色:root { --bg-color: #ffffff; --text-color: #333333; } html[data-themedark] { --bg-color: #1e1e1e; --text-color: #cccccc; }阅读页body直接用var(--bg-color)当背景色切换只需要一段JavaScript改变data-theme属性的值。演示时一键切换深色模式老师一般都会觉得“这个项目做得很细”成本不过三五十行代码。4.3 划词取词与生词本交互用户阅读时想查单词最顺手的交互是“划词悬浮释义”。实现思路监听mouseup事件用window.getSelection()获取选中的文本判断是英文单词后调后端词典接口把释义放进浮层。生词本按钮做成浮层里的一个小加号点了调POST /api/vocab/add接口把当前单词收进生词本。前端的关键代码是mouseup事件处理document.addEventListener(mouseup, (e) { const selection window.getSelection(); const text selection.toString().trim(); if (!text) return; // 只处理纯英文单词 if (!/^[a-zA-Z]$/.test(text)) return; // 计算弹窗位置基于选区边界 const rect selection.getRangeAt(0).getBoundingClientRect(); this.showTip(text, rect); });这里要注意事件监听加在document上而不是文章内容容器上。因为用户可能在文章末尾的练习题区域也选中单词全局监听才能覆盖所有情况。同时要防止弹窗里的文字被再次选中触发死循环弹窗本身不要用可选中文本。生词本页面用虚拟滚动渲染列表单词多的时候性能不崩。我实测过加入200个生词后普通v-for渲染还是有微微卡顿换成简单虚拟滚动后流畅多了。这个优化点写进项目文档里也是一个加分项。5. 本地运行全流程从SQL导入到前后端联调这个项目交付给别人或者演示时能不能一键跑起来决定了可信度。我把从零到运行的完整流程记录出来你照着这个顺序操作基本不出错。5.1 环境准备清单JDK 1.8或11不要用17以上部分依赖不兼容Node.js 14或16版本太高可能导致node-sass这类库编译失败建议16稳妥MySQL 5.7或8.0注意8.0的驱动和时区配置略有不同Maven 3.6IDEA自带的也可以用可选Redis但毕设不强制如果用的话注意配置RedisTemplate的序列化方式。流程是先用IDEA打开后端文件夹等待Maven依赖下载完再用VSCode或WebStorm打开前端文件夹执行npm install。注意国内网络环境用npm install常会因为镜像源问题卡死解决办法是npm config set registry https://registry.npmmirror.com/ 先切换镜像源再装。5.2 数据库导入与配置文件修改数据库导入没什么技术含量但很多人就是卡在这一步。打开MySQL客户端Navicat或命令行执行CREATE DATABASE IF NOT EXISTS english_reading DEFAULT CHARSET utf8mb4; USE english_reading; SOURCE /你的路径/english_reading.sql;SQL脚本里我习惯把前面三段创建库、选库、建表全写进去但这里演示的是手动一步步执行等文件导入成功后用SELECT COUNT(*) FROM article;验证一下有没有数据。一般正常的脚本导入后article表至少10条记录user表有2个演示账号admin/admin123管理员、demo/demo123普通用户。然后改后端的application.ymlserver: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/english_reading?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath*:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplserverTimezoneAsia/Shanghai必须写否则MySQL 8.0下会报时区错误。map-underscore-to-camel-case是MyBatis-Plus的默认行为但我还是显式写上让读者看得清楚。5.3 前后端联调开发环境代理与生产构建开发阶段的联调有一个坑要注意前端页面跑在9528端口后端接口在8080端口直接请求必然跨域。两种解决方式后端用CrossOrigin注解是最快的但只适合调试推荐前端配置代理Vue CLI项目的vue.config.jsconst { defineConfig } require(vue/cli-service) module.exports defineConfig({ transpileDependencies: true, devServer: { port: 9528, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } })这样前端请求/api/auth/login会被自动转发到后端8080端口同时把/api前缀剥掉。生产部署时可以把前端npm run build生成的dist目录下的静态资源直接放进后端的src/main/resources/static目录这样打成一个jar包启动同一个端口同时提供页面和接口省去配Nginx的麻烦。6. 我踩过的坑时区、跨域、路由白屏、端口占用毕设开发周期里一定会碰到几类高频问题。这些问题光靠查报错信息很难一次解决我把经验总结成速查表按症状排错会快得多。6.1 数据库连接失败时区与驱动冲突报错信息一般是“The server time zone value is unrecognized”或者“Public Key Retrieval is not allowed”。前者就是application.yml里少了serverTimezone配置加上就好。后者是MySQL 8.0的驱动默认不允许远程公钥检索url后面追加allowPublicKeyRetrievaltrue即可。连接用的驱动类名8.0以下是com.mysql.jdbc.Driver8.0及以后是com.mysql.cj.jdbc.Driver写错了也会报ClassNotFound。6.2 跨域请求失败Network Error但后端日志正常前端浏览器控制台报跨域但后端的SQL查询日志正常执行说明后端接口本身没问题纯粹是浏览器策略拦截了响应。处理方案首选前端代理如果后端非要自己解加一个全局CorsFilter要比每个Controller都加CrossOrigin更一劳永逸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); } }这里注意一个细节setAllowCredentials(true)之后allowedOrigin不能写*必须写allowedOriginPattern(*)这是SpringBoot 2.4之后的一个兼容性调整很多旧教程没更新就踩坑了。6.3 Vue路由白屏history模式和404开发模式一切正常build部署到服务器后刷新页面就404或白屏。这是Vue Router的history模式在后端没有配置路由回退导致的。解决办法有两种要么改用hash模式URL会带个#号丑但省事要么在后端加一个转发控制器让所有非/api的路径都转发到index.htmlController public class SpaForwardController { RequestMapping(value /{path:[^\\.]*}) public String forward() { return forward:/index.html; } }这个控制器的正则要匹配“不包含点的路径”避免css和js资源文件被拦截转发否则会出现页面白屏但浏览器控制台报静态资源404的错误。6.4 端口被占用启动报端口8080被占用Windows系统常见的坑。打开命令提示符执行netstat -ano | findstr 8080找到占用端口的PID后taskkill /F /PID 进程号。搞不定就直接换端口在application.yml里把server.port改成8081或别的。7. 答辩高频问题与两个加分的扩展方向功能全部实现、项目顺利跑起来之后接下来的重头戏是答辩。这里把我总结的评委高频问题和应答思路整理出来再分享两个能体现你思考深度的扩展点。7.1 评委最爱问的问题及应答思路“你的分级标准是怎么定义出来的”如果你说“我拍脑袋定的1到6级”这题就挂了。好的回答是“参考了蓝思阅读分级和CEFR框架1-2级对应初级阅读者能读懂短句和基础词汇3-4级对应中级阅读者需要理解复合句5-6级对应高级阅读者涉及抽象概念和复杂逻辑。同时用测评题的难度系数来量化定级答对高难度题的得分权重更高。”逻辑闭环就出来了。“为什么不用协同过滤推荐”如果你用了Iterm-CF这类算法评委一定会追问“用户-物品矩阵怎么构建的数据稀疏怎么解决”大部分毕设根本没有大量数据支撑这个算法很容易露馅。实话实说“当前数据规模下协同过滤面临冷启动问题所以我采用基于内容的匹配推荐先用等级过滤再用标签加权。如果后续数据量上来可以引入协同过滤作为补充。”这个回答既承认当前方案的合理性又展示了迭代意识评委挑不出毛病。“你的安全措施有哪些”至少能答出三层密码加盐MD5存储、全局异常处理不泄露堆栈信息、前端路由守卫控制未登录访问。再补一句“管理端接口有权限拦截器只有管理员角色才能调用”这就比大部分只会说“我做了登录功能”的同学高一档。“项目的亮点是什么”别只说功能多。围绕“数据驱动”讲平台记录每道阅读题的作答结果反向修正用户的等级标签从而让推荐越发精准。这个机制是一个完整的数据闭环功能多不等于有亮点数据驱动才是有说服力的亮点。7.2 两个值得投入的扩展方向扩展方向一用Redis缓存热门文章列表。当前文章推荐每次都查数据库数据量小时没问题但可以给热门文章列表加缓存设定10分钟过期。这样既提升首页性能又能把Redis写进简历贴合企业级项目的实际做法。实现代码不超过30行但简历上加一句“熟悉Redis缓存应用”还是有分量的。扩展方向二给管理端加批量导入。当前文章只能一条条添加太费劲。可以做一个JSON文件批量导入接口按Excel或JSON格式整理文章数据上传后自动解析写入。这个功能看似不起眼但能体现“你考虑过真实运营场景”——管理员每天要上传大量文章批量导入是刚需。扩展点写进项目总结里比空谈技术栈有价值。最后再分享一个实用的小技巧项目里所有的前端请求封装成统一的request.js模块API接口按模块建文件比如article.js、user.js、test.js。这不止让代码看着专业更重要的是你做扩展时不用到处定位代码一个接口一个文件改起来思路特别清晰。我当时按照这个习惯维护后期加功能和改bug的效率高出一大截——这个项目从框架搭建到最终交付大概五周时间其中约有一周花在打磨阅读页排版和推荐逻辑上没有这段打磨项目不会有现在这样的完整度答辩的时候也不会那么有底气。