企业官网建设流程全解析

“三国之家”这种选题在毕业设计里属于那种看似传统，真正做起来才发现处处要下功夫的类型。标题里给出的是源码、SQL脚本、接口文档三件套，但它真正的价值不在于你打包提交多少个文件，而在于整个SpringBoot+Vue的链路是否完整、是否可以运行、是否能在答辩现场扛住追问。这篇文章主要面向两类人：一是还没定题、正在找Java Web全栈毕设方向的学生；二是已经拿到类似源码但不知道怎么改、怎么部署、怎么讲清楚的二开选手。我会从项目选题、技术选型、数据库设计、后端接口、前端页面到部署演示，把整套链路拆开讲透，并且把我实际开发中踩过的坑、调过的参数、改过的方案一起放出来，给后来者一个真正能落地的参考。

1. 毕设选题的取舍：为什么是“三国之家”而不是购物商城

1.1 烂大街选题与“伪创新”选题之间，第三条路在哪

每年毕业设计选题季，Java Web方向最不缺的就是两类题目：一类是图书管理系统、网上商城、学生选课系统，这类题目优点是教程多、资料全，缺点是一答辩评委就知道你是照着某套模板换皮；另一类是“基于人工智能的什么什么系统”“基于大数据的什么什么平台”，这类题目听起来高级，但以本科阶段的能力范围，很容易做成只有一个接口调用、没有核心逻辑的伪需求。

“三国之家”这个方向的聪明之处在于，它落在一个有明确内容边界的垂直领域里，既不是烂大街的商城，也不是悬空的“平台”。三国题材本身包含人物、战役、武器、事件、势力、文章等多维数据，天然适合做信息展示、分类检索、后台管理、用户互动这几类功能，而这些功能恰好覆盖了Java Web课程设计一直强调的知识点：增删改查、分页搜索、文件上传、权限控制、前后端分离。换句话说，这个题目能让你把技术栈完整演一遍，同时又有一个足够吸引眼球的内容包装。

1.2 这个题目到底在练什么：从用户端到管理端的完整闭环

很多同学拿到“某某之家”模板后，只关心页面好不好看，忽略了项目真正的骨架是业务闭环。以这套平台为例，前台要有三国人物浏览、战役事件时间轴、武器百科、文章资讯、关键词搜索，用户要能注册登录、收藏人物、发表评论；后台要有内容管理、用户管理、轮播图配置、系统设置。这些需求拆开后，你会发现它就是一个微缩版的门户网站，比单一商城多了内容权重，比简单博客多了多模块管理。

从技术训练的角度看，它逼着你把下面这几个问题想清楚：第一，人物、战役、武器、文章这些实体之间是什么关系，怎么设计外键和关联查询；第二，前台哪些接口需要登录才能访问，后台接口如何识别管理员身份；第三，Vue前端如何组织路由和组件，才能让游客和管理员看到不同的页面。这些问题只要有一个没想透，项目跑到中间就一定会卡壳。

1.3 适合谁拿去做二开和参考

如果你是打算自己从零写，这套思路可以帮你少走弯路；如果你已经拿到了同款源码，最重要的是弄清楚每个文件的角色，而不是急着改页面。我的建议是，在动手之前先把数据库脚本逐行看一遍，再用接口文档对照着跑一遍后端，最后再看前端路由和API调用。这个顺序能让你在最短时间内建立“数据从哪里来、接口怎么返回、页面怎么消费”的整体认知，后面改起来才不至于抓瞎。

2. 技术栈定版与技术骨架：先把脚手架立起来

2.1 SpringBoot、Java、Vue、MySQL版本搭配才是第一道坑

很多毕设翻车不是死在业务逻辑，而是死在版本兼容。先说我推荐的组合：后端SpringBoot 2.7.18搭配Java 8或Java 11，前端Vue 3.2搭配Vite 5和Element Plus，数据库MySQL 8.0，接口文档用Knife4j。这套组合的稳定性经过大量实践验证，网上资料最全，遇到问题也最好搜。

有的人会问，为什么不用SpringBoot 3.x？SpringBoot 3.0起强制要求Java 17，如果你的电脑和服务器上装的还是Java 8，部署时就会多出一堆环境折腾。毕设阶段求稳是第一位的，没必要为了追新版本浪费一周时间调兼容性。当然，如果你的环境已经具备Java 17，选SpringBoot 3.x也没问题，只是下面的示例我会以2.7版本为主来写。

2.2 后端工程分包：别把代码堆成一个万能包

