企业官网建设流程全解析

每年这个时间点，我都能在技术社区里刷到大量"毕设选题求助帖"——"有没有适合Java Web的毕设题目""SpringBoot项目有没有推荐""图书管理系统是不是太老套了"。说实话，图书管理系统确实烂大街了，但如果在这个基础上加一个“个性化推荐引擎”，整个项目的含金量会完全不一样。这篇文章要聊的，就是一套完整的SpringBoot+Vue个性化图书推荐系统平台：后端基于SpringBoot，前端基于Vue，配MySQL数据库和全套SQL脚本，附带接口文档，可以直接跑通、可以改造、可以写进简历，也可以直接用来作为Java Web毕设的主体框架。

这个系统不是那种只有一个“登录注册加CRUD”的壳子，它把推荐系统真正落了地：有基于协同过滤的个性化推荐算法，有用户评分和图书借阅的数据闭环，有后台管理和数据可视化，代码结构也是按照生产标准来组织的。不管你是要做毕设，还是想在校招项目里多一个有深度的项目，这套内容都值得你花一个周末把它吃透。

说实话，我做这个项目的过程中踩了不少坑，从数据库表设计到推荐算法参数调整，再到前后端联调的安全问题，每一个坑背后都有值得复盘的点。下面的内容我不打算写成那种“一步步跟着做”的教程手册，而是按我真实做完整个项目的思路走一遍：为什么选这个方向、架构怎么搭、算法怎么落地、数据库脚本里有哪些细节、前后端怎么配合、接口文档怎么写、答辩时怎么把这个项目讲出彩。你看完可以直接在现有源码基础上去改、去扩展，比拿着代码盲目的跑一遍有用得多。

1. 为什么“个性化图书推荐系统”是Java Web毕设的黄金选题

1.1 推荐系统：既不过时也不烂大街的领域

每年毕设论坛里最多的两句话是：“题目太普通的老师不给过”和“题目太难的自己写不出来”。图书管理系统、酒店管理系统、仓库管理系统这一档，属于经典的CRUD项目，功能做完没问题，但答辩的时候拼不出亮点。而如果上人工智能相关的推荐系统、图像识别，又容易被算法部分卡住，最后连系统都跑不起来。

个性化图书推荐系统恰好卡在中间：技术难度足够、演示效果直观、又有真实的业务闭环。

推荐系统本身在目前的工业界和学术界都是高热度方向，电商、短视频、音乐、资讯，全都在用推荐引擎。你在毕设里做一个图书领域的推荐系统，背后是完整的需求分析、算法选型、数据处理、前后端工程化落地，任何一个环节都能回答老师“为什么这么做”。

而且图书这个领域特别适合做推荐系统。原因有三点：第一，图书的品类和标签体系成熟，容易做内容特征；第二，用户的评分、借阅、收藏行为可以组成天然的评分矩阵；第三，推荐结果的展示非常直观——给用户推一个“与你喜好匹配”的书单，比推一段冷冰冰的列表更能体现算法的价值。

1.2 这套项目能让答辩老师眼前一亮的三个点

我做这个项目的过程中，总结了三个答辩加分点，反而是很多同类项目容易忽视的：

第一，前后端分离的工程化组织。SpringBoot负责纯后端API，Vue负责页面渲染和交互，两者通过JSON交互。你在简历里可以写“熟悉前后端分离开发模式”，在答辩时可以讲RESTful接口设计、跨域处理、Token鉴权，这些都是面试高频题。

第二，推荐算法不是摆设，而是真正参与业务闭环。用户注册后可以给图书打分、收藏、借阅，系统根据这些行为产出“猜你喜欢”和“相似图书推荐”。评分数据不是静态造出来的，而是随着用户操作持续累积的，这就让整个系统变成一个“活”的系统，演示效果远比静态页面有说服力。

第三，有完整的SQL脚本和接口文档。很多毕设项目代码能跑，但数据库脚本一塌糊涂，接口也没有文档。这套项目里我把SQL脚本和接口文档当成一等公民来对待，评审老师翻到的时候观感会好很多。脚本拆成建库建表、模拟数据、初始化数据三个部分，接口文档既支持在线Swagger查看，也提供离线Markdown版本，光是这两项就能在“项目完整性”这个评分维度拿到不少分。

