SpringBoot电影评论推荐系统实战：架构、算法与避坑指南

每年到了毕业设计开题季，我都能收到大批类似的消息：博主，我的题目是“基于SpringBoot电影评论数据分析与推荐系统”，我刚装好JDK和IDEA，下一步该干嘛。这个题目在计算机毕业设计里的出现频率高得离谱，名字看着也唬人，又“数据分析”又“推荐系统”，好像要把机器学习、大数据全用一遍。但真正拆开以后你会发现，它更像一个“业务系统 + 算法模块 + 可视化面板”的三件套组合。

这篇文章我就从自己完整做过一遍的角度，直接把这个题目的选型、架构、评论分析、推荐算法、表结构、前端可视化和最后部署避坑全部过一遍。目标不是教你堆一套“看起来高深”的代码，而是给你一条能真正跑通、能讲明白、能让论文写起来也顺手的路线。适合谁看？正被毕设折磨的人最合适，另外想用SpringBoot练手做实战项目的初学者也可以参考。

1. 先把题目拆开：这个系统真正要做的四件事

1.1 别被“分析”和“推荐”两个字吓到

“电影评论数据分析”听起来要上Hadoop、Spark，实际上在SpringBoot项目语境下，它通常只做两件事：对评论数据进行聚合统计，以及对评论文本做关键词抽取和简单情感倾向判断。前者用SQL就能完成，后者找一个分词工具包也比想象中简单。而“推荐系统”在这个项目里最常见的落地方案是协同过滤，尤其是基于物品的协同过滤ItemCF，也就是“你喜欢A电影，那就把和A最相似的B电影推荐给你”。

我说句实在话，毕业设计阶段的评审老师不会指望你提出新的推荐算法，他们更关注三件事：系统能不能完整跑起来、推荐结果在界面上看不看得出来、答辩时能不能把原理讲清楚。你只要在这个框架内把每一个模块做得完整、演示流畅，就已经超过大部分只做了CRUD的同学了。

1.2 真实工作量拆解：先搭骨架，再补算法

我把这个题目按模块拆成一张表，你感受一下权重：

建议第一步永远不是去研究推荐算法，而是先把用户、电影、评论三个基础表建好，把增删改查跑通。理由很简单，协同过滤需要从评论表里读取用户评分数据，评论分析也需要有评论文本，没有业务数据支撑的算法就是空中楼阁。

1.3 明确你的业务闭环

一个合格的项目必须有一个能演示的最小闭环：用户登录注册后，能在电影列表中选择一部电影，在详情页查看信息、发表评论并打分，进入个人中心能看到自己的历史评论，回到首页能获得一组“猜你喜欢”，最后管理员登录后台能看到电影评分分布、评论趋势等图表。

这个闭环一旦跑通，你的论文里的功能模块图、系统流程图、技术架构图基本都能画出来。我见过很多学生写到第三章功能设计时开始编内容，就是因为代码本身没有形成闭环，业务逻辑不清楚。先把这个链条理清，后面所有的设计都是在往这个骨架上贴肉。

2. 技术选型直接决定了你能少踩多少坑

2.1 SpringBoot版本：为什么我强烈建议2.7.x加JDK8

每次看热搜词里都有一堆“springboot版本太高”“springboot jdk1.8打包”相关问题，这几乎是所有自学者都会掉进去的坑。SpringBoot 3.0发布后，底层把javax命名空间迁移到了jakarta，很多旧教程里的代码、第三方依赖和配置方式都不再兼容，你搜索到的很多老博客内容也会失效。

所以除非你已经有明确需求，否则毕设优先选择SpringBoot 2.7.18 + JDK 8。这组搭配目前生态最成熟、网上遇到的坑最少、部署到服务器上也最省心。等你熟练了再考虑SpringBoot 3不迟，没必要在毕业设计基础阶段跟新版本硬磕。

2.2 ORM层选MyBatis-Plus，数据库选MySQL

Java后端目前的主流搭配是MyBatis-Plus + MySQL。MyBatis-Plus的BaseMapper提供了单表CRUD方法，省去大量手写XML的时间，代码也简洁很多。评论数据量小，不需要上Redis做缓存，MySQL一张表完全够用。