拿到源码第一件事，先看后端项目的包结构。一个清晰的后端工程，至少应该包含这样几个包：controller放接口入口，service放业务逻辑，mapper放数据库操作，entity放实体类，config放配置类，common放统一返回体和异常处理，util放工具类。如果某个源码把几百个类全塞在一起，那你后面每改一行代码都会担心影响别的地方。

我自己习惯用一个叫“项目模块化”的思路来控制分包：按业务模块竖切，而不是按技术层横切。以这套项目为例，人物模块下应该有PersonController、PersonService、PersonMapper、Person实体；战役模块同理。这样的好处是，答辩时评委问“人物搜索是怎么实现的”，你能立刻指出对应的类和代码行，而不是在几个包之间来回跳。

@SpringBootApplication @MapperScan("com.sanguo.mapper") public class SanguoApplication { public static void main(String[] args) { SpringApplication.run(SanguoApplication.class, args); } }

启动类里的@MapperScan这行很关键，它让MyBatis自动扫描到所有的Mapper接口，少写一行漏掉一个，项目启动就会报找不到Bean的错误。这是新手最容易卡住的第一个点。

2.3 前端初始化：Vite创建项目与目录规划

前端部分用Vite创建Vue项目的命令非常简单：

npm create vite@latest sanguo-web -- --template vue cd sanguo-web npm install

装完基础依赖后，我基本上都会再装这几样：vue-router做路由，pinia做状态管理，axios发请求，element-plus做UI组件。目录方面，src下分成views、components、router、store、api、utils六个目录。views放页面级组件，components放可复用组件，api目录按后端模块拆分接口定义。很多同学喜欢在一个文件里既发请求又写页面逻辑，短时间看着省事，后面维护起来非常痛苦。

路由规划上，我建议从第一天就按“前台门户、内容详情、后台管理”三大块来划分。前台路由包括首页、人物列表、人物详情、战役列表、武器百科、文章资讯；后台路由独立挂载在一个/admin前缀下，并通过路由守卫判断管理员身份。后面说前端联调时我会再展开讲路由守卫怎么写。

3. SQL脚本拆解：三国领域模型如何在数据库里立起来

3.1 用户、角色与操作日志：先保住平台的“人”

拿到SQL脚本后，我建议先不要急着看三国相关表，而是从用户侧开始读。用户表、角色表、用户角色关联表这三张表构成了平台的身份体系。用户表里除了username、password、nickname之外，我特别推荐加上status字段做账号状态控制，一个值代表正常，一个值代表禁用。别小看这个字段，后台要封禁某个恶意用户时，如果没有它，你就只能物理删除数据，这会让后续所有关联数据一起出问题。

密码字段长度建议设置为60或64。这不是随手写的长度，而是BCrypt加密算法生成的哈希值固定是60个字符。如果你把字段长度定成20，那密码一存进去就会被数据库截断，注册明明成功，登录永远说密码错误。这类由字段设计引发的bug，排查起来非常浪费时间。

用户行为方面，如果想让项目在毕设答辩里更有说服力，我建议加一张操作日志表。这张表用几个字段记录用户ID、操作类型、操作内容、操作时间即可。前台用户收藏一个三国人物、后台管理员修改一篇文章，都往这张表里插一行。展示出来之后，评委能看到这个项目是有“数据轨迹”的，这在功能演示环节非常加分。

3.2 三国核心内容表：人物、战役、武器、事件的建模细节

三国之家这类内容平台，数据库设计的核心难点在于，内容表之间既有层级关系，又有交叉关联。我见过很多半成品项目只建一张超大的内容表，把所有文章、人物介绍全塞进去，结果前台模块一多，查询逻辑就乱成一团。正确的做法是让每类内容独立成表，再用关联表把关系串起来。

以人物表为例，常见字段有：

战役表和武器表类似，但要注意它们和人物多对多的关系。比如“赤壁之战”关联了周瑜、诸葛亮、曹操等多个人物，一个武器也可能被多个人物使用过。这种关系光靠外键无法表达，必须建中间表。中间表的命名我建议用双实体名组成，比如person_battle和person_weapon，表里放两个外键字段即可。这种设计在MyBatis里对应起来非常顺手，一对多、多对多的嵌套查询都能写清楚。

事件时间轴需要额外加一个排序字段sort_order，用数字控制先后顺序。因为三国历史事件的时间描述有时不是精确年份，可能只到某一年甚至某一阶段，直接在SQL里排序不够灵活，手动指定sort_order反而更可控。前台时间轴组件直接按这个字段升序取数，页面顺序就稳定了。

