企业官网建设流程全解析

如果你此刻正盯着选题列表发愁，翻来覆去看到的都是“网上商城系统”“图书管理系统”这种做了无数遍的题目，那我建议你认真看看“基于Django+大数据的学习资源推送系统”这个方向。

这个题目的核心是：做一个能根据用户行为自动推荐课程视频和电子书的学习平台，后端用Django写业务逻辑和推荐接口，数据层用爬虫采集、日志埋点配合pandas做离线清洗，再用协同过滤或相似度计算把“用户”和“资源”之间的关联跑出来。放在毕设里，它既不缺业务功能、也有算法建模空间、还方便做可视化展示，是一眼就能看出工作量的那种题目。

我把开发这类系统从架构选型到推荐算法落地、再到答辩包装的所有关键点都整理在下面，拿去就能照着做。

1. 为什么这个选题值得做：从评审角度拆解价值

很多同学误以为“大数据毕设”就一定要上Hadoop、Spark、Flink这一套重型生态，先把自己吓退了。实际上本科毕设的评审关注点只有一个：你是否完整地解决了一个有实际意义的问题，并且理解和掌握了所用的技术。

1.1 学术价值与工程难度的平衡点

这个项目的巧妙之处就在“大数据”三个字用得很轻巧，但又不算骗人。你不需要真的跑分布式集群，只需要用一个单机可承载的数据处理流程来体现“数据量较大时如何做分析和推荐”的思路即可。

通常推荐的实现方式是：用requests写爬虫脚本抓取公开课程平台的数据（注意只抓公开接口和自己允许使用的数据），配合CSV或者JSON格式的结构化数据，存到MySQL中。离线部分用pandas做数据清洗、去重、标签提取，然后计算资源之间的相似度矩阵，把结果存入Redis或者数据库表中。在线部分用户访问时，Django直接读取预先算好的推荐结果，响应速度极快。

这个方案的好处是：不上Hadoop也能把“大数据处理流程”讲清楚，数据清洗、特征工程、相似度计算这些环节每一步都有产出，论文里有写头，答辩时有问有答。

还有一些同学会强行给系统接入Spark Streaming，结果集群根本跑不起来，或者用最简单的两个数据表硬撑着。我的经验是，本科毕设的深度不需要做到“生产级”，但必须做到“逻辑完整”。你哪怕用十行代码实现一个分词加TF-IDF特征提取，只要讲明白了每个参数为什么这样设置，就已经比很多把PDF翻译成中文再抄一遍的人强太多了。

1.2 谁适合选这个题目，开发周期怎么排

这个题目适合两类人：第一类是Python基础还凑合、但不擅长前端折腾的同学，因为Django自带Admin后台和模板渲染，你不需要学Vue也能做出一个完整可用的系统；第二类是已经会一些机器学习基础、想在毕设里加点算法含量的同学，推荐模块可以放开手脚做得深入一些。

更现实的问题是时间分配。按照我的经验，单人开发这个系统，完整做完并写好论文的时间节点大概是：

总体控制在8周以内是没问题的。其中最容易延期的是推荐模块，后面我会专门讲这里有哪些坑。

2. 系统架构与技术选型：Django和大数据的正确结合方式

很多人在写项目描述时喜欢堆名词，什么“基于Django+Vue+Spark+协同过滤的学习资源推荐系统”，但实际代码里连协同过滤的影子都找不到。我不建议这么玩，与其堆砌名词，不如把一条链路做成闭环。

2.1 整体架构：从数据采集到推送的完整链路

我推荐的四层结构是这样的：

• 展示层：Django模板或者Django REST Framework提供接口，前端用Bootstrap或者原生HTML+JavaScript渲染页面。如果不想折腾前端打包工具，就用模板渲染加少量Ajax即可。
• 业务层：负责用户管理、资源管理、收藏、浏览记录、推荐结果查询等业务逻辑。这一层全部由Django的app模块组织。
• 数据层：MySQL存放用户、资源、行为三类核心数据，Redis可选，用于缓存热门资源和在线推荐结果。
• 数据处理层：独立于Web应用的Python脚本，负责定期从数据源拉取内容，数据清洗后落库，并离线计算资源间相似度矩阵和用户推荐候选集。

这里要特别强调：离线计算脚本和建议用“不占用Web服务进程”的方式运行。很多新手会直接把一个耗时的相似度计算写在Django的视图中，导致用户请求推荐页面要等几十秒甚至超时。正确做法是：写一个独立的脚本，比如recommend_builder.py，在本地跑完后把结果文件或数据库记录更新好，Web端只负责读。

2.2 环境与依赖版本建议

版本选得对，直接少走一半弯路。我比较推荐的组合：

• Python 3.8或3.10，不要用太新的版本，否则部分包没有预编译wheel，安装时容易出问题
• Django 4.2 LTS版本，文档丰富，坑少，网上能搜到的问题多
• MySQL 8.0以上，注意创建数据库时用utf8mb4字符集，否则存中文时可能出现乱码
• pandas和numpy用于数据清洗和相似度计算
• scikit-learn如果做TF-IDF特征或KMeans等算法可用，做余弦相似度也可以直接手写，不重