这里特别注意一个问题：低版本的SpringBoot项目如果用了高版本的MyBatis-Plus，可能会遇到分页插件配置不生效、依赖冲突等麻烦。建议使用3.5.2或3.5.3这个阶段版本，配套文档相对稳定。

2.3 推荐算法用Java原生实现还是调Python服务

我见过很多学生想把算法放到Python里跑，然后用Java后端调用。如果你是为了练技术，没问题。但作为毕业设计项目，这会明显增加部署负担：服务器上要跑两个进程、Java和Python之间要定义接口协议、还得处理跨语言调用的异常情况。你想想答辩前部署服务器时，多一个组件就多一堆不可控因素。

实际上ItemCF协同过滤用Java写并不复杂，也就是遍历用户历史评分、计算余弦相似度、排序取TopN，代码量不会超过300行。另一个常见选择是引入HanLP做中文评论分词和情感分析，它本身就是Java库，直接作为依赖加进SpringBoot工程就行，不需要额外起Python环境。整个项目最后就是一个可执行的Jar包，部署顺畅得多。

2.4 前端不是重点，够用即可

前端可以选择Thymeleaf模板引擎加Bootstrap加ECharts，后端渲染页面，代码最简单，适合时间紧张的学生。也可以选择Vue3 + Element Plus做前后端分离，但意味着要多维护一套前端工程，还要处理跨域。

从纯毕业设计维度出发，Thymeleaf + Bootstrap + ECharts是我个人的推荐。但如果你的开题报告已经把“前后端分离”写进去了，那就用Vue，项目里用axios调后端接口。前端可以打包后放到SpringBoot的src/main/resources/static目录下统一部署，不必单独跑Nginx，这样既能体现前后端分离思想，又不至于让部署复杂化。

3. 评论数据分析：词频统计、评分分布与趋势图

3.1 避免空谈“大数据分析”，把数据来源先想好

评论文本从哪来，这是很多学生没想清楚就开工，最后卡壳的地方。公开数据集MovieLens包含大量评分数据，但它的评论内容字段很少，无法满足“评论分析”的需求。实际项目里，建议用公开数据集中的评分信息，再人工构造一部分带有情绪色彩的评论文本灌进数据库。你可以准备大约200到500条评论，内容覆盖好评、中评、差评，包含“剧情”“演技”“特效”等关键词，这样后面做热词统计和情感分析时数据才不会太难看。

人工构造数据虽然听起来费劲，但好处是可以精确控制每条评论的情感倾向和主题词分布，便于你在系统里明确展示分析效果。如果老师问到数据来源，你就按照“初始数据来自某公开数据集，再结合本地整理扩充了评论文本”这个思路讲，不会有问题。至于考虑爬取商业网站数据的方向，尽量不碰，免得惹来合规风险。

3.2 HanLP分词集成到SpringBoot

中文评论分析和英文不一样，首先要分词。用户写“这部电影的剧情真的很精彩”，你不能把整句话当做一个词去统计，得切成“这部 / 电影 / 的 / 剧情 / 真的 / 很 / 精彩”。HanLP是一个非常好用的Java自然语言处理库，支持中文分词、词性标注、关键词抽取等功能。

在pom.xml中加入依赖：

xml复制<dependency>
    <groupId>com.hankcs</groupId>
    <artifactId>hanlp</artifactId>
    <version>portable-1.8.4</version>
</dependency>

portable版本内置了标准分词所需的数据，不需要额外下载模型，几百KB的依赖就能完成常规任务。完成依赖引入后，写一个独立的WordCountUtil工具类，我贴一份可运行的核心代码：

java复制import com.hankcs.hanlp.HanLP;
import com.hankcs.hanlp.seg.common.Term;

import java.util.*;
import java.util.stream.Collectors;

public class CommentAnalyzeUtil {

    private static final Set<String> STOP_WORDS = new HashSet<>(Arrays.asList(
        "的", "了", "是", "和", "也", "很", "都", "就", "在", "我", "他", "这部", "电影",
        "一个", "没有", "自己", "真的", "因为", "所以", "但是", "还是", "可以", "觉得"
    ));