所以，如果你正在纠结毕设题目，我的建议是：别做一个单纯的“XX管理系统”，而是做一个“带业务智能的XX系统”。图书推荐系统就是一个非常成熟的切入点，同类的思路也可以迁移到视频推荐、课程推荐、新闻推荐上，换一个业务领域就是一套新项目。

2. 整体架构设计与技术选型：前后端分离的落地姿势

2.1 技术栈版本选型：稳定压倒一切

先讲技术选型，这块我踩过坑。最初我把SpringBoot直接拉到3.x，Vue也用了最新的3.4，结果学校机房的老机器跑不动，因为JDK版本要求高（SpringBoot 3需要JDK 17），而且网上能查到的教程大多数还是基于旧版本，出了问题自己排查很费时间。我后来把版本全部降回保守组合，项目就没再因为环境问题卡过壳。

毕设项目的核心诉求是“稳定可复现”，不是“追新”。我最终选型如下：

这里插一句：不是不能上新技术，而是毕设时间宝贵，别把时间耗在环境兼容性上。如果你确实想用Vue3+TS+SpringBoot3，项目整体思路是通用的，只需要调整部分依赖写法。但如果你是为了省事，强烈建议就走上面这套版本组合，遇到任何问题都能在网上搜到现成答案。

2.2 功能模块划分与角色权限

整个系统分成两个面：用户端和管理端。

用户端给普通读者用，核心功能包括：注册/登录/个人资料维护；图书浏览、按分类筛选、关键词搜索；图书详情页展示内容简介、作者、封面、评分、评价；对图书进行评分（1-5星）、收藏图书、模拟借阅；首页的个性化推荐区（猜你喜欢）、图书详情页的相似推荐。

管理端给管理员用，核心功能包括：图书管理（新增/编辑/下架图书，支持批量导入）；分类管理（维护图书一级/二级分类）；用户管理（查看用户列表、禁用异常账号）；数据统计（注册趋势、热门图书、评分分布的可视化图表）。

后端按经典三层来设计：Controller（接收请求）、Service（业务逻辑）、Mapper（数据访问）。再往外一层是统一的Result 返回结构、全局异常处理器、JWT拦截器。这个分层结构在你写接口文档的时候特别舒服，每个接口对应的职责一清二楚。

2.3 为什么坚持前后端分离而不是用模板引擎

有同学会问：SpringBoot自带的Thymeleaf也能写页面，为什么非要拆成Vue？

我的回答是：第一，目前企业里主流的前后端分离模式，毕设用这种方式更能体现你对现代开发流程的理解；第二，推荐系统的数据呈现需要大量异步刷新、图表渲染，用Vue做交互体验比服务端渲染顺滑得多；第三，前后端分离之后的接口文档天然非常规范，因为你必须明确每个接口的出入参，系统之间才能协作。

当然，拆成前后端两个项目后，部署会多一步，需要在Nginx里配置代理，或者把Vue打包出来的dist目录直接放到SpringBoot的static目录下。这个我在后面部署章节会详细讲。在开发阶段，我用的是Vue CLI自带的devServer代理，通过vue.config.js配置proxy把前端的接口请求转发到后端8080端口，这样开发时连跨域都很省心。

3. 推荐算法落地的核心：协同过滤与冷启动处理

3.1 基于用户的协同过滤（UserCF）

推荐算法是这套系统的灵魂。我先说最基础也最实用的一个：基于用户的协同过滤（User-CF）。

UserCF的核心思想就是一句话：找到跟你品味相似的人，把他们喜欢而你没看过的东西推荐给你。

具体分三步：

第一步，构建用户-图书评分矩阵。每一行是用户，每一列是图书，单元格是对应的评分（没评过的为空或0）。

第二步，计算用户之间的相似度。我用的是余弦相似度，公式是：

cos_sim(A, B) = (A·B) / (|A| × |B|)

A和B是两个用户在共同评分图书上的评分向量。我在实现的时候只在两者都评过分的图书上计算，避免大量0值干扰，否则每个用户都因为“都没看过某本书”而变得相似，那结果就完全没有意义了。

第三步，为目标用户生成推荐列表。找到相似度最高的K个用户，把他们评分高的、目标用户没看过的图书收集起来，按相似用户评分和相似度加权求和，取Top-N输出。