3.3 关于外键、索引和字段长度：很多博客不会教你的细节

数据库脚本里最容易出问题的，一是外键约束，二是不合理的索引。我的态度很明确：物理外键能不加就不加，逻辑外键优先。不是因为外键没用，而是毕设项目经常要导入导出数据、批量修改数据，物理外键会带来非常多的连锁限制。你可以在表结构注释里写明“该字段关联某表主键”，但不要真正创建FOREIGN KEY，这样既保留了关系语义，又避免了后期调试数据时处处碰壁。

索引方面，人物表的name字段、战役表的title字段、文章表的category字段这三个地方值得加索引。前台搜索基本都是按这些字段过滤，没有索引在数据量小的时候没感觉，一旦导入几百条数据，接口响应时间就明显拉长。但也不要每个字段都加索引，尤其不要对text类型的detail字段加索引，那不仅浪费空间，索引本身也会失去速度优势。

还有一个很常见的坑是字符集和排序规则。整个库统一用utf8mb4，排序规则用utf8mb4_general_ci，这样中文内容才不会有乱码和排序问题。每张表的注释、每个字段的注释尽量写全，因为接口文档有时候描述不清时，数据库注释就是第二份说明书。

4. 后端接口与权限会话：把“能用”变成“可用”

4.1 统一返回体与全局异常：接口文档的第一页应该长这样

前后端分离项目里，接口返回格式不统一是最大的内耗来源。今天这个接口返回{code:0,data:xxx}，明天那个接口返回{code:200,msg:ok}，前端联调时就得一路写if。接手这类项目后，我第一件事就是建立统一返回体，大致结构如下：

{ "code": 200, "msg": "操作成功", "data": { ... } }

后端类名我用Result，内部包含code、msg、data三个字段。所有控制器的返回值都套用这个结构。成功时调用Result.success(data)，失败时调用Result.error(code, msg)。这样前端用axios拦截器统一判断code，等于把所有接口的错误处理做了一次收敛，工作量直接减少一大半。

全局异常处理也是同样的思路。在项目里加一个类，标注@RestControllerAdvice，把业务异常、参数校验异常、系统异常分别写三个处理逻辑。业务异常返回提示信息，参数校验异常返回具体字段错误，系统异常返回“服务开小差”。这个设计一是保证任何情况下接口都返回统一结构，二是防止后端报错堆栈直接暴露给浏览器。

4.2 登录注册与JWT拦截：用户态不做好，内容再多也没用

前端有不少接口需要用户登录后才能访问，比如收藏、评论、后台管理，所以登录注册模块是整个项目的安全地基。密码处理上面提过用BCrypt加密，这里再补充一句：注册接口接收明文密码后，在service层加密再落库，登录接口则用BCrypt自带的方法比对密文。永远不要自己写加密算法，也不要明文存密码。

登录成功后，后端生成一个JWT令牌返回给前端。JWT的好处是无状态，服务器不用保存会话记录。令牌里我习惯只放userId和role两个字段，过期时间设为2小时。前端拿到令牌后存到localStorage，后续每个请求都在Authorization请求头里带上它。后端写一个拦截器，从请求头解析令牌，校验通过就把userId存入请求上下文，校验失败直接返回未登录错误。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/user/login", "/api/user/register", "/api/person/list", "/api/battle/list"); } }

配置里稍微注意一下白名单。前台首页、人物列表、人物详情这些内容接口通常不需要登录，所以要在拦截器里排除。后台管理接口则另外用管理员拦截器保护，判断上下文里的role字段。两个拦截器分开写，职责更清晰，答辩时也更容易讲明白。

4.3 内容管理接口的编写套路：分页、详情、增删改查的标准化写法

内容类接口虽然模块多，但写多了以后你会发现，套路高度一致。拿三国人物模块举例，核心接口无非就是这几个：分页查询列表、查询详情、新增人物、修改人物、删除人物、上下架。分页查询写起来有个细节值得注意，前端传入的pageNum和pageSize要跟PageHelper插件对接，查询方法返回的列表要封装出总条数total，否则前端分页组件没法渲染页码。

@GetMapping("/api/person/list") public Result personList(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, @RequestParam(required = false) String keyword) { PageHelper.startPage(pageNum, pageSize); List<PersonVO> list = personService.search(keyword); PageInfo<PersonVO> pageInfo = new PageInfo<>(list); return Result.success(pageInfo); }