    /**
     * 从一批评论中统计出现频率最高的 topN 个词
     */
    public static Map<String, Integer> topWords(List<String> comments, int topN) {
        Map<String, Integer> wordCount = new HashMap<>();
        for (String comment : comments) {
            if (comment == null || comment.trim().isEmpty()) {
                continue;
            }
            List<Term> terms = HanLP.segment(comment);
            for (Term term : terms) {
                String word = term.word.trim();
                if (word.length() < 2) {
                    continue;
                }
                if (STOP_WORDS.contains(word)) {
                    continue;
                }
                wordCount.put(word, wordCount.getOrDefault(word, 0) + 1);
            }
        }
        return wordCount.entrySet().stream()
                .sorted(Map.Entry.<String, Integer>comparingByValue().reversed())
                .limit(topN)
                .collect(Collectors.toMap(
                    Map.Entry::getKey,
                    Map.Entry::getValue,
                    (oldVal, newVal) -> oldVal,
                    LinkedHashMap::new
                ));
    }
}

注意停用词表一定要手动维护。我做这个项目时第一次得出的热词排名前几名全是“电影”“这部”“真的”，一点信息量都没有。你需要把评论文本中频繁出现但对分析无意义的词过滤掉，才能使“剧情”“演技”“特效”“结局”这类真正代表观众关注点的词浮上来。

3.3 评分分布和评论趋势用SQL聚合就够

这类统计其实完全不需要写复杂Java算法，直接用SQL分组聚合，然后封装成接口返回给前端图表组件即可。

评分分布用这样一条SQL：

sql复制SELECT score, COUNT(*) AS cnt
FROM movie_comment
GROUP BY score
ORDER BY score ASC;

如果评论表中score是1到5的整数，就能得到每个评分数量的柱状数据。评论趋势用日期分组也能轻松实现，假设你要按天统计最近30天的评论量：

sql复制SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS comment_date, COUNT(*) AS cnt
FROM movie_comment
WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
GROUP BY comment_date
ORDER BY comment_date ASC;

建议把这些统计SQL做成独立的Mapper方法，然后放在一个专门的StatsService中统一管理。另外，统计数据尽量只对最近一段时间、或符合某种筛选条件的数据做聚合，而不是打开页面就把全表扫描一遍。虽然项目数据量小不影响性能，但写代码的习惯要从这些细节培养起来。

3.4 一个简单但能讲出道理的情感倾向分析

评论情感分析在很多毕设里是评分标准里的加分项。真正的深度学习文本分类模型没必要上，你只需要一个基于情感词典的规则打分器。我把实现步骤拆一下：

准备两个词典，正面词如“精彩”“好看”“震撼”“经典”“喜欢”，负面词如“无聊”“失望”“差劲”“尴尬”“烂片”。对一条评论分词后，遍历词表，遇到正面词总分加1，遇到负面词总分减1，根据总分判断是正向、中性还是负向评论。

核心代码剪影如下：

java复制public static String analyzeSentiment(String comment) {
    int score = 0;
    for (Term term : HanLP.segment(comment)) {
        String word = term.word;
        if (positiveWords.contains(word)) score++;
        if (negativeWords.contains(word)) score--;
    }
    if (score > 0) return "positive";
    if (score < 0) return "negative";
    return "neutral";
}

需要注意两个坑：第一，情感词典要和前面停用词一样放入配置文件或数据库，方便你后期调整；第二，不要指望它对“这部电影并不无聊”这种带转折的句子判断正确，因为规则引擎没有上下文理解能力。遇到这种局限性，答辩时坦诚承认“规则模型在否定句场景存在不足，后续可引入深度学习模型优化”，远比硬吹效果好。把统计结果和人工标注做一次对比，在论文里给出准确率数据，也算是个小亮点。

4. 推荐模块的实现：基于物品的协同过滤

4.1 为什么这个题目选ItemCF而不是UserCF

回答推荐模块选型时，最常见的思路是介绍基于用户的协同过滤UserCF和基于物品的协同过滤ItemCF的区别：UserCF是找与你有相似观影偏好的其他用户，把他们喜欢的你没看过的电影推荐给你；ItemCF是找你评分过的电影，计算出与这些电影最相似的其他电影并推荐。

大多数情况下，用户数量远大于电影数量。比如你的系统有100个用户、50部电影，UserCF要对100个用户两两计算相似度，而ItemCF只需要对50部电影两两计算，计算规模小得多，效果稳定，给用户推荐的可解释性也更强。“因为你看过《霸王别姬》，所以为你推荐相似度更高的《活着》”这句话在推荐结果页面上展示出来，显得系统真的有智能逻辑，不是随便把高分电影塞给用户。

