做毕业设计这几年有个选题几乎年年都能看到就是“在线教育平台”。你随便在平台上搜一下Java方向的毕设里十有八九是xx管理系统、xx商城剩下那一两个有点技术含量的基本就是“推荐系统在线教育”这个组合。今天想聊的正是这个方向里一个非常典型的题目基于SpringBoot和协同过滤推荐算法的线上安全教育平台。这类项目一般配套完整源码、论文圈内叫LW、部署说明和演示视频号称一条龙交付。但说实话源码谁都能拿到真正值钱的不是你拷下来的那堆代码而是你能不能把这个项目讲明白、能不能在答辩的时候把算法说清楚、能不能在部署的时候不卡壳。这篇文章我就从实战角度把这个项目从选题思路、算法原理、架构设计到部署排错完完整整拆一遍给你一份能直接照着操作和复述的干货。1. 项目整体设计与思路拆解1.1 毕设选题的价值为什么是“安全教育平台”而不是普通网校先说选题背景。在线教育平台本身已经很卷了你做一个“Java在线教育平台”听起来像个通用CRUD项目没有记忆点。但换成“线上安全教育平台”场景一下就具象了企业员工安全培训、学校消防安全教育、建筑工地入场安全考试、危化品从业人员的年度再教育……这些全是真实存在的需求。安全教育有个特点它不是随便学学就行的很多行业规定从业人员必须完成规定学时并通过考试所以课程体系、学习记录、考试认证这些模块天然比普通网校要求更硬核。从毕设角度讲这个选题的好处有三个。第一领域方向清楚功能模块能对应到真实业务写论文的时候“研究背景”和“需求分析”不会空洞第二平台需要课程推荐这就给你引入协同过滤算法提供了合理的业务场景而不是为了用算法而用算法第三安全教育平台涉及用户角色多管理员、教师、学员、课程类别多消防、交通、生产、防诈骗等数据量哪怕只有几百条也足够演示推荐效果。再直白点说毕设选题最重要的原则是“看着难但难的部分你自己能把握”。平台管理功能再复杂本质还是SpringBoot那一套增删改查真正有点区分度的就是那个推荐模块。所以你会发现这类项目的源码结构通常都是“管理系统为主干、推荐算法为亮点”这个搭配在论文里特别容易写出东西来——一路推进到核心算法章节自然就有深度了。1.2 技术栈选型的逻辑SpringBoot、MySQL、推荐算法三者怎么结合技术选型上这个项目几乎标配是SpringBoot MyBatis-Plus MySQL Vue或Thymeleaf配一个推荐算法模块。为什么是SpringBoot而不是传统Spring MVC说白了就是效率和自动配置。毕设开发周期就那么几个月SpringBoot的starter机制把大部分通用配置都封装好了你引入spring-boot-starter-web就能起Web应用引入mybatis-plus-boot-starter就能操作数据库不需要折腾一堆XML配置。这让你能把精力放在业务逻辑和推荐算法上而不是跟配置文件搏斗。推荐算法这块标题点明了“协同过滤”那落地上就有两种选型思路一是用现成的推荐框架如Mahout或Spark MLlib二是自己用Java写相似度计算和推荐逻辑。我建议毕设自己手写不要引入太重的东西。原因很现实手写协同过滤不过几十行代码却能让你在论文里完整展示算法推导过程答辩时老师问“相似度怎么算的”“推荐列表怎么生成的”你张口就能答如果用了框架老师追问框架里的实现细节你大概率会卡住。这个项目里推荐模块的典型实现方式是从数据库读用户评分或学习记录数据在内存里做相似度计算再生成推荐课程列表返回给前端展示。数据量不大内存计算完全够用。架构上前后端分离、单体部署是主流方案。SpringBoot提供RESTful接口Vue页面或模板引擎负责展示MySQL存业务数据Redis可加可不加。对毕设来说Redis不是必需品加了反而增加部署复杂度机器上没Redis时项目起不来演示现场会很尴尬。这个取舍后面还会细说。1.3 功能模块划分从用户角色反推系统功能系统功能模块建议按角色划分这样需求分析、数据库设计、论文目录都能对齐。三类核心角色管理员端用户管理学员、教师账号的增删改查、课程管理课程分类、课程内容上下架、考试管理试卷配置、考试成绩查看、数据统计学习人数、课程热门度、通过率。教师端课程资源上传视频、文档、PPT、习题维护、考试批阅如果是主观题或自动判分选择题、判断题。学员端课程浏览、课程学习记录学习进度、课程搜索、课程推荐、在线考试、学习证书/学时记录。在这基础上推荐模块就是学员每次进入首页或课程列表页时后端根据协同过滤算法给当前用户算出Top-N课程推荐。学习记录和评分表是推荐算法的数据来源这一点在设计数据库时就要想到否则推荐模块就会出现“无米下锅”的情况。我看到很多同学做这类项目时容易犯一个错把所有功能一股脑做出来页面一大堆但相互之间没有数据联通。比如学员学过哪些课程、学了多少、考试得了几分这些数据没有落到表里推荐模块就拿不到有效的“用户行为数据”。所以设计阶段一定要先把“推荐算法需要哪些数据”这个链条想清楚再倒推设计表结构。数据流顺了项目就成了一半。2. 协同过滤推荐算法的核心实现原理2.1 UserCF与ItemCF的选择课程推荐场景该用哪种协同过滤Collaborative Filtering有两个经典分支基于用户的协同过滤User-Based CF简称UserCF和基于物品的协同过滤Item-Based CF简称ItemCF。很多同学一上来就纠结选哪个其实只要理解了业务场景就不难。UserCF的思路是“找跟你兴趣相似的人看看他们学了什么推荐给你”。它的核心是计算用户之间的相似度。适合用户数量相对少、用户特征明显的场景比如新闻推荐用户兴趣变化快群体性热点明显。ItemCF的思路是“找出跟你学过的课程相似的课程推荐给你”。核心是计算物品之间的相似度。适合物品数量相对少、物品特征稳定的场景比如电商、视频网站。课程不是快消品一个用户一学期可能就学那么十几门课但课程总数可能是上千门这种情况下利用“用户对物品的行为”来计算课程之间的相似度推荐结果更有针对性。对安全教育平台来说我推荐以ItemCF为主理由有两点第一平台里课程是相对稳定的今天上架一门“消防安全基础”半年后它还是那门课适合预计算相似度第二学员与课程的交互矩阵是高度稀疏的一个用户只学过几十门课但库里有几百上千门物品相似度矩阵相对稠密计算出的结果更可靠。当然为了论文里体现“算法对比”你可以两个都实现然后说明为什么最终选择了ItemCF这是一个非常常见的加分写法。2.2 相似度计算公式余弦相似度和皮尔逊相关系数怎么落地协同过滤里最核心的公式就是相似度计算。代码写起来不复杂但公式推导和每一步的含义在论文里必须写清楚。余弦相似度Cosine Similarity是最常用的。假设有两个物品i和j它们分别对应一个评分向量由所有用户对它们的评分组成没评分的记为0余弦相似度就是这两个向量夹角的余弦值公式是sim(i,j) (R_i · R_j) / (|R_i| * |R_j|)其中R_i是物品i的评分向量分子是向量点积分母是两个向量模长的乘积。结果范围在-1到1之间越接近1表示越相似。它的特点是只关注向量的方向差异不关注数值整体大小。比如一个用户总是打4分另一个用户总是打3分但两人的评分变化趋势一致余弦相似度依然很高。皮尔逊相关系数Pearson Correlation Coefficient可以看作对评分做了中心化处理减去用户平均分后的余弦相似度公式是sim(i,j) Σ(u∈U)(R_ui - R_ū)(R_uj - R_ū) / sqrt(Σ(u∈U)(R_ui - R_ū)^2 * Σ(u∈U)(R_uj - R_ū)^2)这里的R_ū是用户u对所有物品评分的平均值。皮尔逊的好处是消除了用户评分尺度差异的影响。比如用户A习惯打3-4分用户B习惯打4-5分两人对课程的真实喜好可能一致皮尔逊就能更好地捕捉这种一致性。项目里我建议实现余弦相似度因为逻辑最简单、答辩时最好讲。想加深度的话就再写一个皮尔逊版本论文里放个对比表说明某些场景下皮尔逊表现更好但这属于锦上添花不是必需的。以下是用Java实现余弦相似度的一个核心代码片段public class CosineSimilarity { // 计算两个用户/物品评分向量的余弦相似度 public static double cosineSimilarity(MapInteger, Double vector1, MapInteger, Double vector2) { double dotProduct 0.0; double norm1 0.0; double norm2 0.0; for (Map.EntryInteger, Double entry : vector1.entrySet()) { Integer key entry.getKey(); double value entry.getValue(); norm1 value * value; if (vector2.containsKey(key)) { dotProduct value * vector2.get(key); } } for (Map.EntryInteger, Double entry : vector2.entrySet()) { norm2 entry.getValue() * entry.getValue(); } if (norm1 0.0 || norm2 0.0) { return 0.0; } return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); } }这段代码对新手非常友好两层循环求点积一层循环求模长最后做除法。注意两个边界处理一是当某个向量为空或者模长为0时直接返回0避免除零异常二是被比较的两个集合可能包含大量key用Map存数据时查询效率是O(1)整体时间复杂度为O(n)几百上千条数据完全没问题。2.3 推荐列表生成最近邻选取与Top-N推荐相似度算完之后怎么生成推荐列表就是下一步。ItemCF的推荐过程分三步第一步构建“用户-课程”评分矩阵。这个矩阵的每一行是一个用户每一列是一门课程矩阵里的值是用户对课程的评分。没学过或没评分的课程记为0。在项目里这个“评分”可以是显式的比如学员学完课程后打1-5分也可以是隐式的比如学习时长超过一定时长记为1或者完成考试记为3。毕设阶段建议直接用显式评分效果直观。第二步计算课程之间的相似度矩阵。对每一对课程计算余弦相似度得到一个n乘n的矩阵。n是课程总数。因为是毕设数据量这个矩阵完全可以存内存或存在一张数据库表里后台定时刷新即可。第三步生成推荐。对于当前用户u找到他评分过的课程列表假设是{c1, c2, c3}然后遍历这些课程的相似课程。计算候选课程i对用户u的推荐得分公式是pred(u,i) Σ(j∈N(u)) sim(i,j) * r_uj其中N(u)是用户u评分过的课程集合sim(i,j)是课程i和课程j的相似度r_uj是用户u对课程j的评分。这个公式的含义是候选课程i跟用户已经学过的课程越相似且用户对那门课的评价越高候选课程的推荐分就越高。最后对推荐分排序取前N个未学过的课程输出就是Top-N推荐。这里有一个关键细节一定要过滤掉用户已经学过的课程。很多新手实现时会忽略这一步导致推荐列表里出现用户早就学完的课演示效果直接翻车。过滤逻辑很简单查询用户已学课程ID集合生成推荐后做一次差集即可。还要注意如果候选课程的推荐分都为0说明用户历史行为太少这时候就要走冷启动方案这个话题后面单独讲。3. 基于SpringBoot的系统架构与核心代码实操3.1 工程结构设计与Maven依赖配置拿到了别人的源码第一件事就是理清工程结构。一个规范的SpringBoot推荐系统项目包结构通常是这样com.safety.edu ├── controller # 控制层接收前端请求 ├── service # 业务层核心业务逻辑 │ └── recommend # 推荐算法模块单独放一个子包 ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库实体类 ├── config # 配置类跨域、拦截器、Redis等 ├── common # 通用工具类、统一返回结果封装 └── utils # 工具方法余弦相似度计算等把推荐算法单独放到recommend子包里是个好习惯这样代码结构一眼就能看出重点论文里画系统架构图时也更容易表达。Maven依赖配置是项目能跑起来的前提最核心的pom.xml依赖如下dependencies !-- SpringBoot Web 依赖 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus 数据库操作 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency !-- MySQL 驱动 -- dependency groupIdcom.mysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- Lombok 简化实体类代码 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies这里要注意SpringBoot版本和JDK版本的匹配问题。现在网上很多源码用的是SpringBoot 2.x版本对应JDK8如果你本地装的是JDK17直接用2.x的老版本可能会报错。所以拿到源码后第一件事就是看pom.xml里的spring-boot-starter-parent版本号再看本机java -version。如果版本对不上要么把SpringBoot升级到3.x但3.x要求JDK17MyBatis-Plus也要用适配版本要么给电脑装一个JDK8并切换默认版本。毕设建议直接统一到“JDK8 SpringBoot 2.7.x”这是最稳的组合网上资料最多踩坑成本最低。3.2 数据库表设计评分表怎么设计直接决定推荐效果数据库设计是推荐能否落地的地基。安全的做法是至少设计这几张表用户表、角色表、课程分类表、课程表、用户学习记录表或评分表、考试表、成绩表。用户学习记录表是整个推荐系统的数据核心。我见过很多同学把学习记录字段设计成“学没学完”一个布尔值这其实是不太好用的。更好的设计是记录用户-课程-评分这个三元关系。这里给出一个实用的评分表DDLCREATE TABLE course_rating ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, course_id bigint(20) NOT NULL COMMENT 课程ID, rating tinyint(4) DEFAULT NULL COMMENT 用户评分1-5, study_duration int(11) DEFAULT 0 COMMENT 学习时长秒, is_finished tinyint(1) DEFAULT 0 COMMENT 是否完成学习, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_course (user_id, course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户课程评分表;注意几个细节。uk_user_course唯一索引一定要加防止同一用户对同一课程产生多条评分记录影响后续相似度计算时的数据一致性。rating字段可以为空因为不是所有课程学完都必须评分但study_duration和is_finished一定要有它们是生成“隐式评分”的备用数据源。比如某个用户看完了一门课但没有打分我们可以用is_finished1代表一个4分的基础评分这样数据覆盖率更高推荐结果也不会因为评分数据太少而显得单薄。课程表和用户表的设计相对常规但要注意课程表至少要有分类ID、标题、封面图、难度等级、学习人数这些字段。其中“学习人数”可以在展示层做一个热门课程排序作为推荐模块的补充冷启动阶段很管用。3.3 课程推荐的核心Service代码实现推荐算法在代码里落地最核心的就是这个Service方法。这里我给出一个简化的ItemCF推荐实现完整逻辑如下Service public class RecommendServiceImpl implements RecommendService { Autowired private CourseRatingMapper courseRatingMapper; Autowired private CourseMapper courseMapper; Override public ListCourseVO recommendCourses(Long userId, int topN) { // 1. 查询所有用户的评分记录 ListCourseRating allRatings courseRatingMapper.selectList(null); // 2. 构建用户-课程评分Map: userId - (courseId - rating) MapLong, MapLong, Double userItemMap new HashMap(); for (CourseRating rating : allRatings) { userItemMap.computeIfAbsent(rating.getUserId(), k - new HashMap()) .put(rating.getCourseId(), rating.getRating().doubleValue()); } // 3. 获取当前用户已评分的课程 MapLong, Double currentUserRatings userItemMap.getOrDefault(userId, new HashMap()); // 4. 计算所有课程与用户学过课程的相似度评分 // 简化处理直接用当前用户评分过课程遍历其他课程做推荐打分 MapLong, Double candidateScoreMap new HashMap(); ListCourse allCourses courseMapper.selectList(null); for (Course course : allCourses) { // 跳过用户已经学过的课程 if (currentUserRatings.containsKey(course.getId())) { continue; } double score 0.0; for (Map.EntryLong, Double rated : currentUserRatings.entrySet()) { double sim calcCourseSimilarity(rated.getKey(), course.getId(), userItemMap); score sim * rated.getValue(); } candidateScoreMap.put(course.getId(), score); } // 5. 排序取TopN return candidateScoreMap.entrySet().stream() .sorted(Map.Entry.Long, DoublecomparingByValue().reversed()) .limit(topN) .map(entry - courseMapper.selectById(entry.getKey())) .map(CourseVO::fromEntity) .collect(Collectors.toList()); } /** * 计算两门课程之间的余弦相似度 */ private double calcCourseSimilarity(Long courseId1, Long courseId2, MapLong, MapLong, Double userItemMap) { // 构建课程1、课程2的用户评分向量 MapLong, Double vector1 new HashMap(); MapLong, Double vector2 new HashMap(); for (Map.EntryLong, MapLong, Double entry : userItemMap.entrySet()) { Long uid entry.getKey(); MapLong, Double ratings entry.getValue(); if (ratings.containsKey(courseId1)) { vector1.put(uid, ratings.get(courseId1)); } if (ratings.containsKey(courseId2)) { vector2.put(uid, ratings.get(courseId2)); } } // 使用上一节的工具类计算余弦相似度 return CosineSimilarity.cosineSimilarity(vector1, vector2); } }这段代码放在毕设项目里跑通演示是没问题的。但我要提醒一句这种写法是“教学版”不是“生产版”因为每次请求都要全表扫描并实时计算相似度数据量一旦上去性能就崩。毕设里课程几百门、用户几十个完全够用。如果你想在论文里体现性能优化思想可以加一个“相似度矩阵定时计算”的说明每天凌晨用定时任务把课程相似度算好存Redis或数据库表在线推荐时只查缓存、不实时计算。有这一笔论文的“系统优化”章节就有东西写了。3.4 前后端接口设计与演示效果可视化后端接口的设计要方便前端调用也方便演示时讲清楚业务流程。推荐模块的核心接口最少要有三个用户登录后获取首页推荐列表GET /api/recommend/home返回推荐课程列表。 获取某个课程的相似课程GET /api/recommend/similar/{courseId}用于课程详情页“猜你喜欢”模块。 给课程评分POST /api/course/rate参数是userId、courseId、rating保存评分数据为后续推荐提供数据基础。接口统一返回数据格式建议用Result对象封装包括code、message、data三个字段。前端Vue页面调用起来统一、规范论文里也可以截图展示这个统一响应结构。演示效果要“可视化”得好有一个很讨巧的技巧造一批看起来合理的数据。比如手动构造两个“相似用户”一个用户学了“交通安全”“事故应急处理”另一个用户学了“交通安全”“事故应急处理”“消防逃生”。“驾驶安全”这门课跟“事故应急处理”相似度高系统就会给第一个用户推荐“消防逃生”。演示时你先登录第一个用户首页推荐列表能稳定出现“消防逃生”再切换登录第二个用户推荐列表会变得不完全相同。就这样一个简单的对比就能直观说明“推荐系统不是所有人都推一样的课程”这比你在答辩时说十句“算法有效”都有冲击力。4. 部署交付与毕设答辩避坑指南4.1 三条经典错误SpringBoot版本、数据库编码、端口占用整个项目最劝退的就是部署阶段。我遇到过并且身边同学也反复踩的坑基本集中在三个地方。第一个坑是SpringBoot版本和JDK版本不匹配运行时报java.lang.UnsupportedClassVersionError或者Maven编译时报错。解决的方法是先确认源码用的是哪个版本。打开pom.xml看spring-boot-starter-parent里的版本号2.x对应JDK83.x对应JDK17。如果本地版本对不上就去Oracle官网或国内镜像下载对应JDK然后在IDEA里Project Structure设置Project SDK和Modules的Language Level两边保持一致。第二个坑是数据库连接失败。新手最容易遇到的就是MySQL 8.x跟老版本驱动的兼容问题。如果你用的是MySQL 8.xapplication.yml里的数据库URL要加serverTimezoneAsia/Shanghai驱动要写com.mysql.cj.jdbc.Driver不然会报时区错误和驱动类找不到。另外如果你从别人那儿拷来项目数据库用户名密码大概率不是你的记得改成你自己的。第三个坑是端口被占用。SpringBoot默认8080端口如果本机已经跑了一个Tomcat或其他服务启动时会报Port 8080 was already in use。解决方案很简单改application.yml里的server.port或者关掉占用进程。Windows下用netstat -ano | findstr 8080查到占用进程的PID再taskkill /PID 进程号 /F即可。每次我在给同学排查部署问题的时候都会强调不要在答辩前一晚才开始部署。至少提前三天把项目从零到跑通完整走一遍并录好演示视频。现场演示大概率会出幺蛾子有视频兜底能救你一命。4.2 演示视频录制与项目交付物检查清单这类毕设项目的标配交付物是完整源码、论文LW、部署说明、演示视频。很多同学拿到这些材料后不做检查就以为自己稳了这是一个特别大的误区。拿到源码后的第一件事不要运行先打开项目结构看是否完整。检查点有这几个是否有src目录SQL初始化脚本在不在db或sql目录下是否有README.md或部署说明.docx里面的数据库版本、JDK版本说明是否清晰是否有application.yml配置文件数据库连接信息是否写死演示视频是否从头到尾完整包含登录、课程浏览、推荐展示、评分、管理端操作等环节。演示视频的录制有讲究。不要一上来就咔咔点页面要按流程走先演示管理员登录创建用户、添加课程再切换学员账号浏览课程、学习、评分然后回到首页展示推荐结果的变化。整个过程要慢一点尤其推荐模块要有明显的“换了一个人推荐就变了”之感。录完视频后自己看一遍注意是否有隐私信息泄露比如数据库密码明文暴露在页面URL上、是否出现白屏或报错弹窗这些瑕疵在答辩现场会被老师敏锐地捕捉到。4.3 答辩时如何讲推荐算法的新颖性与合理性答辩是很多技术型毕设的真正考验。老师大概率会问三个方向的问题一是算法原理二是为什么这么选三是系统改进空间。算法原理的问题最好准备。你把协同过滤的流程用三句话讲清楚输入是用户历史行为核心是相似度计算输出是Top-N推荐。老师如果追问相似度怎么算的你就把余弦相似度的公式写出来解释分子是点积、分母是模长乘积。再追问冷启动怎么办回答策略是新用户没有行为数据时采用基于热门课程、基于课程分类属性的推荐兜底等用户产生足够行为后再切换为协同过滤。这个回答一出来老师就知道你对业务场景有完整的思考。为什么选协同过滤而不是深度学习这个问题很多同学会慌。其实答案非常朴素毕设场景下数据量小协同过滤实现简单、效果可解释性强、不需要GPU且课程推荐属于典型的有行为数据可用的场景。反面来说深度学习需要大量数据和计算资源在毕设这种规模的数据下性价比极低。你还可以补一句“如果后续扩展到真实生产环境、数据量达到百万级可以引入矩阵分解或图神经网络做进一步优化。”这句话是高阶加分项但前提是你真能接住追问所以不要乱说。4.4 推荐效果不好怎么办冷启动、数据稀疏与算法选型修正很多同学第一次跑通项目后会发现推荐结果看起来“不准”或者“没有明显变化”。这通常不是你代码写错了而是数据问题。我建议在初期导入数据时就按照“造数据”的思路来设计而不是随便导几百条一模一样的记录。具体操作准备20个测试用户、30门课程每门课被5-8个用户评分每个用户评了8-12门课评分值集中在3-5分之间。这样构造出来的评分矩阵虽然不是特别稠密但足以让相似度计算产生有效差异。如果所有用户都只学了同一门课那任何推荐算法都白搭因为它拿不到区分度。还有一点容易被忽略推荐结果的展示要有“推荐理由”。比如返回推荐列表时附带相似课程名称“因为您学习了《建筑施工安全基础》所以推荐《高处作业安全规范》”。这种解释性推荐在答辩时特别加分它证明了你是真正理解了算法逻辑而不是简单调了一个接口。实现上也不复杂在推荐打分的时候同时记住“贡献分最大的已学课程ID”返回结果时把对应课程名称一并带上就行。4.5 后续扩展方向从毕设到真实项目的进阶思考到这里整个项目的主线已经走通了。最后聊聊做完这个项目后如果想继续往深走可以往哪些方向拓展。第一把推荐算法从离线计算升级为实时计算。现在大部分毕设项目都是用了就现算、结果缓存住。升级方案是引入消息队列和流式计算用户每次点击、评分、学习行为都发送到一个消息队列由消费端异步更新“用户-课程”交互矩阵再周期性地更新相似度矩阵和外排序后的推荐结果。第二增加多路推荐融合。除了协同过滤再加入基于内容课程的分类、标签、关键词的推荐、热门榜、新课程榜、同类用户的学习路径推荐。多路召回、加权融合最终排序再用业务规则或简单的排序模型调优。这在真实推荐系统里是标配思路你只要在论文里写出这个框架内容深度直接甩开同组同学一个档次。第三引入评估机制。推荐系统上线后好不好不能靠感觉。可以加入离线评估指标准确率Precision、召回率Recall、覆盖率Coverage、平均绝对误差MAE。毕设里你只需要设计一个评估模块把测试集评分隐藏掉一部分用预测值跟真实值对比算一下MAE或RMSE就能在论文里给出量化结果。这是很多优秀毕设的论文亮点之一但实现成本不高值得投入时间。我在实际给学弟学妹们看这套项目的时候发现大多数人的问题根本不是代码写不出来而是不会“讲”。你只要把算法原理吃透、把数据流梳理清楚、把三个常见部署坑背下来这个项目从交付到答辩都不会有大问题。最后再分享一个小技巧不管是录演示视频还是现场答辩第一件事永远是展示推荐算法模块别一上来就展示登录注册。把最亮眼的放最前面老师对整场答辩的印象分立刻就不一样了。