企业官网建设流程全解析

每到毕设季，总有人反复问同一类问题：Java Web方向到底选什么题目，既不容易一眼撞车，又能把课程里学的技术栈完整展示出来。我的答案里，一直给“SpringBoot+Vue英语知识应用网站平台”这样的项目留着一个位置。它看上去不是那种惊艳的创意型选题，却特别适合当个人工程能力的载体——后端要写接口，前端要做页面，数据库要设计表结构和初始化数据，还要整理接口文档。一套跑下来，Web开发的核心技能基本全覆盖了。

如果你是正在准备毕设的学生，或者想复现一个完整前后端分离项目的开发者，这篇内容会围绕完整项目源码、SQL脚本和接口文档三样东西展开，从头讲清楚一个英语知识应用网站从需求拆分到数据库设计、从后端接口到前端页面、再到本地跑通项目的全部关键细节。文中所有的思路都基于一个普通开发者的实际工程习惯，不是教科书目录。

1. 毕业设计选题前的需求分析：这个题目到底在考什么

1.1 从“学习网站”题目反推课程知识覆盖点

“英语知识应用网站”这个题目的重点，其实不在“英语”两个字，而在“知识应用”四个字。它本质上要求你把某个领域的知识内容组织成可浏览、可搜索、可练习的资源，再配上一整套用户体系。这样一个题目，考察的无非是几件固定的事：

• 后端：实体类设计、Mapper层、Service层、Controller层、登录鉴权、事务控制、异常处理、参数校验、分页查询。
• 前端：组件拆解、路由配置、状态管理、HTTP请求封装、列表数据的展示与交互。
• 数据库：至少五六张业务表、合理的表关系、初始化数据、常用查询语句。
• 工程能力：项目结构是否清晰、配置是否合理、依赖管理是否规范、接口文档是否完整。

换句话说，英语知识应用网站表面上是个内容系统，实际上是一份标准的Web全栈练习卷。相比纯粹的商城系统，它多了一层“学习内容”的语义，让数据库设计和接口设计都有更自然的业务场景。

1.2 如何把“课程作业”升级成“能答辩的作品”

很多课程作业停留在“能跑”这个层面：一个登陆页面能跳转、一个列表能展示、一个增删改查能完成，就算交差。但毕设作品不能只讲功能，还得讲设计理由。比如下面这类问题，答辩时几乎必然被问到：

• 用户登录为什么用JWT而不是Session？
• 词汇表分页为什么放在SQL层，而不是把所有数据查出来在内存里截取？
• 错题本和学习记录为什么单独建表，而不是直接查历史答案？
• 前端路由守卫是怎么防止未登录用户进入后台页面的？

这些问题的答案，恰恰要在系统设计和实现过程中预先想清楚。“做一个能跑的网站”和“做一个能讲清道理的网站”，这两件事的差别，就是课程作业和毕设作品的差别。这个英语知识应用项目，业务边界很清晰，非常适合用来练习这种“先讲道理、再写代码”的开发方式。

2. 功能模块划分：从“学习资源”到“在线练习”的业务闭环

2.1 用户端模块：学习、练习、记录一个都不少

一个符合毕设体量的英语知识应用网站，用户端通常包含下面这些模块：

• 注册与登录：支持用户名和密码注册，密码加密存储。
• 学习中心：词汇浏览、每日一句、阅读文章、语法知识点等内容展示。
• 在线练习：基于词汇和阅读文章的练习题，支持选择、填空等常见题型，提交后自动判分。
• 错题本：答错的题目自动进入错题列表，用户可以重新练习或移除。
• 学习统计：展示累计学习次数、总正确率、近7天活跃趋势等数据。

模块别贪多，把上述内容做完整，工作量已经足够一份毕设。很多同学一上来就想加背单词打卡、智能推荐、语音朗读，结果每个功能都只写了一半，反而是大忌。

2.2 后台管理模块：让项目具备“平台感”的关键

后台管理模块是区分“一个静态网站”和“一个应用平台”的分水岭。至少要包含：