requirements.txt建议单独列一份，方便别人复现环境。写死版本号比写“django>=3.0”好得多，不然别人一装就是最新版，然后碰到各种兼容性问题。

2.3 数据库模型设计：三张核心表

先说一个我见过无数次的错误：只设计了用户表和资源表，用户点了什么、收藏了什么全部不记录，然后推荐模块完全是假的。这不行。

用户行为表（核心中的核心）

字段至少有：user_id、resource_id、behavior_type（浏览/收藏/下载/评分）、rating（如果是评分行为则记录1-5分）、create_time。每张表都给一个普通索引，按user_id和resource_id分别建联合索引也行，行为查询会快很多。

资源表

字段设计为：title、description、category（课程还是电子书）、subject（科目分类）、tags（多个标签用逗号分隔）、difficulty、cover_url、file_url、play_count、collect_count、publish_time。视频类资源建议存文件路径或者外部链接地址，不要把视频文件本身放进数据库。

用户特征表

这个表很多人会忽略，但对推荐效果提升非常明显。里面存用户偏好的标签集合、主要关注科目、平均学习时长等汇总特征。离线脚本会定期刷新这张表，在线推荐时直接读取，速度极快。

表之间用外键关联和用逻辑关联都有。我的个人习惯是：ORM里只定义普通IntegerField存关联ID，不用物理外键。原因是毕设后期导数据、删测试数据时物理外键非常碍事，而且你用Django的select_related也能拿到关联对象，性能差别不大。

3. 核心功能模块拆解：推荐功能到底怎么做

推荐功能是整个系统的灵魂。我见过的毕设代码里，有直接SELECT随机条数塞给用户的，有统计热门榜充当推荐的，这两种都太简陋，答辩时肯定被追问。至少要足够“推荐感”，有算法层面的解释空间。

3.1 用户行为数据采集：别小看这一步

推荐系统离不开行为数据，而行为数据怎么采集是有讲究的。

最基础的做法是：在Django视图函数里直接插入行为记录代码。比如用户点击“视频播放”按钮，对应的视图收到请求后，先创建一个Behavior对象，再执行播放逻辑。这个方式最简单，也完全够用。

我更推荐用中间件或装饰器来统一处理。比如写一个login_required装饰器包一层，在装饰器内部记录行为类型、页面、停留时间等，然后调用原视图函数。这样代码更规整，不会到处散落一堆Behavior.objects.create。

有一个容易被忽略的细节：不要把behavior_type用中文存。存一个英文code，比如view、collect、download、rating，展示的时候再映射中文。否则以后想扩展行为类型时，改数据库里的字符会非常难受。

3.2 混合推荐策略：规则+相似度+协同过滤

我建议做“三层混合推荐”，做到即使数据量不大也能出效果。

第一层，基于热度的兜底推荐。对全站资源按照播放量、收藏量、评分做一个加权分值排序，公式可以自己设计，比如：热点分 = 播放量×0.4 + 收藏量×0.3 + 评分×0.3。这个作为默认页推荐，保证新用户进来不会看到空页面。

第二层，基于内容的相似推荐。把每个资源的标题、描述、标签拼接成文本，用jieba分词，再用TF-IDF提取关键词向量，最后用余弦相似度计算资源之间的相似度。离线算好每个资源最像的Top10资源存表，用户在详情页就能看到“相关课程推荐”，这是最有真实感的一处功能亮点。

第三层，基于用户的协同过滤。如果用户行为数据超过几百条，就可以做UserCF：计算用户之间的相似度，找到最相似的用户，把他看过你还没看过的资源推荐给你。如果行为数据量很小，这一层跑出来效果会偏差，这时候可以把相似用户范围放宽，或者干脆降级到第二层。

3.3 推荐结果怎么“推送”给用户

推送这个词在毕设里没必要做成实时消息。我建议在首页、详情页和“我的推荐”页展示即可。

具体实现时，推荐结果生成后写进推荐结果表，字段包括：user_id、resource_id、reason_type（说明这条推荐是热度、相似还是协同过滤产生的）、score、create_time。前端显示时，在卡片上标注推荐原因，比如“因为你喜欢Python，所以推荐这份Django实战视频”。这种细节在答辩演示时很有冲击力，老师会觉得你真的在做推荐，而不只是开个接口。

4. 实操过程中的典型坑与排查实录

这个项目我在帮学生调试过程中遇到的坑，积累了不少，这里挑几个最典型、最容易让人崩溃的说一下，避免你再走一遍弯路。

4.1 推荐效果差：矩阵稀疏、数据造假和标签质量问题

很多同学跑了协同过滤之后发现推荐的资源驴唇不对马嘴，核心原因通常是数据太少。解决思路：

