简介：一套基于推荐算法的在线课程推荐系统完整源代码，面向Java Spring Boot方向的毕业设计或课程设计，覆盖管理员与用户两类角色的全流程业务，可解决教育场景下课程个性化推荐的实际需求。压缩包共收录617个文件，大小34.53MB，包含Java后端源码、Vue前端页面、SQL数据库脚本、XML/YAML配置文件、说明文档及演示视频等常见开发资源，并配有目录结构梳理，便于按模块查阅。目前已有42人浏览学习，适合需要快速搭建同类型项目或深入理解前后端联调思路的开发者。系统功能覆盖用户管理、课程信息管理、课程评价、学习进度、我的发布/收藏、互动交流与意见反馈等模块，同时提供数据库设计文档与部署文档，便于理解表结构与规划项目目录，能够作为课程设计或毕业设计的完整样例。

1. 推荐算法在课程系统里落地：瓶颈不在算法代码

拿到「基于推荐算法的在线课程推荐系统设计与实现源代码（完整前后端+mysql+说明文档+LW）」这类交付物，多数人第一反应是去看协同过滤那些高深代码。实际在课程场景里，效果翻车十有八九不在算法，而在数据怎么喂：评分表有没有唯一索引、种子数据稀疏到什么程度、相似度矩阵是启动时加载还是每次请求重算。

这类系统典型需求很固定：注册登录、课程浏览评分、首页推荐位，后台一张行为表驱动推荐。这篇按「算法选型→表结构→接口联调→避坑→效果验证」走一遍，适合做课程设计、毕设，或正给学习平台加推荐位的开发者。新手能跟着把链路搭通，熟手可以直接对齐边界和参数。

2. 推荐算法选型：为什么课程场景默认走 ItemCF

课程推荐和电商推荐有个明显差异：课程更新慢，一门课可能放一两年还在被推荐；而用户对课程的兴趣相对稳定，很少出现今天喜欢后端、明天转向完全无关领域的情况。所以协同过滤两大流派里，ItemCF（基于物品的协同过滤）在这类系统里是默认选择，核心逻辑一句话：找出「喜欢课程 A 的人还喜欢课程 B」，然后用用户历史喜欢的课程去匹配相似课程。

这套逻辑看起来简单，落地时牵涉三个决策点：两道流派怎么选、相似度公式怎么写、TopN 怎么截断。下面逐个说。

2.1 先用场景筛掉一半：UserCF 在课程系统里的三个问题

UserCF 是「找和你相似的人，推荐他们喜欢的课」。听起来个性化更强，但放到课程系统里有三个实际问题。

第一，用户数通常远大于课程数。学习平台动辄上千注册用户，课程可能只有一两百门。UserCF 要算用户与用户之间的相似度，矩阵规模是用户数的平方，比课程间的矩阵大一个量级，内存和计算时间都更紧张。

第二，新用户没有行为时，UserCF 完全无法计算「他和谁相似」，推荐直接落空。ItemCF 至少还能用课程热度、课程分类做兜底。

第三，用户兴趣随时间漂移。这个月学前端、下个月学数据分析，如果按历史行为找相似用户，推出来的东西会有明显滞后。课程之间的相似关系反而稳定得多，「学完 Java 基础的人继续学 Spring Boot」这条规律半年内基本不会变。

所以我在此类系统里一律先实现 ItemCF，矩阵小、代码少、上线后好排查。UserCF 等有足够用户行为数据、且想做「同学都在学」这种社交化推荐时再叠加，而不是一开始就两头写。

2.2 ItemCF 核心公式与可直接改写的代码

ItemCF 的相似度一般用余弦相似度，公式是：

sim(i, j) = |U(i) ∩ U(j)| / ( sqrt(|U(i)|) × sqrt(|U(j)|) )

其中 U(i) 是给课程 i 打过分（或产生过有效行为）的用户集合。分子是同时接触过两门课的人数，分母是对两门课各自热度开根号，用来抵消「热门课和谁都相连」的问题。