在实际代码里，我用HashMap来构建评分矩阵，用双重循环计算相似度。数据量小（几百个用户、几千本书）的时候跑得飞快，毫秒级出结果，完全不需要引入Spark这种重武器。网上可以看到很多用Spark做电商推荐的案例，那种方案适合百万级数据，用在毕设系统里确实没有必要——你把“为什么用单机算法而不是分布式框架”这个问题答好，反而是加分项。

考虑性能，我在项目里把推荐计算放到了后端异步执行，用户触发评分/借阅行为之后，系统会更新推荐结果；另外还用Spring的@Scheduled定时任务，每天凌晨离线重算一次全量推荐结果，缓存到推荐结果表里。这样用户点开首页推荐区的时候，直接从表里查，响应速度很快，不会让用户感受到“这个系统在现算推荐”。

3.2 基于物品的协同过滤（ItemCF）

UserCF之外，系统里还用了ItemCF（基于物品的协同过滤），主要用在图书详情页的“相似图书推荐”。

ItemCF的思想反过来：先找相似的物品，再判断用户是否对相似物品感兴趣。对于图书这个场景，它有一个天然优势——图书的相对稳定性高，计算一次相似图书表可以长期复用；而且解释性好，你可以对用户说“因为你看了《围城》，所以推荐钱锺书的另一本《人·兽·鬼》”，这种解释在推荐系统的可解释性指标里非常加分。

ItemCF的关键是计算图书之间的相似度。同样用余弦相似度，把“用户-图书评分矩阵”转置成“图书-用户评分矩阵”再计算。我在项目里提前离线算了图书相似度矩阵并存入数据库，这样详情页不用每次动态计算。相似图书表book_sim里预先保存了每本书最相近的10本书及相似度分数，详情页接口只需要一条SQL关联查询就能返回结果。

3.3 新用户冷启动：怎么让推荐“活”起来

推荐系统里最经典的坑就是冷启动：新用户没有任何行为数据，系统推什么？

我的方案是三层递进：

• 用户首次注册后，先推全站热门图书榜（按平均评分和评分人数加权排序），保证推荐区不为空；
• 用户浏览或搜索时，记录用户对图书分类的偏好，一旦有了行为痕迹，立刻切换为基于分类偏好的推荐；
• 用户产生评分/收藏/借阅行为后，进入协同过滤主流程，输出个性化结果。

这套冷启动策略实测下来效果不错，演示的时候你可以现场注册一个全新账号，然后故意给一本冷门书打高分，刷新页面就能看到推荐结果发生变化——这个“从无到有”的变化过程非常直观，比讲一堆算法公式有用得多。

混合推荐方面，我的做法是给三类结果分别打分，按照“热门榜30% + 分类偏好30% + 协同过滤40%”的权重加权，既保证有个性化，又避免推荐结果太单一。权重的具体比例你可以按自己数据跑出来的效果调整，没有绝对最优，关键是答辩的时候能说清楚你这套权重是怎么调出来的，比如你对热门榜降权是因为发现它太大众化、个性化不足。

4. 数据库设计要点与SQL脚本里的那些坑

4.1 核心数据表：从用户到推荐的完整链路

这套系统的数据库我设计了8张核心表，SQL脚本建好之后还导入了大量模拟数据，让系统一跑起来就有内容。先看表的整体结构：

几个容易被忽略的设计点：

第一，用户密码不能明文存储。我在SQL脚本里预置的密码都是BCrypt加密后的值，业务代码里用Spring Security自带的BCryptPasswordEncoder校验。答辩十有八九会被问到密码安全性，这个细节可以拿出来讲。

第二，图书表里的rating_avg和rating_count是冗余统计字段。用户每次打分后，业务层实时更新这两个字段，避免反复用AVG(score)全表聚合。这是典型的空间换时间，也是性能优化的常见手法。

第三，评分表加唯一约束（user_id, book_id），保证同一个用户对同一本书只能有一条评分记录，防止前端重复提交造成数据错乱。数据库层面的约束永远比业务代码判断更可靠。

4.2 SQL脚本的落地细节与索引优化

