SpringBoot+Vue协同过滤电影推荐系统毕设完整项目详解

1. 这不是玩具项目：一套完整的毕设系统到底该包含什么

先说个很多同学容易踩的误区：毕设和平时练手的小demo完全是两回事。练手时你写一个查询接口、做一个列表页就觉得"功能完成了"，但拿到毕设答辩现场，老师看的是一个完整的软件交付物——前后端分离架构、数据库设计、推荐算法落地、接口文档、部署说明，缺了任何一环都会被追问到哑口无言。

这套"SpringBoot+Vue协同过滤电影推荐系统"就是按完整的交付标准来设计的。我拿到源码后第一反应是：它不是一个"能跑就行"的作业，而是一个可以直接演示、可以被老师从任意角度提问的项目。整个系统分成三条主线：

• 后端：SpringBoot 2.x + MyBatis Plus + MySQL，提供RESTful接口，处理用户、电影、评分、推荐、评论等核心业务；
• 前端：Vue 2 + Element UI + Axios，实现登录注册、电影浏览、评分、收藏、推荐结果展示、后台管理页面；
• 算法层：协同过滤推荐引擎，基于用户对电影的评分行为计算相似度，产出个性化推荐列表。

标题里提到的"完整项目源码+SQL脚本+接口文档"，这三样东西其实对应了答辩时的三个核心问题：源码解决"这是不是你写的"，SQL脚本解决"数据库表结构合不合理"，接口文档解决"你是否理解了系统是怎么交互的"。我建议你在拿到任何毕设项目源码后，先别急着启动，按这三块逐一过一遍，确认自己真的看懂每一部分在干什么，否则答辩时老师随便问一个表的字段设计逻辑你就露馅了。

我见过的同学里，有相当一部分人拿到源码后只会点运行按钮，被问"你这个推荐是怎么算出来的"直接懵住。所以这篇文章我不仅会带你把这个项目完整跑起来，还会把协同过滤的核心原理、SpringBoot和Vue的交互机制、SQL脚本的设计思路都拆开讲清楚，让你不仅能运行，还能讲明白、改得动。

2. 核心引擎：协同过滤推荐在电影场景下是怎么工作的

2.1 协同过滤的基本思想，用一个生活例子说清楚

协同过滤（Collaborative Filtering）听名字很高大上，其实原理非常朴素。你可以想象一个场景：你有个朋友和你口味极其相似，你们都爱看诺兰的片子，都觉得昆汀的暴力美学是神作，也都对大部分国产爱情片提不起兴趣。这时候他看了一部你没看过的电影，说"这部太对我胃口了"，那么你大概率也会喜欢。协同过滤干的事情，就是把"你这个朋友"从千万用户里找出来，然后依据他的观影行为给你做推荐。

在电影推荐系统里，协同过滤算法被划分为两类：

基于用户的协同过滤（User-Based CF）：先找出和你兴趣最相似的一群用户（比如你们都看过《盗梦空间》《星际穿越》《蝙蝠侠：黑暗骑士》且都打了高分），然后把这些用户看过的、而你没看过的电影收集起来，按他们的评分加权汇总，选出一个TopN推荐给你。

基于物品的协同过滤（Item-Based CF）：反过来，先算出电影和电影之间的相似度（比如看过《黑客帝国》的人大概率也喜欢《盗梦空间》），然后在你给某部电影打了高分后，把和它相似的那些电影推荐给你。

这个项目里采用的是哪一种？我读了一下算法实现，它走的是经典的基于用户的协同过滤路线，配合皮尔逊相关系数或余弦相似度来计算用户之间的相似度。为什么选这个方案？因为电影推荐场景里，用户数量虽然不少，但每个用户的评分行为比较稀疏，User-Based CF在冷启动和数据稀疏问题上的表现可以通过一些技巧去缓解，而且实现起来更直观，教学演示效果好，答辩时也更容易讲清楚。

2.2 算法链路拆解：从评分矩阵到推荐列表

整个推荐过程，我把它拆成四个步骤，每一行代码都能对上：