下面这段 Python 是逻辑最清晰的可读版本，适合先在本地验证算法，再翻译成 Java 放进后端。

# behaviors: [(user_id, course_id, rating), ...]，rating >= 4 才认为真正喜欢 item_users = {} # course_id -> {user_id: rating} for uid, cid, rating in behaviors: if rating < 4: continue item_users.setdefault(cid, {})[uid] = rating # 构建课程相似度矩阵 sim_matrix = {} for cid_i, users_i in item_users.items(): for cid_j, users_j in item_users.items(): if cid_i == cid_j: continue common = len(set(users_i.keys()) & set(users_j.keys())) if common < 2: # 共同评分人数太少，视为噪声 continue sim = common / (len(users_i) ** 0.5 * len(users_j) ** 0.5) sim_matrix.setdefault(cid_i, {})[cid_j] = sim sim_matrix.setdefault(cid_j, {})[cid_i] = sim

这里有个关键过滤条件：common < 2 直接跳过。只有一个人同时看过两门课，很可能只是偶然，不构成相似证据。示例里 rating >= 4 是为了把「真正喜欢」和「随便点开」分开。

如果发现热门课严重淹没推荐，可以在相似度上加惩罚因子：把 sim 再乘以 1 / log(1 + len(users_i))。这样用户量大的课程虽然交集多，但会被对数项压回来。这个因子在数据量小的时候效果不明显，等种子数据到几百条以上再调。

2.3 三个必须先定好的参数：topN、共同用户数、行为阈值

这三个参数里，minCommon 是首先要调的。种子数据少、评分稀疏时，把它从 2 降到 1，矩阵立刻从「全空」变成「有边」，演示效果马上出来；但真实环境别用 1，否则两个课程只要被同一个人碰过就会连上一条边。topN 建议先用 15，等评测时再根据结果收缩或放宽。

行为阈值反而容易忽略。如果 rating 表里 1~5 分都有，直接把全量传入算法，低分课程也会参与相似度计算，最后推荐一堆用户其实不喜欢的课。我习惯只让 4 分和 5 分参与相似度矩阵构建，3 分及以下当作「看过但不感兴趣」不进入计算。

3. MySQL 表结构与种子数据：喂给推荐算法的口粮在这

算法代码只是消费数据的计算单元，rating 表怎么建，直接决定后面的推荐代码是几十行还是几百行。标题里写着「mysql」，说明整条链路都依赖这一张行为表，这里是整个系统最不能省事的部分。

3.1 user、course、rating 三张表：建表 SQL 与索引设计

课程推荐系统最少需要三张表：用户表、课程表、评分行为表。实际项目会在用户表加上角色，课程表加上分类和难度字段，评分表预留来源字段，这样后面调算法和做冷启动都有操作空间。

CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(100) NOT NULL, `role` tinyint NOT NULL DEFAULT 0 COMMENT '0-学员 1-管理员', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `course` ( `id` int NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL, `category` varchar(50) DEFAULT '' COMMENT '分类，用于冷启动兜底', `difficulty` tinyint DEFAULT 0 COMMENT '难度 1-3', `cover_url` varchar(255) DEFAULT '', `is_active` tinyint DEFAULT 1 COMMENT '0-下架 1-上架', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category` (`category`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `rating` ( `id` int NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL, `course_id` int NOT NULL, `rating` tinyint DEFAULT 0 COMMENT '显式评分 1-5，隐式行为记为 4', `learn_time` int DEFAULT 0 COMMENT '累计学习秒数', `source` tinyint DEFAULT 1 COMMENT '1-显式评分 2-学习行为', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_course` (`user_id`, `course_id`), KEY `idx_user` (`user_id`), KEY `idx_course` (`course_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

rating 表最核心的设计是uk_user_course唯一索引。同一个用户对同一门课只保留一条行为记录，后续无论前端提交多少次评分，都用INSERT ... ON DUPLICATE KEY UPDATE去更新而不是新增行，从根上杜绝重复数据污染相似度。

索引方面，推荐算法高频查询恰好是两类：按 user 取历史评分、按 course 取评过分的用户列表。所以 idx_user 和 idx_course 必须建，否则数据量到几千条后接口明显变慢。course 表的 idx_category 不是给推荐算法用的，是给冷启动兜底查「推荐同类课程」用的。

3.2 种子数据怎么造：30 个用户 300 条评分也能出效果

最常见的失败方式是把评分数据做成全表随机，每个用户对每门课都有评分。这样的数据表面丰富，算出来的相似度全被热门课把持，演示时完全说不清推荐逻辑。

我的做法是给课程分簇，让用户只在自己感兴趣的簇里产生评分，簇之间留一点重叠：

import random # 课程按内容分成三个簇，模拟真实兴趣 groups = { 'A': [1, 2, 3, 4, 5], 'B': [6, 7, 8, 9, 10], 'C': [11, 12, 13, 14, 15], } # 30 个用户，每个用户喜欢两个簇 for uid in range(1, 31): pref_groups = random.sample(list(groups), 2) for g in pref_groups: for cid in groups[g]: if random.random() < 0.6: # 簇内 60% 概率评分 rating = random.randint(3, 5) # 执行 INSERT INTO rating(user_id, course_id, rating) VALUES(...) # 实际接入时用批量 execute 插入，避免逐条 commit

注意评分取值只在 3~5 之间，不出现 1 和 2。因为 1~2 分的行为对 ItemCF 来说属于「不感兴趣」，但种子数据里低分课同样会被算进矩阵，最终拖低推荐结果。等系统上线收到真实低分评价后，再按 2.2 里的 rating >= 4 过滤逻辑处理。

30 个用户、15 门课、300~400 条评分足以让 ItemCF 演示出「不同用户看到不同推荐」的效果。数据再少，矩阵基本是空的。

3.3 说明文档与 LW 的对应：E-R 图和算法章节别和代码脱节

标题里「说明文档+LW」是交付物的一部分，很多人代码写完了回头补文档，结果表字段和文档里 E-R 图对不上。答辩或验收时被问「为什么实体关系图和代码不一致」，会比算法问倒更尴尬。

文档结构按五步写就够：评分归一化、构造共同用户集合、计算课程相似度、取 TopN 相似课程、加权求和得推荐列表。这一套文字描述和上面 Python 代码的逻辑一一对应，评审看不出破绽。截图位置也提前留好三处：冷启动兜底效果、个性化推荐列表、相似度详情页。

另外提醒一句：如果后面在 rating 表加了 source 字段或改了索引，文档里的表结构说明要同步更新。这类细节最容易被挑刺。

4. 前后端与接口联调：把推荐列表变成页面上的课程卡片

算法单独跑通不算系统。要让推荐真正出现在网页上，需要把相似度矩阵接到后端接口，再把接口数据渲染到前端推荐位。这里后端以常见的 Java 技术栈为例，前端用 Vue 说明，其他语言原理一致。

4.1 后端推荐接口：从相似度矩阵到 TopN 的调用链

推荐接口设计成 GET 请求，路径带用户 ID，返回课程列表。推荐结果允许小时级延迟，不需要实时计算。

@RestController @RequestMapping("/api/recommend") public class RecommendController { @GetMapping("/{userId}") public Result recommend(@PathVariable Integer userId, @RequestParam(defaultValue = "10") Integer size) { List<CourseVO> courses = recommendService.recommend(userId, size); return Result.ok(courses); } }

Service 里的推荐逻辑是整条链路的重点：

public List<CourseVO> recommend(Integer userId, int size) { // 1. 找到用户真正喜欢的课程 List<Integer> liked = ratingMapper.findLikedCourseIds(userId); if (liked.isEmpty()) { // 冷启动兜底：返回热门课程，不让页面空着 return courseMapper.findHotCourses(size); } // 2. 遍历喜欢课程，用相似度矩阵加权累加候选课程得分 Map<Integer, Double> scoreMap = new HashMap<>(); for (Integer cid : liked) { Map<Integer, Double> simCourses = simService.similarItems(cid); for (Map.Entry<Integer, Double> entry : simCourses.entrySet()) { Integer itemId = entry.getKey(); if (liked.contains(itemId)) { continue; // 已学过的课不再推荐 } // 累加相似度作为得分 scoreMap.merge(itemId, entry.getValue(), Double::sum); } } // 3. 按得分降序取前 size 门课 return scoreMap.entrySet().stream() .sorted(Map.Entry.<Integer, Double>comparingByValue().reversed()) .limit(size) .map(e -> courseMapper.findById(e.getKey())) .collect(Collectors.toList()); }

两处需要解释。第一，scoreMap 的 merge 方法是累加逻辑：同一门候选课如果和用户看过的好几门课都相似，得分会叠加，这是 ItemCF 加权投票的朴素实现。第二，冷启动兜底分支至关重要：新用户没有行为时返回热门课程，而不是返回空数组，前端页面至少是有内容的。

4.2 相似度矩阵装载与失效时间：定时重建还是启动时加载

课程数据变化慢，相似度矩阵最优做法是启动时加载到内存，然后按固定周期重建，而不是每次请求都现算。现算会让接口延迟从毫秒级变成秒级。

recommend: rebuild-cron: "0 0 3 * * ?" # 生产环境每天凌晨重建一次

开发阶段把 cron 临时调成每 10 分钟一次，方便验证数据修改后矩阵会跟着变。更省事的做法是额外提供一个管理端接口POST /api/recommend/rebuild，手动触发矩阵重建，省去反复重启服务的时间。生产环境用定时任务即可，这个手动接口不要对外开放。

4.3 前端推荐位渲染：Vue 示例与三个展示位置

前端推荐位最常见的实现是登录后首页加载一段课程卡片列表：

<template> <div class="recommend-section"> <h3>{{ title }}</h3> <CourseCard v-for="course in courses" :key="course.id" :course="course" /> </div> </template> <script setup> import { ref, onMounted } from 'vue' import CourseCard from '@/components/CourseCard.vue' import { getRecommend } from '@/api/course' const courses = ref([]) const title = ref('为你推荐') onMounted(async () => { // currentUser 由登录状态统一注入 const res = await getRecommend(currentUser.id, 10) courses.value = res.data }) </script>

getRecommend 内部就是 axios 封装，指向 4.1 的接口。这里有个细节：冷启动时后端返回的是热门课程，前端可以根据接口返回的特殊标记把标题从「为你推荐」换成「大家都在学」，体验上完全说得通。

推荐位的三个放置位置，我见过的最佳实践：首页顶部一个横排推荐区、课程详情页底部一个相似课程区、学习完成页一个「接下来学什么」区。三个入口共用同一套推荐接口，只是传参和展示数量不同，工作量很小。

5. 推荐系统调试避坑：现象、原因、解决三件套

整套链路搭起来之后，第一版效果通常很惨。以下五条按我见过的出现频率排序，每一条都是实际调试中真实踩过的类型。

5.1 新用户冷启动：推荐列表空转

现象：刚注册的用户打开首页，推荐位显示空白，浏览器请求返回 200 但 data 是空数组。

原因：评分表里找不到该用户任何行为，scoreMap 计算出来是空的；后端没有写冷启动兜底逻辑，直接返回了空列表。

解决：在 recommend 方法入口判断喜欢课程列表是否为空，为空时直接走热度查询，按评分人数排序返回前 N 门课。这是最廉价的冷启动方案，不需要任何标签体系。关键词是「宁可推荐热门，也不要让页面空着」。

5.2 数据稀疏：相似度矩阵全零

现象：固定用一个老用户测试，日志里查询相似度矩阵的结果全是空，推荐永远走兜底分支。

原因：种子数据只有几十条评分记录，minCommon 设为 2 之后，几乎所有课程对都被过滤掉了。

解决：开发期把 minCommon 临时调到 1，矩阵立刻有边可算；同时把课程分簇造数据的脚本跑一遍，让评分记录数到 300 条以上。这里有个取舍：minCommon=1 在演示环境可以接受，生产环境绝对不能长期用，否则偶然一次共同行为就会产生错误关联。

5.3 改完 MySQL 数据推荐结果不变

现象：后台把某门课的评分批量改掉，前端刷新五分多钟，推荐列表完全没变化。

原因：相似度矩阵在服务启动时一次性加载进了内存，改数据库不会自动触发矩阵重算。这是 4.2 留下的坑，很多人忘了配套重建机制。

解决：先确认接口返回时间戳，排除浏览器缓存；再看矩阵最后重建时间，确认是否当天凌晨定时任务之外没有手动触发过。开发期最省事的是调用 rebuild 接口，或者把定时任务临时改成每 5 分钟一次，确认逻辑正确后再改回生产 cron。

5.4 热门课程淹没整个推荐列表

现象：推荐结果前 10 门里有 8 门是同一分类的热门课，看起来像「排行榜」而不是「个性化推荐」。

原因：热门课评分的用户基数大，和任何课程的交集人数都多，余弦相似度天然偏高。加上新用户冷启动走热度查询，会让热门课的位置更明显。

解决：在相似度公式里加惩罚项，把 sim 乘以 1 / log(1 + 用户数)，压住热门课的虚高关联。同时推荐结果出来后，过滤掉全局评分人数前 N 的热门课，只把它们放到候选集里参与投票，不直接作为推荐结果输出。

5.5 显式评分与隐式学习记录混用造成伪相似

现象：某门课 5 星高分但几乎没有学习时长，另一门课很多人学完但评分不高，算法却把这两门课判定为高度相似。

原因：rating 表里显式评分和自动记录的学习行为没有区分来源。用户点开视频挂了 10 分钟也算一条行为，和认真打 5 分混在一起算相似度，数据噪声非常大。

解决：用建表时预留的 source 字段区分来源，1 是显式评分，2 是学习行为。计算向量时给 source=2 的记录加权重系数，比如 0.6；或者更严格一点，学习时长要达到视频总时长的 60% 以上才允许写入隐式评分记录。否则学习行为会变成纯粹的噪声来源。

6. 从跑通到可用：推荐效果评估与「因为你看过」的推荐理由

跑通只是第一步，验收时评审更关心两个问题：推荐到底准不准、为什么推荐这门课。第二个问题尤其容易被忽视，但恰恰是最容易出彩的点。

评估推荐效果，不需要引入复杂的离线评测框架。按用户把评分表拆成 80% 训练集、20% 测试集，用训练集生成推荐，再检查推荐结果覆盖测试集的比例：

def evaluate(rec_items, test_items): hit = len(set(rec_items) & set(test_items)) precision = hit / max(len(rec_items), 1) recall = hit / max(len(test_items), 1) return precision, recall

注意过滤掉测试集中没有行为记录的新用户，否则冷启动用户会拉低整体指标。覆盖率则需要统计推荐列表里有去重后多少门不同课程出现，连续多次评测覆盖率越来越低，说明推荐结果收敛到热门课了，需要回去调惩罚因子。

「因为你看过」这招性价比极高。后端在计算推荐得分时，额外记录对每门候选课得分贡献最大的历史课程 ID，接口返回时带上这个字段；前端展示文案为「因为你看过《Java 基础》，推荐你学《Spring Boot 入门》」。用户一眼看懂推荐逻辑，比任何炫酷算法描述都有效。

我平时养成的习惯是：先造一份可复现的分簇种子数据，再调 minCommon 和惩罚因子，最后才加推荐理由字段。顺序反了容易在调参时被数据噪声带偏。这整套链路真正跑顺，看推荐列表加推荐理由能自圆其说，才算把「基于推荐算法」从标题变成了真实可用的功能。希望帮到你。

本文还有配套的精品资源，点击获取