SQL脚本不是只有建表语句和几条INSERT就完事了。我把脚本拆成了三个文件：schema.sql（建库建表）、data.sql（模拟数据）、init_data.sql（预设管理员账号和基础分类）。这样看脚本的人一眼能分清结构，也方便你自己替换数据。

模拟数据这块特别重要。一个推荐系统演示时如果只有20条图书、5个用户，算法算出来的效果会非常有限；我最终导入了3000+条图书和600+个用户行为数据，推荐结果才真正“有个样子”。数据来源可以是爬虫抓的公开书单、豆瓣榜单数据，也可以手动造一批有规律的数据——比如让某些用户集中在“技术类”图书上打高分，这样系统才能学到“这群人喜欢技术书”的规律。造数据的时候要注意数据的“故事感”：一个用户如果今天看Java、明天看分布式、后天看算法，系统就应该能给他推技术类的其他书；另一个用户如果只看文学和历史，推荐结果就应该完全不同。这种差异化正是演示时最出彩的部分。

索引设计上我做了三处关键优化：

• rating表创建联合索引UNIQUE KEY uk_user_book (user_id, book_id)，同时服务了按用户查评分的场景；
• book表给category_id建普通索引，分类筛选时避免全表扫描；
• 搜索场景用title、author两个字段的LIKE模糊查询，数据量不大时性能没问题，如果数据量上来了，可以换成MySQL 8.0自带的全文检索，或者引入Elasticsearch——我建议毕设阶段做好LIKE + 索引就足够了，但可以对老师说“后续可以扩展ES”。

慢SQL这块我还专门写过一个排查笔记。当时图书列表分页接口在数据量到几千条之后变慢，我发现是因为ORDER BY rating_avg DESC这种排序字段没有索引，MySQL执行了Using filesort。后来给rating_avg和rating_count建了联合索引，分页排序的速度立刻上来。这个优化案例写进文档里非常加分，它证明你真排查过性能问题，而不是只做了个“能跑”的系统。

这里顺便说一句：如果你学校要求把MySQL换成SQL Server，整体表结构基本不用改，只需要调整驱动依赖和个别方言函数——比如分页写法从LIMIT换成OFFSET FETCH，或者用SQL Server的TOP。不过我还是建议优先用MySQL，资料多、踩坑少，适合毕设节奏。

4.3 SQL注入与安全细节

很多同学在用字符串拼接SQL时踩过SQL注入的坑，“万能密码绕过登录”这些问题在毕设评审里也常被问到。我在项目里全程使用MyBatis-Plus自带的安全预编译机制（PreparedStatement），禁止用${}直接拼接参数，在Mapper里一律用#{value}语法传参。这一点在答辩时一定要主动提一下，老师们特别看重安全意识。

另外一个安全细节是JWT。用户登录验证通过后，后端生成Token返回给前端，前端存储到localStorage并在axios拦截器里统一加到Authorization头。后端通过拦截器解析Token、放行白名单路由（比如登录、注册、图书查询）。这样做的核心价值是无状态鉴权，不需要在服务端存Session，也非常贴合前后端分离的架构。

5. SpringBoot后端：推荐接口与用户体系的具体实现

5.1 项目结构与统一返回体

后端项目我按功能包组织，结构如下：

src/main/java/com/library/recommend ├── controller # 接口层 │ ├── UserController │ ├── BookController │ ├── RecommendController │ └── AdminController ├── service # 业务层 │ ├── UserService │ ├── BookService │ ├── RatingService │ └── RecommendService ├── mapper # 数据访问层 ├── entity # 实体类 ├── config # 配置类（跨域、拦截器、Knife4j） ├── common # 统一返回体、异常处理、常量 └── util # JWT工具类、推荐算法工具类

为了让接口风格统一，我定义了一个Result 类，里面固定三个字段：code（业务状态码）、message（提示信息）、data（业务数据）。所有接口都返回这个结构。前端axios拦截器里统一判断code，只有code为200时才把data交给业务逻辑，否则弹错误提示。

5.2 后端接口代码里最值得说的几个接口

推荐接口是系统的核心。接口设计如下：

GET /api/recommend/home

参数：无（后端从Token解析当前用户ID）

返回：轮播图推荐（运营位）+ 猜你喜欢列表 + 热门榜单