这个解释在论文和答辩里非常有用，它不是套话，而是真实的工程选择逻辑。

4.2 ItemCF的向量化思路：余弦相似度

先跳出公式，用一句大白话理解ItemCF：如果给两部电影打分的用户群体非常重合，也就是说看过A的人往往也会看B、给A高分的人往往也给B高分，那就认为A和B在观众眼里是相似的。

工程实现的第一步是从movie_comment表中拉取所有评过分的数据，构建一个内存里的评分矩阵。结构大概是：

java复制Map<Integer, Map<Integer, Double>> userRatingMatrix;
// key: userId, value: Map<movieId, score>

然后对任意两部电影A和B，用它们被共同用户打过分的数据算相似度。

第二步需要计算相似度，采用带用户评分均值修正的余弦相似度，可以避免某些用户习惯性打高分造成的误差。如果你不想一开始就引入修正，先用最基础的余弦相似度也行，公式如下：

similarity(A, B) = 同时给A和B打过分的用户的评分点积 / (A的评分向量模长 * B的评分向量模长)

在Java里的实现，我可以写一个片段：

java复制public double cosineSimilarity(Map<Integer, Double> movieAScores,
                               Map<Integer, Double> movieBScores) {
    double dot = 0.0, normA = 0.0, normB = 0.0;
    for (Map.Entry<Integer, Double> entry : movieAScores.entrySet()) {
        Integer userId = entry.getKey();
        double scoreA = entry.getValue();
        normA += scoreA * scoreA;
        Double scoreB = movieBScores.get(userId);
        if (scoreB != null) {
            dot += scoreA * scoreB;
        }
    }
    for (Double score : movieBScores.values()) {
        normB += score * score;
    }
    if (normA == 0.0 || normB == 0.0) {
        return 0.0;
    }
    return dot / (Math.sqrt(normA) * Math.sqrt(normB));
}

如果你觉得在代码中维护双层的Map太绕，也可以用数据库把每个用户的所有评分都查出来放在一个List里，再在Java层转换为Map，这是一个常规操作。

4.3 给目标用户生成推荐TopN

有了电影之间的相似度矩阵，就可以对某个用户做推荐。对用户已经评过分的每一部电影，找出它最相似的几部电影；再把这些相似电影里用户没看过的电影按加权分排序，取TopN作为推荐结果。

预测用户对未看电影P的喜欢程度，标准做法是加权求和：

score(P) = 对用户看过的每部电影N，累加 sim(P, N) * 用户的评分(N)，最后除以累加的sim值，得到用户的预估评分。

看完这个公式你就明白了，为什么推荐结果需要一个Service类来做。不要把计算逻辑写在Controller或者页面里，独立出RecommendService，输入userId，输出RecommendItem列表，调用方不必关心内部算法。这样整个项目的分层才清晰。

4.4 冷启动和离线缓存

协同过滤有两个让人头疼的问题：新用户没有任何评分记录，算法无法给他算推荐；新电影没有任何人评分，算法也无法把它推荐给别人。解决办法很粗暴但很有效：用基于热度或基于时间的规则做兜底。把系统里评分人数最多、平均分最高的几部电影作为新用户的初始推荐列表，等用户产生了几条评分记录后，再切换为ItemCF推荐。

另一个工程上的重点是不要把协同过滤计算放在用户请求的链路上。不然每次有人访问推荐页面，系统都要把所有用户的评分数据重新加载一遍再计算一遍，完全没有必要。正确做法是设计一个定时任务，例如Spring的@Scheduled注解，每天凌晨2点重新计算一次全量用户的推荐结果，写入一张recommend_result表。用户在页面请求推荐时，后端只做一次普通查询。

这个“离线计算”和“在线展示”分离的思路，在论文中能体现出你的架构意识。面试和答辩时提到这一点，往往会有额外的好感。

5. 数据库表结构与核心接口设计

5.1 表结构：最少6张表

围绕业务闭环，我建议按下面的表结构设计，实际上这也是最少需要维护的6张核心表：