• 内容管理：对词汇、文章、练习题进行增删改查。
• 用户管理：查看注册用户列表、禁用异常账号。
• 数据概览：用图表展示用户数量和内容数量，最好能显示最近几天的学习趋势。

后台不需要做得非常华丽，但它能证明你理解了角色权限和数据管理的完整链路。管理员账号和普通用户账号的权限区别，是答辩时一个很好的讲述点。

2.3 模块间如何串成一条“数据闭环”

我给这个项目定过一条核心业务链路，写文章、画PPT、答辩讲演示，都围绕它展开：

用户在词汇页面学习单词 → 进入词汇练习 → 提交答案 → 后端自动判分 → 答错的题写入错题本 → 学习记录更新 → 学习统计页面展示正确率变化。

这条链路的价值在于，它把不同模块之间的数据关系讲清楚了。词汇表和题目表通过内容ID关联，练习记录表保存用户的每一次答题结果，错题本表只保留答错的题目，统计表再基于这些记录做汇总。每个功能都不是孤立的，而是围绕“学—练—测—复盘”这条主线运转。答辩时能完整讲出这条链路，比单独说“我做了个词汇列表页面”要有说服力得多。

下面是一个简单的模块与落点对照表，方便规划开发顺序：

这张表对开发排期很有用，建议拿到题目后先把这个表格做出来，再开始建项目。

3. 技术选型逻辑：SpringBoot + Vue 的搭配为什么是毕设“安全牌”

3.1 SpringBoot在后端能省下多少琐事

SpringBoot在后端工程里的好处，不需要背概念，直接说体感：

一是内嵌Tomcat，不用单独下载一个容器再去部署，打包成一个jar就能跑，演示和部署都省事。二是Starter依赖体系让引入框架变得非常简洁，加一个依赖、写几条配置，就能拥有一个可用的Web环境。三是配置集中在application.yml或application.properties里，数据库连接、端口、日志、文件上传大小这些常见配置一目了然。

在毕设项目里，SpringBoot还有一个隐形的优势：社区案例极其丰富。你遇到的大部分异常，比如数据库连接失败、MyBatis映射不对、跨域被拦截，几乎都能在已有的项目经验里找到答案。对第一次做完整Web项目的同学来说，这是降低风险的重要因素。

3.2 Vue在前端为什么比JSP更适合这个项目

如果还在用JSP做前后端混合开发，不是不行，但这个英语知识应用网站的后端接口和前端页面会耦合在一起，改一个按钮样式可能都要重启服务。Vue把前端拆成组件，路由负责页面切换，axios负责调用后端接口，整个开发过程的组织方式会清晰很多。

Vue真正的优势是组件化和响应式数据。词汇列表可以拆成搜索栏、表格、分页器、收藏按钮几个组件，练习页可以拆成题目卡片、选项列表、交卷按钮。这些组件各自维护自己的状态，页面之间用路由参数或接口数据通信，团队协作或单人开发都很顺手。

另外，Vue的生态里还有Element UI / Element Plus这样的组件库，表格、表单、弹窗、布局这些后台管理高频组件可以直接用，省下的时间足够把业务逻辑写得更完整。

3.3 前后端分离的工程结构如何组织

一个标准的前后端分离项目，我会建议按下面的目录结构来规划：

english-app/ backend/ src/main/java/com/example/english/ controller/ # 控制器 service/ # 业务逻辑 mapper/ # 数据访问 entity/ # 实体类 config/ # 跨域、拦截器、分页插件等配置 common/ # 统一返回、异常处理、工具类 src/main/resources/ application.yml # 数据库、端口等配置 mapper/ # XML文件 frontend/ src/ api/ # 接口请求封装 router/ # 路由配置 store/ # 全局状态 views/ # 页面组件 components/ # 通用组件 sql/ english_app.sql # 建库、建表、初始化数据 接口文档.md README.md

后端只提供接口，不关心页面长什么样；前端只调用接口，不直接操作数据库。这样项目从结构上就是分层清晰的，答辩时把目录结构一投影，评审老师心里就已经有底了。

