企业官网建设流程全解析

1. 项目全貌与定位拆解

先把话说在前面：如果你正为Java Web毕设发愁，或者想找一个能完整落地、答辩时经得起追问的前后端分离项目来参考，那么“SpringBoot + Vue 三国之家网站平台”这套东西，可以当成一个非常标准的样本来看。它不是什么炫技项目，而是把最主流的Java后端技术栈、最常见的内容型网站需求、最稳妥的前后端分离架构全部串在了一起。做完这一套，你对整个Web开发流程的理解会清晰很多。

这个项目的核心是什么？说白了，就是一个以三国文化为主题的“内容展示 + 用户互动 + 后台管理”的三层结构站点。前台面向普通游客，展示三国人物、经典战役、文化典故、图文资讯；用户注册登录后可以收藏、评论、点赞；后台管理员则负责维护这些内容。技术上就是SpringBoot提供RESTful API，Vue负责页面渲染和数据交互，MySQL存放所有数据，再用一份SQL脚本把表结构和初始数据一次性初始化好。

为什么说这个选题很聪明？做毕设最怕两件事：一是题目太虚，答辩时讲不清楚业务逻辑；二是范围太大，做到一半发现收不住。三国文化站点这个主题，业务边界非常清晰，数据模型有天然的“分类—详情—关联”结构，非常适合演示增删改查、分页搜索、关联查询、登录鉴权这些Java Web的核心知识点。而且内容数据都是现成的历史常识，不需要你苦想测试数据怎么造。

这套项目适合谁？如果你是一个对SpringBoot和Vue都只有基础了解、想通过一个完整项目把两者打通的人，或者正在准备毕设、需要一个能说清楚设计思路的参考项目，那这篇文章就是写给你看的。我会从选型思路、数据库设计、后端接口实现、前端页面落地、部署运行，一直讲到答辩时容易被追问的问题，尽量把每个环节的“为什么这么做”都拆开讲明白。

1.1 毕设选题思路：为什么选“内容型站点”而不是“管理系统”

很多同学选题时第一个念头就是“XX管理系统”——学生管理系统、图书管理系统、仓库管理系统。这种题目不是不能做，但普遍存在两个问题：一是功能同质化严重，两个管理系统拿出来对比，页面结构几乎一模一样；二是业务逻辑太简单，基本就是单表CRUD（增删改查），答辩时老师一句“你的系统难点在哪里”就能把你问住。

而你回头看“三国之家”这个定位，它表面上是一个资讯展示站，实际上是一个带多角色权限的内容管理平台。游客有游客的视角，用户有用户的互动能力，管理员有后管的维护能力。这就自然形成了三种不同的API权限级别，让你有理由去设计登录鉴权、拦截器、权限校验这些环节。更重要的是，三国主题让数据天然具备“一对多”（一个人物对应多个事件）、“多对多”（一个战役关联多个人物）的关联关系，这正好可以顺理成章地讲清楚表结构的关联设计。

另外一个隐性好处是演示效果。答辩现场时间有限，管理系统类的项目演示起来就是机械地“增删改查”，而内容型站点打开首页就有视觉冲击力，轮播图、人物卡片、详情页、搜索联想，一页一页翻下来，老师能直观看到你的前端能力和页面交互设计。人都是视觉动物，第一印象很重要。

1.2 技术选型拆解：这套组合到底稳在哪里

先看技术栈清单：后端是SpringBoot 2.x + MyBatis Plus，前端是Vue 2 + Element UI + Axios，数据库是MySQL 5.7 / 8.0，接口文档用Swagger生成，构建工具后端Maven、前端npm。这套组合在Java Web毕设圈子里属于“国民级”搭配，选它不丢人，但也不是随便选的。

SpringBoot的价值不用多说，内置Tomcat、自动配置、约定优于配置，让一个Java Web项目从创建到跑起来只需要几分钟。它把Spring MVC、事务管理、参数校验这些底层细节都打包好了，你能把精力集中在业务实现上，而不是纠结配置文件写在哪里。