movie_similar表和recommend_result表是推荐模块的产物。相似度离线计算后写入movie_similar，给用户实时推荐时直接查recommend_result，不用边请求边运算。很多学生的表结构设计里漏了这两张结果表，导致Controller里频繁写一堆算法代码，这不是合理的设计。

movie_comment表里的score字段，我建议用TINYINT类型表示1到5分。有人问是否要把评分单独拆一张rating表，从我实操经验看，毕业设计阶段没有必要。一个用户对一部电影通常只有一次有效评论，把评分和评论内容放在同一行记录中，统计分析时写SQL更顺手，理解起来也直观。

5.2 核心接口设计参考

RESTful接口可以按资源维度拆：

统一返回体要在一开始就定好，我在项目里通常用下面的JSON结构：

java复制public class Result<T> {
    private Integer code;      // 200表示成功
    private String message;
    private T data;
}

前后端所有接口都返回这个格式，前端判断code为200后再取data，异常处理会统一很多。代码别写到resful接口时返回裸的List或Map，一旦出现异常，前端无法统一处理。

5.3 安全校验要把好关

我见过不少学生的登录接口直接把前端传来的明文密码和数据库里的明文密码比对，这种实现虽然能运行，但会暴露许多安全问题。建议在注册时使用常见的哈希算法存储密码，不了解加密算法的可以直接用Spring Security里的BCryptPasswordEncoder，不需要引入整套Security框架，单独拿这个工具类使用即可。

评论接口也要限制一下：未登录用户不能评论；同一个用户对同一部电影只能评论一次。后者可以先查库再插入，或者在表上加唯一索引。

6. 可视化页面：如何让“分析结果”一眼可见

6.1 页面模块如何规划

前端页面建议分成用户前台和管理后台两大块。用户前台主要承担闭环演示功能：首页推荐电影卡片、搜索结果页、电影详情页、个人评论记录页。管理后台则集中展示数据统计能力：登录进去能看到一个数据分析面板，上面分布着“总用户数”“总评论数”“平均评分”等摘要数据卡，以及评分分布图、评论趋势图、热词图、电影评分Top榜等图表。

想要让评委一下子看懂你在做什么，数据面板页面比任何文字描述都管用。很多学生把图表藏在三级菜单深处，演示时自己都找不到，这绝对是失误。我给毕设演示的建议是，把数据分析页面直接设置为管理后台的首页，登录管理账号后第一眼就能看到所有图表数据，效率最高。

6.2 用ECharts快速做可视化

ECharts是目前最主流的开源图表库。在HTML页面中引入它的JS文件后，你只需要给每个图表指定一个指定大小的div容器，再通过JavaScript配置option对象就能渲染出图表。

比如评分分布饼图的option大概长这样：

javascript复制$.ajax({
    url: '/api/stats/rating-distribution',
    type: 'GET',
    success: function (res) {
        if (res.code === 200) {
            var chart = echarts.init(document.getElementById('ratingChart'));
            chart.setOption({
                tooltip: { trigger: 'item' },
                legend: { bottom: '0%' },
                series: [{
                    name: '评分分布',
                    type: 'pie',
                    radius: ['35%', '70%'],
                    data: res.data.map(function (item) {
                        return { name: item.score + '星', value: item.count };
                    })
                }]
            });
        }
    }
});

评论趋势图通常用折线图，类型设为line；电影Top榜用柱状图，类型设为bar。热词的话，常规做法是用词云展示，需要额外引入echarts-wordcloud插件。如果不想引入额外包，把统计出来的Top热词做成横向条形图效果也不差。展示数据方式服务于论文里“数据分析”这个模块的描述，重点是图表能跟着数据库内容动态变化，而不是写死的静态图。

6.3 词云图的中文乱码是个小坑

很多人做词云时发现页面显示的文字是方块或者乱码，原因是ECharts wordcloud插件在渲染时用了canvas的默认字体，对中文支持不稳定。解决方法是给textStyle显式设置中文字体：

javascript复制textStyle: {
    fontFamily: 'Microsoft YaHei, PingFang SC, sans-serif'
}

另外后端返回的词频数据，有些词很长，建议在service层先过滤掉长度超过4个字的不常见词，这样词云整体排版更干净。

7. 从本机运行到答辩演示：高频坑位与准备清单