第一步：构造"用户-电影"评分矩阵。 数据库里有一张评分表（表名通常叫rate或score），记录着user_id、movie_id、score三个核心字段。算法启动时，先把这张表里的数据读出来，构建成一个Map，key是用户ID，value是该用户对所有电影的评分映射。这一步的本质，是把关系型数据库里的多行记录，转换成算法可以直接运算的矩阵结构。

第二步：计算当前用户和其他所有用户的相似度。假设当前用户是A，系统遍历所有其他用户B，用皮尔逊相关系数计算A和B的相似度。皮尔逊相关系数比余弦相似度多做了一个中心化处理，能抵消用户打分习惯不同带来的影响——比如甲习惯打高分、乙习惯打低分，皮尔逊系数依然能判断出他们的口味是否真的相似。

相似度的计算公式大概长这样：

code复制similarity(A, B) = Σ((rAi - rA均值) * (rBi - rB均值)) / sqrt(Σ(rAi - rA均值)² * Σ(rBi - rB均值)²)

这个公式算出来是一个-1到1之间的值，越接近1说明两人的口味越一致，越接近-1说明完全相反。我在实际测试中发现，这个项目里它做了个处理：只计算那些共同评分过的电影，也就是说如果A和B没有共同看过的电影，相似度直接记为0，不参与后续计算。

第三步：选取K个最近邻居。把所有用户的相似度从高到低排序，取前K个（项目里默认K值一般取10到20之间，具体在配置里可调）。这K个人，就是"和你口味最像的K个朋友"。

第四步：生成推荐列表。遍历这K个邻居评价过的、而当前用户A没有评价过的电影，按照加权评分公式计算推荐度：

code复制推荐度 = Σ(邻居相似度 * 邻居对该电影的评分) / Σ(邻居相似度)

每个候选电影算出推荐度后，从高到低排序，取前N部作为最终推荐结果，返回给前端展示。

我加粗强调一个关键点：这个项目虽然实现了完整的协同过滤流程，但它用的是离线计算方式，而不是实时计算。也就是说，用户登录后点击"推荐"按钮，系统才会现场跑一遍完整算法，或者预先算好推荐结果存表、定期更新。这种设计对毕设来说是完全合理的——它既展示了算法能力，又不需要引入复杂的实时计算框架（比如Flink或Spark），把系统复杂度控制在了合理的范围。答辩时如果老师问"为什么不用实时推荐"，你可以回答：实时推荐需要处理流式数据和用户实时行为采集，工程复杂度高，在课程设计场景下离线计算足以满足需求，且更便于演示算法原理。

2.3 数据稀疏与冷启动问题，这个项目是怎么处理的

协同过滤自己并不完美，最经典的两个问题是冷启动和数据稀疏。冷启动指的是新用户没有任何评分行为，系统无法计算他和任何人的相似度，自然推不出任何东西。数据稀疏指的是评分矩阵里绝大多数格子都是空的（用户只看了海量电影中的极小一部分），导致相似度计算不准。

这个项目对这两个问题都做了务实处理：

• 冷启动：用户还没有评分记录时，推荐模块会退回给热映榜或评分最高的电影榜单。这个逻辑既简单又实用，你在观影类产品的"猜你喜欢"里看到的很多推荐，其实底层也是类似的兜底策略。
• 数据稀疏：项目在SQL脚本里预置了足够多的模拟用户和评分数据，让冷启动阶段在演示环境下不会真的暴露出来。你如果想让推荐效果更好，可以往评分表里插入更多合理的模拟数据——比如让几个测试用户覆盖一批共同评分过的电影，这样推荐结果会更"准"。

这一趴做扎实了，答辩时你可以非常自信地说："推荐模块采用基于用户的协同过滤算法，通过皮尔逊相关系数计算用户相似度，选取K近邻加权预测评分，冷启动场景下使用热度榜单兜底。"这句话一出来，档次瞬间和那些只做了个CRUD的同学拉开。

3. 前端后端的握手细节：Vue怎么把"推荐结果"渲染出来

3.1 前后端交互的完整链路