MyBatis Plus选得非常聪明。纯MyBatis写简单的单表查询都要手写SQL，效率低；而MyBatis Plus提供了通用的Mapper接口和条件构造器，像分页查询、批量插入这些高频操作，基本不用自己写SQL。同时它还保留了我自己写XML SQL的灵活性，复杂查询（比如多表关联、统计报表）依然能手动控制。对于毕设这种需要快速实现、又要有一定展示深度的项目，这个度拿捏得刚刚好。

前端Vue加Element UI的好处是组件生态成熟。Element UI的表格、表单、弹窗、分页、菜单组件开箱即用，后管页面基本是拼组件就能完成。Axios做HTTP请求封装，配合拦截器统一处理token注入和错误提示，代码看起来很规整。整套组合对新手最大的友好之处在于：遇到问题搜索即有答案，资料量巨大，几乎不会卡死你超过半天。

1.3 功能模块规划：前台、用户端、后台三层边界

拆功能模块是开工写代码前必须做的一步，别一上来就建工程写Controller。我把三国之家的功能划分为三个区，每个区有清晰的权限边界：

前台游客区：首页轮播推荐、三国人物列表（按势力/身份筛选）、人物详情页（含人物生平、关联战役、相关文章）、战役时间线展示、文化资讯列表与详情、全局搜索。游客不需要登录就能浏览这些内容，这是网站的门面，也是SEO友好的部分。

用户中心区：注册、登录、个人资料编辑、我的收藏、我的评论记录。登录用JWT（JSON Web Token）做无状态认证，前端把token存在localStorage，每次请求带在请求头里。收藏和评论是内容型网站用户粘性的核心，这两个功能做出来，前后端交互的完整度一下子就上来了。

后台管理区：管理员登录、仪表盘统计（用户数、文章数、浏览量）、人物管理、战役管理、资讯管理、评论审核与删除、用户管理。后台不追求花哨，重点是条理清晰、权限受限，管理员能对前台所有内容进行“增删改查”，这正好覆盖了Java Web大纲里的全部核心考点。

2. 数据库设计与SQL脚本要点

数据库设计是一切的根基。很多同学急于写代码，到了联调阶段才发现表结构不合理，回头改起来极其痛苦。我先说你最关心的问题：一份完整的SQL脚本应该包含哪些东西？

好的SQL脚本绝对不是单纯把建表语句粘在一起。它至少要有：SET FOREIGN_KEY_CHECKS这类兼容性设置、明确的库名和字符集定义（utf8mb4是必须的）、完整的建库建表语句、合理的主外键约束、索引设置、以及一批可以直接跑起来的初始数据。这里面有两个细节最容易被新手忽略：一是字符集不统一会导致中文乱码，二是初始数据里必须包含一条管理员账号，否则项目部署后你登录不了后台，还得临时去数据库手动插入。

2.1 三国内容型站点的表结构设计思路

我在设计这套项目的数据模型时，第一原则是“从页面反推表结构”。前台页面需要展示什么数据，表就怎么建。比如首页要展示轮播图，就有一张banner表；人物列表要按势力筛，那人物表就必须有country_id这个外键字段；人物详情页要展示关联战役，那就不能把战役信息硬塞进人物表，而是通过关系表来关联。

核心表我拆成这样：

用户表（sys_user）：id、用户名、密码（这里必须用BCrypt加密，不能明文存）、昵称、头像、邮箱、角色标识（管理员还是普通用户）、创建时间。

人物表（hero）：id、姓名、字、籍贯、身份、势力外键、生卒年、生平简介、性格特点、形象图URL、浏览量。

战役表（battle）：id、名称、交战双方、时间、地点、背景介绍、过程描述、影响分析、参战人物（通过关系表和人物表多对多关联）。