7.1 JDK版本过高导致项目启动失败

如果你用的是SpringBoot 2.7系列，却给本机装的是JDK 17或更高，maven编译阶段可能不会立刻报错，但项目启动时经常出现“UnsupportedClassVersionError”或者某些依赖注入失败。更诡异的是，有时你换成SpringBoot 3.0以后，原代码里使用javax.servlet的部分又会编译报错。

我总结出一条最稳妥的路线：SpringBoot 2.7对应JDK 8，SpringBoot 3.0对应JDK 17及以上。做毕设不需要追求新，直接统一装JDK 8，然后IDEA中设置Project SDK、Module SDK、maven的JDK都用Java 8，打开terminal输入java -version确认版本，基本就不会再为JDK折腾了。

7.2 MySQL中文乱码

MySQL中文乱码是老生常谈，但每年仍然有大量人踩。建库时就要显式指定字符集：

sql复制CREATE DATABASE movie_recommend DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

jdbc连接串也要带上编码参数和时间参数：

properties复制spring.datasource.url=jdbc:mysql://localhost:3306/movie_recommend?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

如果你部署到Linux服务器上，还要检查一下系统是否安装了中文字体。很多服务器渲染图片或导出报表时中文变方块，跟数据库没关系，是系统缺字体，用yum安装fontconfig和中文支持包即可。

7.3 MyBatis-Plus分页查询不生效

MyBatis-Plus旧版本里配置一个PaginationInterceptor就能用分页，但在3.5.x版本之后配置方式变了。如果你发现调用page方法返回的total始终为0，或者数据全部查出来没有被分页，多半是没有把分页插件注入容器：

java复制@Configuration
public class MybatisPlusConfig {

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

这个坑排查起来很费时间，因为编译不会报错，只有运行结果不对。建议新建项目后第一件事就是配置分页并验证，不要等到模块做完了才发现基础能力有问题。

7.4 Maven依赖下载慢，建议配国内镜像

很多学生在宿舍网络环境下拉依赖能等上几十分钟，然后误以为IDEA卡住了。其实只需要修改maven的settings.xml，加入国内仓库镜像地址，依赖下载速度会提升明显。这里我不贴具体公司名，但通过搜索引擎搜“maven settings 镜像”就能找到合适的配置。

7.5 演示数据准备：推荐结果为空才是最大的翻车点

本地开发时推荐算法可能一切正常，但演示现场却可能因为你当前登录的是新注册用户，该用户没有评分数据，协同过滤算不出推荐列表，页面上出现“暂无推荐”。我建议做以下准备：

至少准备10个以上的测试用户、30部以上电影、400条以上带评分的评论，保证每个主要测试账号都有10条以上历史打分记录。演示前专门用一个账号A来操作：注册登录，评分三五部电影，刷新后展示推荐列表。另一个备用账号B提前预留充分的评分数据，假如账号A现场操作出了问题，立即切换到账号B，推荐结果依旧存在。多准备一条路，就能尽量避免演示时的尴尬局面。

7.6 答辩之前把原理梳理成口头表达

算法代码写的再好，表达不出来也会丢分。回答“协同过滤是什么意思”时，不要只背定义，可以这样讲：先举最简单的例子，比如一百个人看过《霸王别姬》，其中八十个人也看过《活着》，我们就认为这两部电影在观众心里相似度比较高。用户A看过《霸王别姬》但没有过《活着》，系统就会把《活着》放进推荐列表。这种表达比抽象讲公式更能让评委快速听懂。

同时建议你提前准备好页面截图，把“推荐理由”的字段在应用界面上展示出来，让用户看到“因为您看过《霸王别姬》，所以为您推荐《活着》”。在论文和答辩里，这种可视化表达非常重要，评委往往会问这块，这也是你体现项目完成度的最好切面。

我在实际操作中最大的体会是，这类毕设项目的关键不在于算法有多复杂，而在于能否把不同模块咬合成一个完整系统。如果只是把代码跑通而不思考推荐结果从哪来、评论数据如何进入分析模块，那其实是最大的浪费。最后再分享一个小经验：在项目里把算法逻辑独立到recommend包，所有推荐结果写入结果表，以后无论是想升级算法还是应对答辩演示，你都会感谢当初这个决定。