详情接口要考虑关联数据。人物详情页不仅显示基本字段，还要显示这个人参与过的战役和用过的武器。最简单的方案是人物详情接口内部查三张表，然后组装成一个包含List集合的VO对象返回。这种方式代码直白，适合毕设阶段展示逻辑。追求性能可以改造成一条SQL联表查询加嵌套结果映射，但理解成本高一些。我建议毕设阶段先把VO组装方案跑通，性能优化可以作为加分项提一嘴。

新增和修改接口的核心区别在于：新增不传id，修改必须传id。很多源码在这里只做了一层浅拷贝，导致修改时未传入的字段被置空。稳妥的做法是修改前先按id查出旧记录，然后只把前端传来的非空字段覆盖到旧记录上，最后再update。这样即使前端漏传某个字段，也不会误删数据。这个处理我在多套项目里深受其益，强烈建议照抄。

4.4 接口文档怎么组织才不挨批：注解命名与示例

接口文档这个交付物，很多学生习惯最后一天拿Word写一版，结果什么实质信息都没有。正规做法是用Knife4j或Swagger自动生成在线文档，然后在代码里把注解写详实。类上标注模块名称，方法上标注接口说明和参数说明，字段上标注取值范围，比如“状态：0草稿，1发布”。

接口命名规范也值得多说一句。前端所有请求路径统一以/api开头，模块名用复数，资源操作用标准方法：GET/列表和详情、POST/新增、PUT/修改、DELETE/删除。不要出现/queryPerson这种动词风格路径，也不要路径里带中文。一旦接口路径随意命名，文档就会变成天书，前端对接时只能频繁来问你。

文档里每个接口至少要包含一个请求示例和一个返回示例。我自己通常在注解里把典型请求写出来，比如分页列表的请求示例填pageNum=1&pageSize=10，返回示例填一段真实的JSON。这样前端调用时可以直接照抄，不大会出现参数名理解偏差。接口文档写得规范，毕设验收环节其实能少回答很多无效问题。

5. 前端Vue落地：三国内容怎么装进组件树

5.1 页面与路由设计：前台门户、内容详情、后台管理三块怎么切

前端页面如果按照“首页-列表页-详情页”三层来组织，会非常清晰。首页放轮播图、热门人物推荐、最新文章资讯，列表页放分页列表和筛选条件，详情页放完整内容展示。这套结构跟后端接口天然匹配，写起来也顺手。

后台管理页面的路由独立成块，路径统一以/admin开头，页面组件放在views/admin目录下。后台的布局采用侧边栏加顶栏的形式，侧边栏放内容管理、用户管理、系统设置等菜单，顶栏放管理员信息和退出登录按钮。侧边栏用Element Plus的el-menu组件，菜单的index属性直接对应路由路径，点击跳转交给vue-router，代码量非常少。

/admin这段路径要做守卫处理：用户在未登录状态下访问后台任意页面，直接重定向到登录页；登录了但角色不是管理员，重定向到首页。路由守卫的逻辑大致如下：

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

5.2 人物卡片、战役时间轴、百科检索三个组件的拆解

组件拆分的核心原则是：一段HTML结构如果在一个页面里出现多次，或者被多个页面复用，就应该抽成组件。三国之家项目里，人物卡片是出镜率最高的组件。首页热门推荐、人物列表页、搜索结果显示，都用同一张卡片来展示人物头像、姓名、简介和浏览量，所以把它抽成PersonCard组件是最合理的。

<template> <el-card class="person-card" shadow="hover" @click="goDetail"> <el-image :src="person.image" fit="cover" class="person-cover"></el-image> <div class="person-name">{{ person.name }}</div> <div class="person-desc">{{ person.description }}</div> </el-card> </template> <script setup> const props = defineProps({ person: { type: Object, required: true } }) const router = useRouter() const goDetail = () => { router.push(`/person/${props.person.id}`) } </script>

战役时间轴组件可以用Element Plus的el-timeline实现，数据源是战役列表接口，接口按时间字段排序好，前端只需要遍历渲染。武器百科则是一个带分类筛选的列表页，分类用el-tabs或el-radio-group做切换，每一项切换重新请求对应分类下的数据。组件之间全部通过props和事件通信，尽量不依赖全局变量，便于排查问题。

5.3 与后端联调的那些细节：跨域、拦截器与token携带