资讯表（article）：id、标题、封面图、分类、摘要、正文内容、发布人、发布时间、阅读量。

评论表（comment）：id、内容、用户外键、目标类型（是评论人物还是评论资讯）、目标主键、父评论id（支持楼中楼回复）、创建时间。

收藏表（favorite）：联合主键，user_id加target_type加target_id。

势力表（kingdom）：id、名称、图标、简述、创建时间。

轮播图表（banner）：id、图片、跳转链接、排序号、状态。

这套表基本覆盖了一个内容型网站的所有核心实体。你注意观察，我没有设计一个巨大的“文章表”把所有内容塞进去，而是把人、战役、资讯拆成不同的实体，用外键和关联表去维系关系。这就叫合理的业务建模。

2.2 SQL脚本细节：字符集、外键与初始数据

写SQL脚本时有个常见的坑：直接复制网上别人建表语句，里面的字符集还是latin1或者utf8。中文内容一旦写入就是问号。我在脚本里统一用了utf8mb4，这个字符集不仅支持中文，还支持emoji和生僻字，属于现在最稳妥的选择。建表语句长这样：

CREATE TABLE `hero` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '人物姓名', `style` varchar(50) DEFAULT NULL COMMENT '人物字号', `country_id` int(11) DEFAULT NULL COMMENT '所属势力ID', `birth_year` varchar(20) DEFAULT NULL COMMENT '生年', `death_year` varchar(20) DEFAULT NULL COMMENT '卒年', `intro` text COMMENT '人物简介', `personality` varchar(500) DEFAULT NULL COMMENT '人物性格', `image` varchar(255) DEFAULT NULL COMMENT '人物图片URL', `view_count` int(11) DEFAULT '0' COMMENT '浏览量', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_country` (`country_id`), CONSTRAINT `fk_hero_country` FOREIGN KEY (`country_id`) REFERENCES `kingdom` (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='三国人物表';

这里注意三个细节：第一，字段注释一定要写，这不仅是规范问题，更是后期维护时省脑力的关键；第二，外键约束要建，但建立之前要想清楚——人物表关联势力表用外键没问题，因为一个人物必然属于一个势力，但业务上不允许删除有子记录的势力表，所以外键更新策略要慎重；第三，索引建在经常查询的字段上（如势力、人物姓名），这是后期搜索性能的基础。

初始数据怎么造？我的习惯是造“够用且有代表性”的数据。以三国人物为例，每个势力挑3-5个代表角色，像蜀汉的刘关张、诸葛亮，曹魏的曹操、司马懿、张辽，东吴的孙策、周瑜、陆逊。每个角色的简介控制在200字左右，别写太多，否则数据库导入费时、页面渲染也不好看。管理员账号固定为用户名admin、密码123456（用BCrypt加密后的字符串写在SQL里），首次部署后直接登录再改密码即可。

2.3 常见设计错误复盘

表结构这块我见过不少翻车案例，集中说几个，你写的时候主动避开。

一是把用户角色的判断直接写在前端代码里。前端判断只是为了让UI有区分，真实的权限校验必须在后端接口做。后端有个别同学图省事，管理员接口全靠前端“隐藏入口”来保护，接口地址被人试出来就能直接调用。正确做法是SpringBoot里配拦截器或Spring Security，对/admin/**路径做登录和角色双重校验。

二是过度设计关联关系。三国人物和战役确实是多对多关系，但没必要为每对关系都建一张“连接表副本”。一个人物参与多个战役，一个战役有多个参战人物，用一张hero_battle_rel表就够，字段就是hero_id、battle_id外加一个备注（比如“该人物在此战役中的角色”）。

三是时间字段类型乱用。有的人把发布时间设计成varchar存字符串，查询没法做排序和范围筛选。直接用datetime类型，配合MyBatis Plus的自动填充功能，插入和更新的时候自动带出时间，省心且不出错。

3. 后端SpringBoot实现干货

后端代码是最能体现你Java基础的部分，也是答辩时老师最关注的部分。三国之家的后端我按标准的三层架构来组织：Controller层接收请求、Service层处理业务逻辑、Mapper层操作数据库。包名建议这样：controller、service、mapper、entity、dto、vo、config、common。

3.1 项目分层与统一响应结构

有一个细节如果你做好了，整个代码的规范程度会看上去专业很多：统一响应的Result对象。也就是说，所有接口的返回值不直接返回实体数据，而是包一层固定的JSON结构：

public class Result<T> { private Integer code; // 状态码：200成功，500失败，401未登录 private String message; // 提示信息 private T data; // 实际数据 }

这样做的好处立竿见影。前端Axios拦截器只需要判断code是否为200就能决定统一的成功提示或错误提示，不需要每个页面重复写错误处理逻辑。状态码的约定要提前想好：200成功、401未认证、403无权限、500服务器异常，你在接口文档里写清楚，前后端联调时就不会出现“明明返回数据了前端却报错”的尴尬。

Controller层的写法也有讲究。别把业务逻辑写在Controller里，一个方法只做一件事：接收参数、校验参数、调用Service、返回Result。参数校验能用JSR303注解（@NotBlank、@NotNull）就用注解，还能顺手把校验失败的错误信息统一处理了。

Service层是我写代码时花时间最多的地方。以人物列表接口为例，它的逻辑不是直接把selectPage结果返回，而是要组装VO（视图对象）。比如人物实体里只存了country_id，但前端列表页需要显示势力名称，那我就在Service里把这个字段翻译成“势力名”，而不是让前端再发一次请求去查。这种“一次请求拿到页面需要的所有数据”的设计，是前后端分离项目里很重要的思维习惯。

3.2 分页、搜索与多条件筛选的实现方案

内容站点最核心的接口就是列表查询。三国人物列表需要支持按势力筛选、按关键词搜索、分页展示这三个能力。我用MyBatis Plus的分页插件实现，配置一个拦截器就能用：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

接口接收三个参数：currentPage、pageSize、keyword和countryId这些条件参数。Service里的写法用LambdaQueryWrapper条件构造器：

LambdaQueryWrapper<Hero> wrapper = new LambdaQueryWrapper<>(); if (StrUtil.isNotBlank(keyword)) { wrapper.and(w -> w.like(Hero::getName, keyword) .or().like(Hero::getStyle, keyword)); } if (countryId != null) { wrapper.eq(Hero::getCountryId, countryId); } wrapper.orderByDesc(Hero::getViewCount); Page<Hero> page = heroMapper.selectPage(new Page<>(currentPage, pageSize), wrapper);

这段代码逻辑不复杂，但有两个细节值得说。一是条件判断里“if不为空才拼接条件”的写法，这是为了防止用户不选势力时SQL里多出country_id = null这种错误条件；二是关键词搜索同时匹配姓名和字号，让搜索结果更人性化——用户搜“曹操”能出结果，搜“孟德”也能出结果。

3.3 登录鉴权与JWT实现细节

登录鉴权是Java Web毕设里最容易被问出深度的点。我这个项目用的是JWT方案。简单说，用户登录成功后，后端生成一个加密的字符串token返回给前端，前端存起来，后续每次请求在请求头里带上这个token，后端拦截器解析token确认用户身份。

JWT的好处是无状态，后端不存session，适合前后端分离的场景。实现分三步：

第一步，登录接口校验用户名密码。密码用BCrypt加密存储，校验时调用BCryptPasswordEncoder的matches方法比对明文和密文。校验通过后生成token：

String token = Jwts.builder() .setSubject(user.getUsername()) .claim("userId", user.getId()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 3600_000 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

第二步，写一个拦截器（HandlerInterceptor），对需要鉴权的路径做前置校验。解析请求头里的token，解析成功就把用户信息放入ThreadLocal，方便后续代码获取；失败则直接返回401状态码和提示信息。

第三步，注册拦截器，设置放行名单。放行名单包括登录注册接口、前台所有的GET请求接口，拦截的是后台管理类路径和用户操作类路径（评论、收藏等）。注意一个坑：如果你放行名单里漏了某个静态资源路径，前端页面就会莫名出现“登录失效”的报错，排查起来很耗时。

3.4 接口文档的整理思路

说到接口文档，Swagger集成是最省事的方式。在pom.xml引入springfox依赖，写个配置类开启Swagger，Controller加上@Api注解、参数加上@ApiParam注解，启动项目后访问/swagger-ui.html就能在网页上测试所有接口。

不过我得说句大实话：Swagger自动生成的文档，结构上往往比较扁平，适合开发期自测，不太适合直接打印出来当答辩文档。更好的习惯是自己在项目里维护一份Markdown格式的接口说明，按模块分类写明每个接口的URL、请求方法、请求参数、返回示例。写一遍这个文档，你对项目接口的全局记忆会清晰很多，答辩时面对“你这个接口是怎么设计的”这类问题完全不慌。接口文档的目录我建议按“前台接口”和“后台接口”分大类，每个模块下再列点。

4. 前端Vue页面落地

前端部分要拆成两套独立的Vue工程更合理：一套是面向游客和用户的main-ui前台，另一套是admin-ui后台管理。两个工程共用同一套API请求封装，但路由和页面结构完全不同。用Vue CLI初始化的项目会自带目录骨架，src下放components、views、router、store、api、utils这几个目录。

4.1 路由设计与导航守卫

前台路由我用vue-router的history模式，但要注意一个问题：前端history模式刷新某个深层页面时会报404，因为后端Tomcat不认识这个路径。解决方法是后端配置一个转发：把非API的路径全部转发到index.html。如果不做这个配置，用户从人物详情页按F5刷新就会白屏，这是个能让你在联调阶段卡上两小时的小坑。

路由的另一个重点是导航守卫。页面跳转前先判断token是否存在，如果没有token且目标页是需要登录的页面（比如收藏列表），就用router.beforeEach拦截并跳转到登录页。注意判断要在next()之前完成，否则会出现路由闪烁或无限重定向的问题。我写过比较成熟的范式是：白名单路径直接放行，其余路径检查token，token存在且去的是登录页就跳回首页，避免“已登录用户还能访问登录页”的体验问题。

4.2 Axios封装与状态管理

Axios封装是个老生常谈但真不能跳过的事。项目里每个请求如果都写一遍axios.get那也不是不行，但一旦需要统一处理401跳转或者统一提示错误，你就得满项目去改。我一般这样做：创建axios实例，设置baseURL和超时时间；请求拦截器里从localStorage取token并加到请求头Authorization字段；响应拦截器里统一判断Result的code，200就放行，401就清除本地登录信息并跳转登录页，其他code统一弹出错误提示。

Vuex我用来存用户基本信息（用户名、昵称、头像、角色），登录成功后commit一个mutation把信息存进store，同时持久化到localStorage。页面里拿用户信息从store取即可，不需要每个页面都解析一次token。

4.3 前台核心页面实现思路

前台页面我用Element UI的Layout组件搭整体框架。顶部导航栏包含Logo、菜单（首页、人物、战役、资讯）、搜索框、登录注册入口。左侧或右侧视页面需要放筛选栏。

人物列表页是最核心的页面。筛选栏是几个下拉框（势力选择、身份选择），配合一个跳转搜索按钮。卡片列表用el-card一行三列展示人物头像、姓名、势力标签、简介摘要。点击卡片跳转到人物详情页。

人物详情页要处理好“详情 + 关联 + 互动”三个区域。详情区展示基本信息表格和长篇生平文字；关联区展示该人物参与过的战役时间线，以及相关的资讯文章列表；互动区是评论组件和收藏按钮。这个页面最能展示你数据库关系设计的合理性和前端组件拆分能力。

评论组件我单独提一下，因为它是前后端交互比较复杂的场景。设计上需要支持四级能力：发表新评论、楼中楼回复、删除自己的评论、管理员删除任意评论。前端用递归组件来渲染树形评论结构，后端用父评论id把评论串成树。这里有个经验：后端一次把某个模块下的所有评论查出来，在内存里组装成树形结构返回给前端，别用递归查询数据库，否则评论一多接口就慢。

后台管理页面的模块相对固定：左侧菜单放仪表盘、人物管理、战役管理、资讯管理、评论管理、用户管理。每个管理页面基本都是“搜索条件区 + 数据表格 + 分页 + 新增/编辑弹窗”四段式结构。用Element UI的el-table、el-dialog、el-form组合实现，你写一次就会形成肌肉记忆。

5. 部署运行与问题排查

一个毕设项目从代码写完到能演示，中间还有一段部署的坎。我把运行环境和问题排查经验一次说全，省得你自己踩坑。

5.1 本地环境搭建与启动步骤

环境准备清单：JDK 1.8或11、Maven 3.6+、Node.js 14+、MySQL 5.7或8.0、Navicat或MySQL Workbench、IDEA或VS Code。版本需要注意匹配，比如SpringBoot 2.x配JDK 8/11没问题，Node版本太高有时会导致依赖安装失败。

启动步骤按顺序来：

第一步，初始化数据库。打开Navicat，新建连接，创建一个名为sanguozhijia的数据库（utf8mb4字符集），然后选择运行SQL文件，把项目里的sanguo.sql导进去。导入完成后查看表列表，确认十几张表都建出来了、数据也有，再继续下一步。

第二步，启动后端。用IDEA打开backend目录，确认Maven配置成功（settings里的镜像源最好换一下，否则依赖下载速度教你做人）。修改application.yml里的数据库用户名和密码，改成你自己的。然后运行启动类，看到控制台出现“Started Application”的日志，说明后端起来了。测试方式：浏览器直接访问http://localhost:8080/api/hero/list，能返回JSON数据就通了。

第三步，启动前端。进入frontend-main目录，命令行依次执行npm install（装依赖）和npm run serve（启动开发服）。看到编译成功的提示后，访问http://localhost:8081就能打开前台首页。前端访问后端，通过vue.config.js里配置的proxy代理转发，把/api开头的请求代理到8080端口，这样可以绕开跨域问题。

5.2 联调阶段的高频报错排查

联调时踩得最多的坑，我按频率排个序：

第一个是跨域报错。现象是浏览器控制台报“CORS policy: No 'Access-Control-Allow-Origin' header”。这个问题的原因是前端的域名端口和后端不一致，浏览器出于安全策略阻止了跨域请求。解决方式我推荐用后端加CorsFilter配置统一放行，或者前端用proxy代理转发。我用的是后者，因为proxy配置只在开发环境生效，生产部署时Nginx本来就会做请求转发，不用改后端代码。

第二个是中文乱码。现象是查出来的数据中文全部变成“???”。大概率是数据库表和字段的字符集没设成utf8mb4，或者JDBC连接的characterEncoding没设置。在JDBC连接串里加上characterEncoding=utf8是基本配置，表设计的字符集也得一致。还有一种隐蔽情况是前端页面没设置meta charset，导致浏览器用默认编码解析HTML。

第三个是前后端字段对不上。前端要的是“createTime”，后端实体里的字段叫“create_time”。MyBatis Plus默认开启了驼峰命名映射（map-underscore-to-camel-case=true），数据库字段自动映射到实体的驼峰属性。如果你发现某个字段死活取不到值，去确认application.yml里这个配置是否开启。

第四个是刷新页面404。这个问题我在前面提到过，解决方式是后端加一个路由转发配置，把非API的路径全部转发到根路径下的index.html。

第五个是npm install报错。最常见是node-sass安装失败。解决办法是换成sass（dart-sass），或者用淘宝镜像源安装。如果还不行，检查Node版本是否过高，必要时降级到稳定版本。

6. 答辩常见问题与经验补充

做毕设不只是写代码，答辩前的准备同样重要。这部分我把自己在指导过程中总结的高频问题，以及我个人的实操体会分享出来。

6.1 老师最爱追问的几个点

“你的项目用什么方法解决跨域问题？”这是最容易被问到的基础题。你不能只说“用了代理”，要能说清楚为什么需要处理跨域——浏览器同源策略导致的请求限制，然后讲如何用proxy实现开发环境的跨域解决，以及如果上线部署，Nginx反向代理是怎样统一入口的。

“为什么选择JWT做登录认证而不用Session？”这道题考察你对有状态和无状态认证的理解。核心回答是：Session存储在服务器端，分布式环境下需要session共享；JWT自带签名、不需要服务端保存状态，适合前后端分离。但要补充“无状态”的代价——token无法主动失效，所以需要考虑过期时间设置。

“你项目里的权限是怎么控制的？”要分层回答：前端通过路由守卫控制页面访问；后端通过拦截器对需要登录的接口做token校验；管理接口再校验角色字段是否为管理员。三层防线缺一不可。

“数据库为什么这么设计表？”这是展示你设计能力的重点题。从业务场景说起——前台页面需要什么数据，因而需要有hero、battle、article这些表；然后说关系——人物与战役的多对多关系用关联表维护；最后说规范——字段类型的选择、索引用在哪些高频查询上。

“MyBatis Plus和MyBatis的区别是什么？”简答：MP提供了通用Mapper和条件构造器，单表操作不用写SQL；但复杂的多表查询仍然要自己写XML。这正好体现你对工具的理性认识，而不是盲目吹捧。

6.2 演示时的加分操作

演示环节的节奏要有设计，别一上来就登录后台一通操作。我先演示前台首页的浏览体验，让页面自然展示轮播图、人物卡片、搜索功能；接着演示搜索“诸葛亮”这个关键词如何联动到人物详情页，在详情页展示评论功能并顺带完成一次登录注册；最后登录管理员账号，展示后台管理的核心功能——新增一个人物、修改资讯、审核评论。

演示有个细节：把数据库里的数据量造得“看起来像真的”，人物三四十个、战役二十几个、资讯每类五六篇，页面滚起来内容丰富，老师第一印象就会好。数据太少会显得假，数据太多你演示时也不好定位。

演示之前养成清理后台的习惯：删掉测试垃圾数据、把管理员界面上的无关log清掉、浏览器清理缓存，这些小事能避免关键时候出洋相。

6.3 功能扩展空间

答辩时被问“你后续有什么扩展想法”，别只说“我还会继续完善系统”这种空话。给出具体的技术方向会加分不少：把人物详情页的数据改为按时间轴动态生成，增强历史感；引入ElasticSearch做全文搜索，解决like查询在数据量大时的效率问题；增加图片上传功能接入对象存储；前端用TypeScript重写提升代码可维护性。这些方向不需要你真做出来，但能证明你对技术演进有思考。

最后再分享一点个人体会：很多人在毕设阶段总想加功能、求炫技，Caffeine缓存、Redis队列、RabbitMQ消息推送全都想往上塞。但以我指导过的项目经验来看，毕设的核心评价标准从来不是功能多，而是逻辑通、结构对、讲得清。把SpringBoot + Vue这套组合的基本功打扎实，把数据库关系理清楚，把接口设计得规范，把答辩的十几个问题准备到位，一个体面的毕设就稳了。如果这篇文章帮到了你，或者你在部署和联调过程中遇到了上述清单之外的坑，可以顺着这套项目的“接线图”再自己捋一遍，往往问题就出在那条你还没走过的线路上。