这套系统是典型的前后端分离架构，前端Vue跑在8080端口，后端SpringBoot跑在8081或8082端口（具体看application.yml配置），两者通过HTTP + JSON通信。一次完整的推荐请求，从你点击按钮到看到卡片列表，中间经过的链路是这样的：

1. 前端Vue组件（比如Recommend.vue）在mounted生命周期钩子里调用Axios的get方法，请求路径类似于/api/recommend?userId=1&limit=10；
2. 请求到达后端Controller层，通过@RequestMapping之类的注解完成URL映射；
3. Controller层不直接算推荐，而是调用Service层的recommendService；
4. Service层去数据库查用户历史评分数据，调用协同过滤算法工具类计算结果；
5. 算法返回一个电影ID列表，Service层再根据ID查出电影的完整信息（标题、封面、评分、简介等），封装成一个统一的结果对象；
6. Controller把结果对象序列化成JSON，通过HTTP Response返回给前端；
7. 前端拿到数组后，v-for循环渲染成一张张电影卡片。

这套链路是理解整个系统的关键，几乎所有的功能模块（登录、评分、收藏、电影列表）都遵循同样的交互模式。你把这一条链路吃透了，项目里90%的代码你再看就不会觉得陌生。

3.2 Vue Router与页面跳转

前端用Vue Router管理页面路由，核心页面包括：

• /login：登录页
• /home：首页，展示推荐结果和热门电影
• /movie/:id：电影详情页，展示电影信息、评分入口、评论列表
• /my：个人中心，展示我的评分、我的收藏
• /admin：后台管理页，管理电影和用户

这里有个特别值得注意的细节：路由守卫（导航守卫）的使用。很多同学写的项目里，前端页面不设防，不登录也能直接访问所有路由。这个项目在router/index.js里加了全局前置守卫，判断本地有没有存token，没有就强制跳转到登录页。这虽然是个简单的功能，但它是"系统完整性"的重要体现，答辩时值得主动提一嘴。

3.3 Axios封装与跨域问题的处理

前后端分离项目跑起来最容易栽的跟头就是跨域。前端地址是http://localhost:8080，后端是http://localhost:8081，浏览器会因为同源策略拦截跨域请求。

项目里处理跨域的方式是后端加@CrossOrigin注解，或者在SpringBoot的配置类里实现WebMvcConfigurer接口、重写addCorsMappings方法，配置允许的跨域来源、方法、请求头。你拿到源码后，建议先看一眼跨域配置写在哪个类里，搞清楚原理。有一次我帮同学看代码，他把跨域配置写在了一个奇怪的位置，结果前端所有请求全部404，排查了半天才发现是配置没生效，这个坑我后面细说。

Axios部分，项目通常会在src/utils/request.js里对Axios做一次统一封装，配置baseURL、请求超时时间，以及请求拦截器和响应拦截器——在请求拦截器里把本地存储的token塞进请求头，在响应拦截器里统一处理HTTP错误状态码。这种封装方式能让页面代码非常干净，业务组件里不需要重复处理鉴权和错误提示的逻辑。

3.4 Element UI的列表与表单渲染

前端UI组件库用的是Element UI，电影列表页面基本就是el-card栅格布局加v-for循环，评分功能用el-rate组件，表单页用el-form。你可以大胆地说"项目采用了组件化开发思路，将电影卡片、评分组件等抽成公共组件复用"，这个在代码里是确实做得到的。

4. 数据底座：SQL脚本与数据库表设计背后的逻辑

4.1 核心表结构拆解

我打开项目自带的init.sql脚本看完表结构之后，觉得这个设计是下了功夫的——它覆盖了一个完整系统需要的所有核心实体，而且表之间通过外键逻辑建立了清晰的关联关系。核心表单大概有这几张：

• 用户表（t_user或sys_user）：用户ID、用户名、密码（MD5加密存储）、昵称、头像、注册时间、角色字段（区分普通用户和管理员）；
• 电影表（t_movie）：电影ID、电影名、封面图URL、导演、主演、类型、简介、上映年份、地区、评分、评分人数；
• 评分表（t_rate）：主键ID、用户ID、电影ID、评分（1-5分或0-10分）、评分时间，以及一个唯一约束保证同一用户对同一电影只能评一次分，重复评分走更新逻辑；
• 收藏表（t_favorite）：用户ID、电影ID、收藏时间；
• 评论表（t_comment）：评论ID、用户ID、电影ID、评论内容、评论时间。