前后端分离联调时，第一个拦路虎是跨域。开发环境下，前端跑在5173端口，后端跑在8080端口，两边端口不一样，浏览器默认会阻止接口请求。解决方式有两种：一种是后端写一个CorsConfig放行所有跨域请求，另一种是前端在vite.config.js里配置proxy代理。两种各有优劣，我更喜欢前端proxy方案：它让浏览器以为所有请求都发到同一个源，反向代理到后端，不需要动后端代码，上线时也更好调整。

axios的封装建议统一写在一个request.js里，设置baseURL和超时时间，请求拦截器里自动把token加到请求头，响应拦截器里统一处理code字段，错误码为401时自动跳转登录页并清除本地存储。这样业务代码调用接口时只需要关注数据本身，不需要重复处理会话过期、网络异常这些通用逻辑。

request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config })

联调阶段我每次都会提醒自己：先确认接口通不通，再纠结样式对不对。遇到页面没数据，先用浏览器开发者工具的Network面板看接口返回码和返回数据；返回200但没有数据，查SQL和Mapper映射；返回401，查token带没带；返回500，后端控制台看异常栈。按这个顺序排查，绝大部分问题五分钟之内都能定位。

6. 打包部署、演示录像与答辩自检

6.1 本地验证到服务器部署的完整操作路径

项目跑到本地成功不算完，毕设验收或答辩演示往往要求能在线访问。后端打包用的是Maven的命令mvn clean package，产物是一个可运行的jar包。前端打包执行npm run build，产物是dist目录下的静态文件。部署时有两种常见姿势：一种是前端dist放到nginx里，后端jar单独跑；另一种是把前端dist拷贝到后端的static目录下，由SpringBoot统一托管静态资源。

我强烈建议用第一种方案，前后端分离部署，职责清晰，也符合真实项目的样子。后端启动命令记得带内存参数：

java -Xms256m -Xmx512m -jar sanguo-api.jar

服务器上不要用默认8080端口裸奔，可以在配置文件里改成其他端口。数据库导入SQL脚本时，如果出现编码问题，先检查脚本文件本身用的是什么编码，再检查连接串有没有加characterEncoding=utf8。部署完成后，打开浏览器访问前端地址，把首页、详情页、后台登录、后台增删改查全部走一遍，这就是最粗粒度的一次冒烟测试。

6.2 联调时要重点验收的六件事

很多项目演示当场翻车，问题出在细节上。这里总结一份我每次上线前必过的验收清单，建议你对照着走：第一，注册一个新账号能不能正常登录，密码错了有没有友好提示；第二，游客访问后台页面会不会被踢回登录页；第三，后台新增一条人物数据，前台列表能不能立刻看到；第四，删除一条数据后，详情页还能不能访问，会不会报空指针；第五，刷新页面之后，登录状态还在不在；第六，数据库服务重启后，平台数据是否完好。这六件事只要有一件异常，演示时都有可能成为事故。

6.3 答辩时评委常问的三个方向

答辩环节，评委基本不会照着源码逐行看，他们关心的是几个宏观问题。第一个方向是“你为什么选这个技术方案”，比如为什么用JWT而不用Session，为什么用MyBatis而不直接写JDBC。回答时不需要背概念，把差异点和本项目场景结合起来讲就行，比如“JWT适合前后端分离，因为服务端不需要维护Session，前端拿到令牌就能请求任意后端节点”。

第二个方向是“你负责了哪些模块”，这个问题必须提前梳理清楚。最怕的回答是“整个项目都是我一个人写的”，因为接下来评委就会追问每一个功能细节。更好的说法是“前端路由和人物模块、后台管理模块由我完成，登录权限框架我参与设计”，这样既体现了工作量，又给自己留了回答余地。

第三个方向是“项目还有什么可以改进的地方”。千万不要说“没有”，也不要大聊AI重构之类的空话。我建议准备两个真正合理的优化方向，比如“当前JWT令牌不携带过期自动续期逻辑，后续可以引入刷新令牌机制”，或者“人物详情接口多次查询数据库，后续可以用缓存改善响应速度”。这两句话既专业又落地，比空谈技术趋势有用得多。

说完这些，我最后的体会是：毕设项目的价值从来不在代码量多少，而在于你能不能把每一行代码背后的设计理由讲明白。三国之家这个方向，恰恰给了你一个内容足够丰富、边界足够清晰的舞台。拿到这套源码只是起点，顺着数据库设计、接口结构、组件拆分这条线走一遍，把每个“为什么”都弄懂，答辩自然就稳了。