3.4 什么情况下不要选这个组合

写技术选型也得分情况。如果你的学校明确要求使用SSH框架或必须单机运行，不需要前端工程化，那前后端分离反而会给自己找麻烦。如果项目只是一个小小的图书管理Demo，用JSP加Servlet可能半天就能做完，引入Vue和SpringBoot反而显得杀鸡用牛刀。

SpringBoot+Vue适合的是：有一定开发时间、希望完整展示Web开发能力、能在本地独立跑通前后端、并且愿意为了更清晰的工程结构多花几天时间的场景。对大部分Java Web毕设来说，这个组合确实是稳的选择，但稳不等于无脑选，想清楚自己学校的验收要求再动手，才不会白费功夫。

4. 数据库设计：SQL脚本里的核心表关系与初始化数据

4.1 用户权限体系：从用户表到角色关联表

英语知识应用网站至少需要两类角色：普通用户和管理员。我习惯按三张表来设计权限部分：

• sys_user：存储用户基本信息，包括用户名、加密后的密码、昵称、头像、创建时间。
• sys_role：存储角色，比如角色编码ADMIN和USER。
• sys_user_role：用户和角色的关联表，一个用户可以拥有多个角色。

密码千万不能存明文。后端可以使用BCrypt算法对密码加密，同一个密码每次生成的哈希串不同，数据库中即使数据泄露，也无法直接反推出原密码。这一段在答辩时是很好的技术亮点。

下面是用户表的简化建表SQL，可以作为模板参考：