这五张表之间是什么关系？一个用户可以有多条评分记录、多条收藏记录、多条评论记录；一部电影可以被多个用户评分、收藏、评论。所以评分表、收藏表、评论表本质上都是"用户-电影"之间的关联表，这也正是协同过滤算法所依赖的数据来源。

我在帮同学审表结构时最常看到的问题就是：评分表中缺少联合唯一约束，导致同一用户对同一电影可以插入多条评分，算法算相似度时数据全乱了。这个项目的SQL脚本里用UNIQUE KEY把这个约束加上了，这是个加分项，值得学习。

4.2 为什么SQL脚本里要预置这么多模拟数据

协同过滤算法的效果和数据量强相关。你如果只往数据库里插10条评分，算出来的相似度基本是瞎猜；但如果有几百条覆盖了多个用户"共同观影"的评分，推荐结果就会明显合理起来。项目SQL脚本里预置的模拟数据，核心目的就是让算法在演示环境中有用武之地。

我在做数据填充测试时发现一个调参技巧：刻意让几个用户对同一批经典电影给出相近的高分，这样当你用其中一个用户登录时，推荐结果里会出现其他同口味用户看过、而你还没看过的电影，演示效果非常直观。这个技巧你在准备答辩演示时一定要用上。

4.3 从脚本到数据库：导入SQL的正确姿势

导入SQL脚本时，我推荐你用Navicat或者MySQL命令行工具，步骤很简单：

1. 创建一个和脚本中同名的数据库（或直接执行脚本里的CREATE DATABASE语句）；
2. 选中目标数据库，执行脚本文件；
3. 查看是否报错——最常见的问题是MySQL版本不兼容（比如用了新的utf8mb4字符集但旧库不支持）或者外键顺序导致建表失败。

执行成功后，检查一下几张核心表的数据行数，确保预置数据都进去了，再启动后端才有意义。

5. 环境准备与启动避坑：从JDK到Maven的完整流程

5.1 版本环境选择

我先说结论，这是我和一个同学折腾了一下午才得出的靠谱组合：

这里面最值得说的坑是Node版本和SpringBoot版本的匹配问题。Vue 2项目如果用了Node 17以上的版本，跑npm run serve时会报ERR_OSSL_EVP_UNSUPPORTED错误，这是OpenSSL的加密算法默认变更导致的。解法有两个：要么降Node版本到16以下，要么在package.json的scripts里加上NODE_OPTIONS=--openssl-legacy-provider这个环境变量。我建议直接装Node 16，省心。

5.2 SpringBoot侧的环境配置

后端启动之前，有几个配置需要核对一遍：

数据库连接配置（application.yml）：确认url里的IP、端口、库名和你的MySQL一致，用户名密码改成你自己的。如果MySQL是8.0，驱动类通常是com.mysql.cj.jdbc.Driver，连接串里建议加上serverTimezone=Asia/Shanghai防止时区报错。这个时区问题几乎每个跑MySQL 8的同学都会遇到，不配的话启动时直接给你一个The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized的报错，网上搜代码根本搜不着解决办法——老老实实加上时区参数就对了。

端口配置：默认后端端口一般是8080或8081，如果被占用就改掉，同时注意前端Axios封装的baseURL要和后端端口一致，这个我会在下一节详细说，因为它是前后端联调最经典的坑。

数据库初始化：打开Navicat，执行项目的SQL脚本，把表结构和预置数据导进去。

配置检查完毕后，在项目根目录执行mvn spring-boot:run，或者用IDEA直接运行Application类。启动日志里看到类似Tomcat started on port(s): 8081的字样，说明后端已经起来了。

5.3 Vue前端环境配置与启动

前端步骤相对简单但坑也不少。首先确保Node和npm装好了，然后进入前端目录（一般是frontend或vue-web）执行：