实现逻辑：先查缓存，如果没有，就去rec_result表里查该用户的推荐结果，按score倒序取前20条，再关联book表补全图书信息。因为推荐结果每天凌晨离线算好，这个接口响应很快，基本都在100ms以内。

评分接口设计如下：

POST /api/rating

请求体：

{ "userId": 1, "bookId": 100, "score": 5 }

业务逻辑三步走：第一步校验参数和用户是否存在；第二步执行INSERT ... ON DUPLICATE KEY UPDATE，用唯一约束兜底防重；第三步异步调用推荐服务，刷新该用户的推荐结果和图书的rating_avg、rating_count。

第三步我用的是@Async注解，把更新推荐结果的逻辑放到线程池执行，用户在页面打分后立刻收到“评分成功”，不用傻等推荐重算。这个体验细节很重要，如果同步执行，推荐计算耗时一两秒，用户会明显感到卡顿。

管理端接口方面，我用了一个通用模式：分页查询 + 条件筛选。MyBatis-Plus自带的分页插件只需要在Config里配置一个MybatisPlusInterceptor，注册PaginationInnerInterceptor，然后在Mapper里传Page对象即可，非常方便。关键代码大概是这样的：

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

5.3 全局异常处理：把错误变成接口文档里的一页

有一个所有毕设都容易忽略的点：异常处理。如果不做统一处理，接口一报错就返回一串默认的500错误页，前端拿到一团乱码，调试起来特别痛苦。

我在项目里加了@RestControllerAdvice全局异常处理类，把常见的业务异常、参数校验异常、未登录异常全部捕获，统一转成Result 结构。比如用户未登录时返回code=401和“请先登录”，前端axios拦截器检测到401就自动跳转登录页。

前端那边我在axios封装里统一做了三件事：baseURL指向后端接口地址、请求拦截器自动携带Token、响应拦截器统一弹出错误提示。这样每个页面组件只管调接口，不重复写错误处理逻辑。这个模式也是现在企业里标准的接口对接方式，你做完整个项目，对前后端联调的理解会非常深。

6. Vue前端：推荐结果可视化与后台管理的交互细节

6.1 页面路由与整体布局

前端用Vue2 + Element UI + Vue Router + Axios + ECharts，整体是标准的SPA单页应用。路由设计成两套布局：

• 用户端布局（包含顶部导航、侧边栏、内容区）：首页、图书列表、图书详情、我的书架、个人中心
• 管理端布局（独立的侧边栏后台）：数据看板、图书管理、分类管理、用户管理

推荐区是首页的核心，我把它分成三个板块：顶部是“猜你喜欢”横滑卡片区，中间是“热门图书”网格列表，底部是“根据你的阅读记录推荐”清单列表。这样设计的好处是让老师一眼看到推荐系统的不同策略输出，而不是一个扁平的大列表。你在前端展示上不要省功夫，推荐系统不像财务报表，一眼能看出“有没有个性”，卡片区的横滑交互和个性化的文案提示能给评委最直观的印象。

6.2 推荐卡片组件与交互细节

推荐卡片是复用率最高的组件。图书卡片上展示封面、书名、作者、评分，鼠标悬停时显示“加入书架”“想看”两个快捷操作按钮。组件接收一个book对象，通过props传递，不维护自己的数据状态，方便列表页和推荐页复用。这种“展示型组件尽量无状态”的做法也是Vue组件设计里的常见规范。

评分交互我做了防重复提交处理：用户点击星级评分后，先置灰星标组件，等后端返回成功再恢复。如果是重复评分，后端会更新原分数而不是报错——这个行为要和后端接口保持一致，否则会出现用户评分成功但页面没变化的诡异情况。

路由跳转上面有个小坑要提醒：两个不同路由如果复用了同一个组件实例（比如从“技术类图书列表”跳到“文学类图书列表”），Vue2不会重新执行组件的created生命周期，导致页面数据不刷新。解决办法是在组件里watch $route对象的变化重新加载数据，或者在列表页给router-view加一个:key="route.fullPath"强制重建。我最后用的是后者，一行代码解决问题，省心很多。

另外开发调试时记得装Vue Devtools，浏览器扩展里可以直接看到组件树和Vuex状态，排查数据问题效率翻倍。这个插件在网络上一搜就有对应浏览器版本，建议每个做Vue毕设的同学都配上。