CREATE TABLE `sys_user` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` varchar(64) NOT NULL COMMENT '用户名', `password` varchar(128) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(64) DEFAULT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `status` tinyint DEFAULT '1' COMMENT '状态：1正常 0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';

4.2 英语知识内容的核心业务表

业务表是整个数据库设计的主体。围绕这个项目的核心链路，通常要有这么几张表：

词汇表：

CREATE TABLE `vocabulary` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '词汇ID', `word` varchar(64) NOT NULL COMMENT '单词', `phonetic` varchar(128) DEFAULT NULL COMMENT '音标', `part_of_speech` varchar(32) DEFAULT NULL COMMENT '词性', `translation` varchar(512) NOT NULL COMMENT '中文释义', `example_sentence` text COMMENT '例句', `difficulty` tinyint DEFAULT '1' COMMENT '难度：1初级 2中级 3高级', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='英语词汇表';

阅读文章表、题目表、学习记录表、错题本表的结构设计，思路是类似的。文章表要有标题、分类、正文、难度；题目表要有题干、选项、正确答案、解析；学习记录表要记录哪个用户对哪个内容做了什么操作；错题本表要关联用户和题目，同时保存用户当时提交的答案，方便复盘。

需要注意一个细节：题目表中，选项可以用JSON字符串存储。比如选择题的A、B、C、D四个选项，存成一个JSON数组，比建四五个字段更灵活。MySQL从5.7开始支持JSON类型，直接用这个类型即可，后端解析也不复杂。

4.3 表关系的设计与冗余取舍

词汇表、文章表、题目表，本质上都是“学习内容”，但我不建议因为都是内容就强行合并到一张content表里。业务场景不同：词汇有音标和词性，文章有大段正文，题目有选项和解析。合并成一张超级表，字段会有一大半为空，反而难以维护。

比较合理的关系是：

• sys_user 和 learning_record 是一对多，一个用户有多条学习记录。
• question 和 wrong_question 是一对多，一道题可以被多个用户记录为错题。
• vocabulary 和 favorite 是一对多，一个单词可以被多个用户收藏。
• learning_record用content_type字段区分内容类型，比如1表示词汇、2表示文章、3表示题目。

对了，外键要不要加？我的建议是物理外键尽量少加，逻辑关联为主。毕设项目里使用外键约束虽然看起来“关系正规”，但会给初始化数据和删除操作带来不少麻烦。比如删一个用户，还要先删他的学习记录、错题本、收藏记录，外键约束会直接导致删除失败。这种情况下，用代码在Service层控制删除顺序，比依赖数据库外键更灵活，也更好讲。

4.4 SQL脚本落地时的几个实用建议

SQL脚本是整个项目能否在别人电脑上跑起来的关键。写脚本时，我有几个很实用的习惯：

• 建库语句明确指定字符集：CREATE DATABASE IF NOT EXISTS english_app DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;，避免中文乱码。
• 每张表都用COMMENT注释说明用途；每个字段也尽量写注释。这个习惯在答辩展示创建表结构时特别加分。
• 建表脚本和初始化数据分开，或者放在同一个文件里用注释分隔。推荐使用一份完整的english_app.sql，包含建库、建表、插入初始化数据。
• 初始化数据量要保证演示效果，词汇至少准备50条、题目至少30道、阅读文章3到5篇。太少会让页面看起来空荡荡，太多又会浪费时间制造无意义数据。
• 每个SQL脚本必须能在重新导入后完整执行。建议拿到脚本后，用一个新的空库完整跑一遍，确保没有任何报错。

5. 后端接口的实操细节：从统一返回到鉴权分页

5.1 统一返回结构与全局异常处理

前后端分离项目里，接口返回的数据格式必须全项目统一，否则前端解析逻辑会写得非常痛苦。我习惯定义这样一套返回结构：

{ "code": 200, "message": "success", "data": {} }

其中code是业务状态码，200表示成功，500表示业务错误，401表示未登录或token失效。对应的Java封装类可以这样写：

@Data @Builder @NoArgsConstructor @AllArgsConstructor public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { return Result.<T>builder().code(200).message("success").data(data).build(); } public static <T> Result<T> error(String message) { return Result.<T>builder().code(500).message(message).build(); } }

除了统一返回，还要做全局异常处理。后端接口运行中抛出的异常，如果不处理，会直接在HTTP层返回一大堆英文堆栈信息，既难看又泄露实现细节。可以用一个全局异常处理器，把业务异常、参数校验异常、未知异常分别转换成统一返回结构。这样前端拿到的永远是标准格式，调试起来非常方便。

5.2 登录鉴权：从Session到Token的思路转变

这个项目的登录鉴权，我强烈建议使用JWT方案。流程概括下来是：

• 用户提交用户名和密码，后端校验通过后，生成一个包含用户ID和用户名的令牌。
• 前端收到令牌后存到localStorage，后续每次请求都在Authorization头里带上这个令牌。
• 后端写一个拦截器，对除登录、注册以外的接口统一校验令牌。校验失败时返回401状态码。

JWT的好处在于后端不需要维护Session状态，多个服务实例之间也能共享同一个鉴权机制。这个“无状态”的概念，在答辩时很容易讲清楚。如果使用Session，反而会被追问服务器集群部署时Session如何同步，那是更复杂的话题。

核心伪代码如下：

// 登录成功 String token = JWT.create() .withClaim("userId", user.getId()) .withClaim("username", user.getUsername()) .withExpiresAt(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .sign(Algorithm.HMAC256("secret")); // 拦截器校验 try { DecodedJWT jwt = JWT.require(Algorithm.HMAC256("secret")).build().verify(token); request.setAttribute("userId", jwt.getClaim("userId").asLong()); } catch (Exception e) { throw new BusinessException(401, "登录状态失效，请重新登录"); }

实际项目中，密钥不要写死在代码里，应该放在application.yml中，通过配置读取。这个小细节也经常被答辩老师问到。

5.3 分页查询接口的设计

列表类接口基本都要做分页。使用MyBatis-Plus时，分页查询非常简单：

public Result<IPage<Vocabulary>> page(int pageNum, int pageSize, String keyword) { LambdaQueryWrapper<Vocabulary> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), Vocabulary::getWord, keyword); Page<Vocabulary> page = new Page<>(pageNum, pageSize); IPage<Vocabulary> result = vocabularyMapper.selectPage(page, wrapper); return Result.success(result); }

接口返回的数据结构里，至少要有records、total、pages、current这四个字段。前端拿到这些数据，才能正确渲染表格和分页器。这里要注意，pageNum和pageSize一定要做上限校验，比如pageSize最大设为100，防止一次查出过多数据。

5.4 典型接口示例

整个项目最核心的接口，大概包括注册、登录、词汇分页、提交练习、统计概览。下面以提交练习为例，展示一个典型接口的设计：

• 请求路径：POST /api/exercise/submit
• 请求参数（JSON）：

{ "userId": 1, "answers": [ { "questionId": 101, "answer": "A" }, { "questionId": 102, "answer": "C" } ] }

• 后端逻辑：
  1. 遍历答案，逐题查询正确答案。
  2. 对比用户答案，生成判分结果。
  3. 答错的题目写入错题本表。
  4. 所有答题记录写入学习记录表。
  5. 更新用户统计表中的正确率。
  6. 返回本次得分和逐题解析。

这样一个接口，串起了题目、错题本、学习记录、用户统计四张表。答辩时把这段代码拿出来讲，能非常直观地展示你对业务链路的理解，比泛泛地说“我做了增删改查”强得多。

5.5 前后端联调中被忽略的细节

写接口的时候，有几个细节最容易在前端联调时爆雷：

• 跨域配置缺失：前端和后端端口不同，浏览器会拦截请求。需要在后端配置CorsFilter，或者在前端开发服务器配代理。
• 请求体格式不匹配：后端接口用@RequestBody接收JSON，前端却用form表单格式提交，会直接报错。
• 日期格式不一致：后端返回的时间如果是LocalDateTime默认格式，前端直接展示会很难看。建议统一格式为yyyy-MM-dd HH:mm:ss，在Jackson配置中全局指定。
• 空值处理：返回对象中的null字段，前端要用兜底逻辑展示，别让页面出现“undefined”。

这些细节看似小，但都是实际开发中每天都会遇到的事情。把它们提前在接口文档里写明，能省去联调阶段的大量沟通成本。

6. 前端页面组织与交互：Vue项目怎么把接口用起来

6.1 用Vue2还是Vue3，UI库怎么选

这个问题在开发前就要定清楚。考虑到毕设资源、网上案例、组件库兼容性，我建议如果没有特殊要求，直接用Vue2加Element UI，或者Vue3加Element Plus。关键是确定一个组合后不要频繁切换。很多同学卡在环境问题上，就是因为一会用Vue2教程的代码，一会又装了Vue3的项目，语法对不上。

如果你拿到的项目模板已经定好了版本，那尽量别自己升级大版本。一个项目里混用Vue2和Vue3的写法，是最折磨人的事情。

6.2 路由设计与菜单结构

前端页面应该围绕模块划分路由。一个典型的配置如下：

后端菜单和前端路由保持一致，后台管理模块单独加一层/admin前缀，方便权限控制。路由文件中再加一个前置守卫，未登录的跳转到登录页，普通用户无法访问管理员页面。

6.3 请求封装与token注入

前端一定要封装axios请求实例，不要在每一个页面里都直接写axios.get。封装的好处是统一管理baseURL、超时时间、请求头、错误提示。下面是一个很常用的封装写法：

import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code === 401) { localStorage.removeItem('token') window.location.href = '/login' } return res }, error => { return Promise.reject(error) } ) export default request

这样封装好之后，所有页面都通过统一的request对象调用后端接口，token自动带上，401时自动跳回登录页。后续如果要改接口前缀，只需要改一处。

6.4 核心页面的实现思路

词汇列表页是这个项目里最典型的CRUD展示页面。它的核心代码思路是：搜索框输入关键词，点击搜索后带pageNum和keyword调用分页接口；表格或卡片列表展示返回数据；分页器变化时重新请求；收藏按钮调用收藏接口并更新按钮状态。这个页面把Vue的响应式数据、组件通信、axios请求都串起来了，做完它，其它列表页基本都能照葫芦画瓢。

在线练习页稍微复杂一点。建议用下面的交互流程：

• 进入页面后，选择一个练习类型，加载一组题目。
• 每题显示题干和选项，用户点击选项后，答案记录在一个本地数组中。
• 交卷按钮提交整个答案数组给后端，后端一次判分。
• 返回结果后，前端展示总得分、每题正确或错误标记，以及解析。

这个流程比“逐题单独提交”体验好得多，也能体现你对接口批量设计的理解。练习页是答辩时最容易被现场演示的页面，值得多花点时间打磨。

学习统计页适合引入ECharts。近7天学习次数用折线图展示，正确率和错题分布用饼图展示，数据来自统计接口。图表会显著提升项目的视觉完成度，在答辩演示时也是一个不错的记忆点。

6.5 路由守卫与登录跳转

路由守卫是前端权限控制的核心。最简单的前置守卫是检查token是否存在：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() } else if (!token) { next('/login') } else { next() } })

如果想区分管理员权限，可以把用户角色存储在localStorage或全局状态管理里，在守卫里判断to.path是否以/admin开头，如果不是管理员角色就跳回首页。这个逻辑写起来不难，但能让你的项目在权限控制上显得完整。

7. 接口文档与交付整理：源码、SQL、文档如何形成闭环

7.1 接口文档应该包含什么信息

接口文档不是给机器看的，是给人和协作看的。一份合格的接口文档，每个接口至少应该包含：

• 接口名称和业务说明。
• 请求路径和请求方式。
• 是否需要登录、需要的角色权限。
• 请求参数表格：参数名、类型、是否必填、说明。
• 返回结果示例：成功返回和失败返回各给一个。
• 错误码说明：什么时候会返回什么错误码。

很多同学在毕设交付时只给一个项目源码，接口文档完全没有，或者随便拍脑袋写几行字。实际上，接口文档是评审老师判断你工程能力的重要材料。代码可能有样式问题，但一份结构清晰的接口文档，直接说明你确实把项目当作一个产品在交付。

7.2 一个接口文档的示例

下面以“词汇分页查询接口”为例，展示文档里信息的组织方式：

一个接口一行表格可能写不下，所以完整文档往往是“表格加详细说明”的结构。建议在文档开头放一段“代码约定”，说明统一返回结构、登录鉴权方式、日期格式等全局约定。看完开头这几条，任何开发都能快速上手你的项目。

7.3 用Swagger和Apifox提升文档维护效率

手写文档很容易和代码脱节，接口改了几次，文档却还停在旧版本。为了解决这个问题，可以在后端集成Swagger或SpringDoc，通过注解自动生成在线接口文档。这样接口一改，文档自动跟着变，前端开发直接看在线页面。

如果不想让项目依赖太多额外工具，也可以把接口定义和维护放在Apifox这类工具里。它支持从Swagger导入、在线调试、一键导出Markdown，非常适合毕设项目的接口管理。最终交付时，导出一份静态的接口文档放进项目包，既整洁又方便评审老师查看。

7.4 完整交付包目录

结合标题提到的“完整项目源码+SQL脚本+接口文档”，一个清晰的可交付包应该长这样：

EnglishApp/ ｜-- 01-源码/ ｜ ｜-- backend/ ｜ ｜-- frontend/ ｜-- 02-数据库/ ｜ ｜-- english_app.sql ｜-- 03-接口文档/ ｜ ｜-- 接口文档.md ｜-- 04-部署说明/ ｜ ｜-- README.md ｜-- 05-演示/ ｜ ｜-- 演示视频.mp4

源码和SQL脚本保证项目能跑，接口文档保证项目能看懂，部署说明保证项目能换环境复现。把这三样东西结构完整地交付出去，整个毕设的完成度一下子就上来了。

8. 从零跑通项目的完整流程与常见坑：拿到源码之后的第一步

8.1 环境准备清单

拿到一份SpringBoot+Vue的SpringBoot项目源码，第一步是检查本地环境，别急着敲命令。通常需要准备下面这些东西：

版本建议不是绝对，但如果你完全按我列表里的版本环境来，出问题的概率最低。特别是Node版本，前端项目如果用了旧版本node-sass，新版本Node往往会编译失败，这是最典型的坑之一。

8.2 导入SQL脚本与修改配置

先把SQL脚本在MySQL中执行。使用命令行或数据库可视化工具都可以，关键是要保证整份脚本无报错执行。然后打开后端的application.yml，修改数据库连接信息：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/english_app?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 你自己的密码 driver-class-name: com.mysql.cj.jdbc.Driver

这里有几个容易踩的坑：

• MySQL 8.0的默认加密方式导致连接失败，需要加上allowPublicKeyRetrieval=true。
• 编码和时区不对会导致中文乱码和日期错误，characterEncoding=utf8和serverTimezone=Asia/Shanghai最好都带上。
• 端口被占用可以在server.port处修改，前端代理也要同步调整。

8.3 启动后端与前端

后端启动有两种方式：在IDEA里直接运行Main启动类，或者在项目根目录执行：

mvn spring-boot:run

控制台出现Spring Boot启动成功的日志后，后端就正常了。

前端启动需要先安装依赖，然后启动开发服务器：

npm install npm run dev

启动后浏览器访问前端地址，比如http://localhost:8081。前端和后端端口不同，如果没有配置跨域，就需要在前端配置文件里设置代理。以Vue CLI项目为例，在vue.config.js中配置：

module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

配置完成后，前端请求/api/xxx时会被自动转发到后端8080端口，不会出现跨域问题。

8.4 实际运行中常见的坑与排查方法

我把实际运行中经常遇到的问题整理成一张表，方便按图索骥：

排查时要养成看日志的习惯。后端日志明确记录了每个请求和异常位置，前端调试工具里Network面板能直观看到请求和响应。把日志和Network面板结合起来看，大部分问题都能在十分钟内定位。

9. 复盘：答辩时会被追问的高频问题与扩展方向

9.1 高频答辩问题及应对思路

项目做完、演示跑通之后，答辩才是真正的考验。我在前面提到的种种设计细节，几乎都是答辩问题的来源。整理几个高频问题，换个提问角度都是在考“为什么这么设计”：

• “登录为什么要用JWT，Session不可以吗？”可以从无状态、服务端扩展、小程序/移动端复用等角度回答。
• “分页查询是怎么做的？”可以讲MyBatis-Plus分页插件、MySQL的limit机制、前端如何传递页码参数。
• “密码存在数据库里安全吗？”可以讲BCrypt加盐哈希，以及为什么不能用MD5裸存。
• “错题本的表结构为什么这么设计？”可以解释为什么单独建表、为什么不直接存历史记录。
• “如果用户量很大，系统哪里会是瓶颈？”可以提到数据库索引、分页查询、部署拆分为进程等扩展思路。

这些问题没有标准答案，关键是你要真的亲手实现过。只要你把项目里的每张表、每个接口都自己梳理过一遍，答辩时基本不会无话可说。

9.2 这个项目还能往哪些方向扩展

完成一个能跑的毕设只是起点。如果你学有余力，或者想让它成为简历上的亮点，可以考虑几个扩展方向：

• 接入Redis，用户登录token实现自动续期，首页热词和每日一句做缓存。
• 接入在线词典或翻译接口，让词汇页显示更多例句和发音资源。
• 增加学习路径推荐逻辑，根据用户做对题目的难度动态推荐下一组练习。
• 把项目部署到云服务器，使用Nginx托管前端、运行后端jar包，实现公网访问。
• 做一个长期维护的版本，补充单元测试、自动化部署脚本等工程化内容。

这些方向不需要全部做，选一两个深入，效果就比堆功能好得多。

最后说一点个人体会。我帮人看过不少类似的项目，发现最后能拿高分或者在面试里讲明白的同学，通常不是代码写得最炫的人，而是能清楚地解释每一张表为什么这样设计、每一个接口为什么返回这个结构的人。这个英语知识应用网站，代码部分其实中规中矩，真正的门槛在于你能不能把“词汇学习—在线练习—错题记录—学习统计”这条链路讲透。把上面提到的每个问题都自己实操和推演一遍，你对SpringBoot+Vue前后端分离项目的理解，会比只看课程代码深刻很多。