bash复制npm install

这一步有两个高频坑：一是网络问题导致依赖下载超时，解决方式是换淘宝镜像源：

bash复制npm config set registry https://registry.npmmirror.com

二是依赖版本冲突，项目原本用的依赖锁文件和当前node_modules不完全匹配。此时可以删掉node_modules文件夹和package-lock.json，重新执行npm install。

依赖安装成功后再执行：

bash复制npm run serve

启动成功后终端会打印一个本地访问地址，通常是http://localhost:8080。用浏览器打开就能看到前端页面了。

5.4 前后端联调时最容易出的"端口不一致"问题

前后端能各自启动只是第一步，真正让它们"手拉手"工作，靠的是接口地址的正确拼接。前端代码里Axios的baseURL必须指向后端的地址，这个配置通常写在src/utils/request.js的baseURL字段或.env.development环境变量文件里。

如果A同学把后端端口改成了8082，忘了改前端baseURL，前端请求依然打到8081，那结果就是页面能打开、但所有列表数据都是空的，浏览器F12控制台一片红色的404或ECONNREFUSED。这个问题的排查方法很简单：打开浏览器开发者工具，看Network面板里请求的真实URL是什么，和后端启动日志里的端口一对，马上就知道问题出在哪。

5.5 启动顺序的讲究

正确启动流程是先启动数据库，再启动后端，最后启动前端。数据库没起来后端连不上直接报错；后端没起来前端所有接口全挂。我在指导同学时还会刻意让他把数据库、后端、前端的启动窗口分开排列，方便观察每个部分的日志输出。后端日志里能看到SQL语句和请求记录，前端终端里能看到编译报错和代理转发信息，一旦出问题，三个窗口的日志就是定位问题的第一手线索。

6. 核心代码走读：协同过滤的实现到底写了什么

6.1 数据加载与评分矩阵构建

这一节我直接带着你读一段代码。这个项目的推荐算法核心类通常叫RecommendService或者CollaborativeFilter，核心逻辑是先加载评分数据：

java复制// 从评分表查出所有评分记录
List<Rate> rateList = rateMapper.selectList(null);
// 构建用户 -> (电影 -> 评分) 的嵌套Map
Map<Integer, Map<Integer, Double>> userRatingMatrix = new HashMap<>();
for (Rate rate : rateList) {
    userRatingMatrix
        .computeIfAbsent(rate.getUserId(), k -> new HashMap<>())
        .put(rate.getMovieId(), (double) rate.getScore());
}

这两行代码是整个推荐系统的地基。computeIfAbsent这个函数很巧妙：如果当前用户还没有评分记录，就给他创建一个新的Map，然后把电影和评分塞进去。最终形成的结构就是"用户A看过哪些电影、分别打了多少分"的完整画像。

6.2 皮尔逊相似度计算

接下来是相似度计算的实现：

java复制private double pearsonSimilarity(Map<Integer, Double> userARatings,
                                 Map<Integer, Double> userBRatings) {
    // 找出两个用户共同评分过的电影
    Set<Integer> commonMovies = new HashSet<>(userARatings.keySet());
    commonMovies.retainAll(userBRatings.keySet());
    
    // 没有共同评分时相似度为0
    if (commonMovies.isEmpty()) {
        return 0.0;
    }
    
    // 计算均值
    double sumA = 0, sumB = 0;
    for (Integer movieId : commonMovies) {
        sumA += userARatings.get(movieId);
        sumB += userBRatings.get(movieId);
    }
    double avgA = sumA / commonMovies.size();
    double avgB = sumB / commonMovies.size();
    
    // 计算皮尔逊相关系数
    double numerator = 0, denomA = 0, denomB = 0;
    for (Integer movieId : commonMovies) {
        double diffA = userARatings.get(movieId) - avgA;
        double diffB = userBRatings.get(movieId) - avgB;
        numerator += diffA * diffB;
        denomA += diffA * diffA;
        denomB += diffB * diffB;
    }
    
    if (denomA == 0 || denomB == 0) {
        return 0.0;
    }
    return numerator / (Math.sqrt(denomA) * Math.sqrt(denomB));
}