6.3 ECharts数据可视化与管理端

管理后台的数据看板我用了ECharts画了四张图：近30天注册趋势折线图、图书评分分布柱状图、热门图书Top10横向条形图、分类占比饼图。这些图表的数据都来自后端统计接口，前端只需要按ECharts要求的格式组织option就行。

ECharts接入有一个经典问题：容器div在初始化时如果宽度为0，图表会渲染异常。因为SPA有时候会先把隐藏的组件挂载出来，导致图表的父容器还没有实际宽度。解决办法是给图表容器一个固定高度，宽度设成100%，并在mounted中使用nextTick后再初始化图表。如果页面是带tabs切换的，要监听tab激活事件，用setTimeout延迟100ms再resize——这个问题我调试了整整一个下午才找到原因，提前写出来给你避坑。

7. 接口文档的编写规范：让评分老师看懂你的系统

7.1 接口文档不是应付检查，而是项目的一部分

很多同学对接口文档的态度是“最后临时拼一个Word”，这很可惜。接口文档其实有两个重要作用：第一，它是系统设计规范性的直接体现，老师翻文档能看出你有没有认真做过系统设计；第二，它帮助你自己理清每个接口的职责，写文档的过程就是review代码的过程。

我在项目里直接把Knife4j（Swagger增强版）集成到了SpringBoot里，通过注解自动生成在线API文档。只要在Controller方法上加@ApiOperation、在参数上补充@ApiModelProperty说明，访问/doc.html就能看到分组清晰、带参数说明和响应示例的文档。同时我导出了一份离线Markdown格式的接口文档，跟着源码一起交付，这样老师不需要启动环境也能看到全部接口的定义。接口文档本身也是你简历里可以写的一项：“熟练编写和维护接口文档，熟悉Swagger/Knife4j规范”。

7.2 一套合格的接口文档必须包含的内容

以“评分接口”为例子，我的文档模板包含六块内容：

• 接口名称：提交图书评分
• 请求方式：POST /api/rating
• 请求参数：userId、bookId、score，每个字段标明类型、是否必填、取值范围、示例值
• 请求示例：JSON格式的完整请求体
• 响应示例：成功时和失败时的JSON结果，失败时附带错误码
• 业务说明：重复评分的更新策略、评分后推荐结果异步刷新逻辑、权限要求

这里有一个加分的小细节：我把接口按模块分组，并给每个分组写了一段用途说明。比如“推荐模块：负责首页猜你喜欢、图书详情页相似推荐、热门榜单三块数据输出”。老师翻文档时不需要读代码就能理解系统的完整功能边界，这种“设计思维”在答辩时非常加分。

我自己在做接口文档时还有一个习惯：每完成一个接口就立刻写文档，绝不攒到最后一起补。因为当时写记忆最清楚，哪个字段是冗余的、哪个状态码有特殊含义，当时不记，一周后你自己都会忘记。

另外，接口文档里状态码设计要统一。我用的规范是：200成功、400参数错误、401未登录/Token失效、403无权限、404资源不存在、500服务器内部错误。前端只需要识别这几类，就能做对应的页面反馈。状态码混乱是很多项目看起来“业余”的核心原因之一。

8. 部署演示与答辩引导：别让项目死在最后一公里

8.1 本地从零跑起来的完整步骤

毕设最后一个坎是“能跑”。很多项目代码很完整，但缺一个清晰的部署说明，导致评分老师或者下一个看代码的人第一步就跑不起来。我建议你把自己的部署步骤沉淀成一个README，至少包含下面这些内容：

第一步，准备环境。安装JDK 1.8、Maven 3.6+、MySQL 8.0、Node.js 16+。注意MySQL建库时字符集选utf8mb4，否则中文可能乱码。

第二步，初始化数据库。用Navicat或命令行执行schema.sql和data.sql。执行前先看一下建库语句里的数据库名，和SpringBoot的application.yml里的配置保持一致。

第三步，启动后端。在项目根目录执行 mvn spring-boot:run，或者先 mvn clean package -DskipTests 再 java -jar target/xxx.jar。看到“Started RecommendApplication”就说明后端起来了，默认端口8080。