• 造数据的时候要有“同质化”。也就是说，让多个用户对某一类资源都有行为，比如十个用户都浏览过“Python入门”系列的视频，这样算法才有规律可挖掘。如果行为完全随机化，任何推荐算法都跑不出效果。
• 标签清洗很重要。你会发现爬下来的课程标签五花八门，什么“最新”“2023”这种词也混在标签里。跑TF-IDF之前，先把无意义词过滤掉，否则相似度计算会被噪声词带偏。
• 用规则修正兜底。协同过滤的结果一旦置信度不够（比如相似度低于0.2），就回退到热度推荐，不要硬推。

4.2 冷启动问题：新用户和新资源怎么办

新用户没有行为记录，协同过滤的候选集就是空的。这时候方案是：新用户注册后引导选择感兴趣的分类。在注册页做一个“勾选你感兴趣的科目”的步骤，前端把用户选择的标签写入特征表。后续推荐时，直接按标签匹配资源。

新资源同理，刚入库的课程没有播放和收藏数据，热度分是0。可以给“上架时间”加一个时间衰减因子，比如最近7天发布的资源初始热度分给一个基础值，避免新内容沉底。

4.3 视频播放兼容与文件路径问题

我把血泪教训说直白：视频文件一定要转成H.264编码的MP4格式，具体来说就是用ffmpeg命令逐个转换，不然在浏览器里用HTML5 video标签播放时会黑屏或有声音没画面。开发阶段用外部视频网站的引用链接也能跑通，但答辩现场一旦断网就露馅，最好准备本地资源副本。

另一个坑是跨平台文件路径。Windows开发时用反斜杠，服务器Linux环境认斜杠。建议所有文件路径都使用相对于项目根目录的路径，用os.path.join生成，不要硬编码。

4.4 Django查询性能：N+1问题太明显

列表页展示资源时，如果用Django ORM逐个取关联分类的名称，会导致每个资源都执行一次SQL查询。数据量小的时候没感觉，数据量超过几百条之后页面响应速度肉眼可见地变慢。

解决方式是在视图中加select_related。比如Resource.objects.select_related('category')，这样一次查询就把关联对象拿出来了。再配合分页，一页显示12个资源，响应时间基本在100毫秒以内。

5. 文档、答辩与演示：把活干得漂亮也要讲得漂亮

代码写完只是第一步，毕设要想拿高分，论文和演示同样占很大的权重。

5.1 论文结构怎么安排与图表怎么画

推荐使用经典“总分总”的五章结构：绪论、相关技术介绍、系统分析与设计、系统实现、测试与总结。

第三章里，给系统架构图、功能模块图、数据库ER图、推荐流程图各配一张。画图工具用draw.io就够，导出PDF放进Word里，不要截图低分辨率的图片。第四章里，每个核心功能至少配一张页面截图和一段核心代码截图，但代码截图不要截一长串，只截最关键的方法体，比如相似度计算的for循环部分。

论文中一定要有一个小节专门写“推荐算法的设计与改进”。哪怕你用的就是最基础的余弦相似度，也可以写：基础实现是什么、遇到了什么问题、我加了一个加权因子或降级策略、效果如何变化。这种“发现问题-解决问题”的叙事方式比罗列技术名词好太多。

5.2 答辩操作要点与高频提问

答辩时建议把系统演示顺序固定好：先展示注册和登录、再展示首页推荐列表、点开一个视频展示详情和相关推荐、然后进入个人中心展示浏览记录和个性化推荐、最后切到后台管理展示资源录入和用户管理。

演示过程中手不要抖，最稳的方式是提前在本地把服务启动好、数据库数据准备好，答辩现场不要现场重新跑数据清洗脚本。如果必须现场启动，也要把启动命令写成一行可复现的脚本，比如start.sh，而不是一步步敲命令。

准备高频问题答案：

• 为什么用Django不用SpringBoot：他适合快速开发、自带Admin后台省了重复劳动、和Python数据分析生态衔接好
• 推荐算法是怎么实现的：简单说清UserCF和ItemCF的区别，讲自己的用了哪些数据、算出的结果存在哪里
• 数据量如果很大怎么办：说实话，说明目前单机MySQL够用，后续可扩展换成Spark或连接ES

5.3 源码与文档的交付组织

拿到一份源码后，老师第一眼看的就是项目结构。README要写清楚环境要求、启动步骤、测试账号、目录结构。数据库脚本单独放sql目录，并且里面包含建库建表和测试数据，光有结构没有数据，别人跑起来是空的。

还有一点很加分：写一份简短的《操作手册》，用三页左右的篇幅说明正常使用流程。我见过很多同学把时间花在花里胡哨的PPT上，反面教材。老师真正想看到的是一份能跑通、看得懂的交付物。

写在最后的个人体会

我带过不少做毕设的学生，这个方向是我推荐次数最多的题目之一。它最省心的地方在于：即使你的推荐算法只有一个简易的相似度计算，也足够把整套系统的故事讲圆，而且从数据清洗到离线计算再到在线展示，每一步都有技术产出。

如果你自己做，我建议把精力重点放在推荐模块和环境部署上。前者决定上限，后者决定下限。很多小组死在前任代码跑不起来上，环境问题解决了，开发效率会翻倍。祝你能做出一份自己敢自信演示的毕设作品。