这段代码本质上就是在套公式。需要注意两个边界情况：一是两个用户没有共同评分过的电影时直接返回0，这是硬性前提；二是分母为0时（一个用户对所有共同电影的打分完全一样），直接返回0避免除零异常。这两个防御性判断在算法实现里非常重要，很多新手写的时候容易漏掉。

6.3 邻居选取与推荐生成

相似度算完后，把当前用户和所有其他用户的相似度收集起来，排序取TopK：

java复制List<Map.Entry<Integer, Double>> similarityList = new ArrayList<>(similarityMap.entrySet());
similarityList.sort((a, b) -> Double.compare(b.getValue(), a.getValue()));
List<Map.Entry<Integer, Double>> neighbors = similarityList.subList(0, Math.min(K, similarityList.size()));

然后遍历邻居们看过的电影，加权算推荐度：

java复制Map<Integer, Double> recommendScores = new HashMap<>();
for (Map.Entry<Integer, Double> neighbor : neighbors) {
    int neighborId = neighbor.getKey();
    double similarity = neighbor.getValue();
    Map<Integer, Double> neighborRatings = userRatingMatrix.get(neighborId);
    for (Map.Entry<Integer, Double> ratingEntry : neighborRatings.entrySet()) {
        int movieId = ratingEntry.getKey();
        // 当前用户已经看过的电影不推荐
        if (userRatings.containsKey(movieId)) {
            continue;
        }
        double weight = similarity * ratingEntry.getValue();
        recommendScores.put(movieId, recommendScores.getOrDefault(movieId, 0.0) + weight);
    }
}

这段代码的核心逻辑在于"当前用户看过的电影直接排除"，避免推荐出用户已经看过的内容。这个细节不写进去，推荐结果里全是用户已经标记过的电影，演示效果会非常尴尬。最后把recommendScores按value倒序排，取topN返回，就完成了整个推荐流程。

如果你决定在答辩时展示"我改进了算法"，我建议你不动核心逻辑，先尝试调整几个参数：比如把K从10改成20观察推荐结果变化，或者把皮尔逊相关系数改成余弦相似度对比效果。这种级别的改动足以说明你读懂了代码，又不至于引火烧身。

6.4 兜底策略：没有评分数据时怎么推荐

不少同学拿到代码后会问："我登录一个新用户，点推荐接口，返回什么？"答案是不一定报错，可能返回空列表，也可能返回热映榜。具体逻辑取决项目里有没有写兜底。

一个有完整考虑的推荐模块，在获取当前用户评分数据时应该判断：如果这个用户一条评分都没有，直接走热门电影列表。这个判断在代码里通常长这样：

java复制Map<Integer, Double> userRatings = userRatingMatrix.get(userId);
if (userRatings == null || userRatings.isEmpty()) {
    // 冷启动，返回评分最高的电影列表
    return movieMapper.getTopRatedMovies(limit);
}

这个兜底策略虽然只有几行代码，但在答辩讲"系统健壮性"时是很好的素材。你要是没有这行代码，建议自己补上，相当于给冷启动场景上了一道保险。

7. 项目讲解加分秘笈：如何让答辩老师觉得"这项目是你的"

7.1 你需要亲手验证的七个功能点

拿到源码后，别急着炫技，先像个测试工程师一样把一个一个功能点走一遍。我列一个清单，这些是你答辩演示时必须能流畅展示的：

1. 注册一个新账号，确认能登录成功；
2. 用预置的普通用户账号登录，首页能展示电影列表；
3. 给几部电影打分，刷新评分记录页面，确认分数已入库；
4. 收藏两部电影，进个人中心能看到收藏列表；
5. 点击"推荐"按钮，确认推荐结果不为空，且推荐列表里没有自己已经看过的电影；
6. 用管理员账号登录，进后台管理，尝试编辑一部电影的信息；
7. 退出登录后，直接访问首页URL，确认被路由守卫拦回登录页。