第四步，启动前端。在vue目录下执行 npm install 安装依赖，然后 npm run serve 启动开发服务器，默认端口8081。前端通过devServer的proxy代理把 /api 开头的请求转发到后端的8080端口，所以不需要单独配置跨域。

第五步，访问系统。浏览器打开 http://localhost:8081 ，用管理员的账号登录后台管理，用普通用户账号体验推荐功能。

这里再送你一个技巧：部署不一定要等答辩前才做。项目开发过程中就养成“最少每周一次全流程跑通”的习惯——把后端打包成jar、前端build一次，模拟从零部署。这样能提前发现很多开发环境里发现不了的问题，比如依赖版本冲突、打包资源缺失、端口占用等。我见过太多同学在开发环境点一下run就没事，结果演示当天在老师的电脑上死活启动不了。

8.2 演示脚本怎么设计更出效果

演示和答辩是你整个项目的收尾，一定要提前排练。我的建议是准备一条“讲故事”式的演示路径：

• 先以管理员身份登录，展示后台的图书管理、用户管理和数据看板，让老师看到系统的完整性；
• 然后切换到一个已有行为数据的普通用户账号，打开首页推荐区，说明“这个用户的推荐是根据他之前打过高分的《深入理解Java虚拟机》等书生成的”；
• 接着现场注册一个新账号，先看默认推荐（热门榜），然后给两三本你提前选好的冷门图书打高分，刷新推荐区，让老师看到推荐结果“从无到有、从冷到热”的变化；
• 最后打开接口文档，演示一两个核心接口的调用和返回，收尾。

这套演示路径的核心思路是：让老师亲眼看到数据如何驱动推荐结果变化，而不是只看到一堆写死的页面。整个演示控制在8到10分钟，节奏要练习到不卡壳。

8.3 答辩时最容易问到的五个问题

做完整套系统后，我总结了答辩时老师最爱问的问题，先列出来，让你有个准备：

1. 为什么用协同过滤，不用深度学习？——答：毕设的数据量在万级以内，协同过滤算法解释性强、计算开销低、效果稳定；神经网络模型需要海量数据训练，且可解释性差。如果数据规模增大，可以迁移到Spark MLlib等分布式框架。
2. 冷启动怎么解决？——答：三层策略，热门榜兜底、分类偏好过渡、协同过滤主推，并把新注册用户没有行为数据时的推荐逻辑理直气壮地讲清楚。
3. 推荐系统的效果怎么评估？——答：可以用准确率、召回率、覆盖率等离线指标做交叉验证，项目里也预留了统计可视化，用真实用户行为来印证推荐变化。
4. 为什么评分数据是模拟的，数据从哪来？——答：可以根据公开书单和榜单数据整理生成，再按用户群体规律生成行为数据，目的是验证算法的业务效果；系统上线后可以替换成真实用户数据。
5. 如果用户变多了，性能怎么办？——答：当前用离线定时计算和缓存已经很稳；更大规模可以引入分布式计算、向量化检索、ALS算法等。

这些问题其实都没有标准答案，关键是你要能自圆其说，并且证明你确实动手做过、思考过。最怕的是背答案，老师追问一个“你实际测试过数据量到多少会变慢”就答不上来，那反而扣分。

8.4 最后说点我自己的体会

项目做完、演示通过之后，我最大的感受是：毕设选对方向比盲目努力重要得多。一个带推荐算法的图书系统，让我在写简历的时候多了很多可以聊的技术点——SpringBoot工程化、Vue组件化、MySQL索引优化、推荐算法落地、接口文档规范。这些不是背出来的，而是真的一步一步做出来的。

如果你打算在“SpringBoot+Vue个性化图书推荐系统”这个框架上继续改，我建议可以从三个方向扩展：把推荐算法换成ALS矩阵分解甚至图神经网络；引入Elasticsearch做图书搜索；把登录升级为OAuth2.0或手机号验证。这个系统做到这个程度，已经是一个可以写进简历的完整项目了。

最后再分享一个小技巧：整个项目做完之后，把“你踩过的三个最大的坑和解决方案”整理成一页文档，放在README的最前面。答辩的时候如果老师问“这个项目里你觉得最难的地方是什么”，你直接把这页翻出来讲，老师会认为你是真的在做项目，而不是在凑毕业。这个动作，比你多写一百行代码都管用。