这七个点全部走一遍，你对系统的功能边界就有了直观认知，比单纯看代码效率高得多。

7.2 可能被追问的高频问题与应答思路

按我的经验，答辩老师对推荐系统的追问通常集中在几个方向，我整理了一份"题库"：

"为什么选择协同过滤而不是基于内容的推荐？"
答：协同过滤不依赖电影内容的元数据（导演、类型、演员等），只需用户的评分行为，能够发现用户自己都未必意识到的兴趣关联。基于内容的推荐则需要维护大量的电影特征标签，特征工程成本高。在评分数据相对充足的场景下，协同过滤实现更简单、效果也更直觉。

"皮尔逊系数和余弦相似度有什么区别？为什么选皮尔逊？"
答：皮尔逊相关系数在计算前对每个用户的评分做了均值中心化，能抵消不同用户打分尺度不一致的问题。比如一个用户习惯打4到5分，另一个用户习惯打1到5分，用余弦相似度会把这种打分习惯差异误判为兴趣差异，皮尔逊系数则不会。

"新用户没有任何评分，系统怎么推荐？"
答：走冷启动兜底策略，返回平台热播榜或评分榜。后续用户产生评分行为后，推荐列表会逐渐个性化。

"系统的推荐是实时的吗？"
答：当前是离线定时计算或用户触发时计算，不追求实时性。如果要做到实时推荐，需要引入消息队列和流式计算框架，工程复杂度会大幅提升，在毕设场景下没有必要。

这些问题你会答了，答辩的基本盘就稳了。

7.3 演示时最稳妥的"脚本式操作顺序"

我建议你演示时遵循一个"由广到深、由易到难"的顺序：

1. 先展示系统整体架构，说说前端用什么、后端用什么、数据库几张表；
2. 演示最外层功能：登录、看列表、看详情、评分、收藏；
3. 重点演示推荐功能：找一个评分数据最丰富的测试账号登录，点推荐，展示推荐结果，并说明"这是基于用户的协同过滤算出来的"；
4. 打开数据库或后端日志，指着评分表说"算法用的就是这张表的数据"；
5. 如果老师追问算法细节，再展开讲相似度计算流程。

这套顺序的好处是：即使前几分钟节奏有点慢，核心的推荐功能也一定有时间演示到；万一时间紧张，靠前面的功能展示和架构讲解也已经能让老师了解项目的全貌。

7.4 如果你想把项目"升级"出新意

最后说点进阶的建议。如果你不满足于"能运行、能答辩"，想让项目在评优时更有竞争力，可以在现成系统上做这三个方向的扩展，每个方向的改动量都不大，但讲出来非常加分：

1. 混合推荐策略：在协同过滤的基础上，叠加一个简单的基于电影类型偏好的规则推荐（比如用户看过3部以上科幻片就推荐更多科幻片），两种结果做加权融合，这就是一个"混合推荐"的雏形；
2. 推荐结果解释：在推荐卡片上标注"因为你看过《星际穿越》，所以推荐了《盗梦空间》"这类文案，本质上是把推荐过程透明化，这在业界叫"可解释推荐"，很能提升用户体验；
3. 后台数据可视化：在后台管理页面加两个图表——比如用ECharts展示每个电影ID被推荐的次数、用户评分的分布直方图。前端本身已经有Vue基础，引一个ECharts组件并不复杂，但看起来系统会瞬间高级不少。

我在实际带毕设的过程中发现，凡是愿意花时间在现成项目上做一两个"微创新"的同学，答辩成绩普遍比只念PPT的高一到两个档次。因为老师一眼就能看出来，你是真的在思考这个系统还能怎么变好，而不只是把别人的代码跑通。

最后再分享一个实用建议：把项目代码里所有你认为关键的类、方法、表，花一个下午画出简单的调用关系图，存在手机里。答辩前十分钟翻一遍，比你背十页PPT都有用。我就是靠这个习惯，帮好几个同学在答辩现场快速回忆起"推荐Service里那个兜底方法到底叫什么名字"这类细节，避免卡壳。技术这条路没有捷径，但一定有方法——把每一步都弄明白，比什么都重要。