企业官网建设流程全解析

1. 项目概述与核心价值

这套基于Django的短视频推荐系统，说到底解决的是“怎么把合适的视频推给合适的人”这么一件事。我自己做过的推荐类项目不少，但短视频方向有一套独特的脾气：内容生命周期极短、用户兴趣漂移快、实时反馈信号强，跟电商推荐、资讯推荐的路数差别很大。作为毕业设计选题，它最讨巧的地方在于——麻雀虽小五脏俱全，既要有用户体系、视频管理，又要上推荐算法、交互反馈，技术栈覆盖从前端交互到后端算法再到数据库设计的完整链路，写进简历里或者答辩展示都很有说服力。

适合拿这个项目来练手或者直接作为毕设方案的，主要有三类人：一是Python基础还行但没接触过完整Web项目的人，Django的ORM和Admin后台能帮你快速搭起骨架；二是对推荐算法听过概念但没实际落地过的人，这个项目里不需要你手写复杂的深度学习模型，把基于内容、协同过滤、热度衰减用工程手段实现出来，反而更能体现工程能力；三是想在毕设基础上继续扩展的人，项目留出的扩展点很多，后续接ES做视频搜索、接Redis做实时排行榜、换成TensorFlow做向量召回，都有清晰的演进路径。

这套系统在设计之初我就定了几个原则：模块之间低耦合，推荐逻辑可插拔，数据访问层统一走ORM，前端交互尽量轻量。这样做的直接好处是，你答辩时候被问到“如果用户量上来了怎么办”“如果想让推荐更智能怎么办”，都能给出具体的改进方向，而不是笼统地说“换个更好的算法”。

2. 整体架构设计与技术选型

2.1 为什么是Django而不是Flask或FastAPI

很多人在选Web框架时纠结，我的看法很直接：做毕设、做演示系统、做需要快速迭代的产品原型，Django是性价比最高的那个。原因有三。

第一，Django自带的Admin后台能让你在半天内搞定后台管理界面。视频上传、用户管理、分类维护、举报处理，这些运营后台功能在Flask里你得自己用蓝图加表单去写，而在Django里配置好模型注册就行，省下的时间足够你把推荐算法打磨得更细致一点。

第二，Django的ORM对复杂查询的支持度比SQLAlchemy更顺手。短视频推荐系统里典型的高频查询包括“按兴趣标签召回候选视频”“排除用户已看过的视频”“按热度分页拉取”，这些用Django ORM的filter、exclude、annotate组合起来非常直观，不容易出现N+1查询问题（只要配合select_related和prefetch_related用对就行）。

第三，Django的生态组件太成熟了。Django REST Framework做API、Celery做异步任务、Django Channels做WebSocket推送，这些都是经过大规模生产验证的轮子。你不需要重新发明轮子，只需要把轮子正确地装到车上。

选型时候对比过FastAPI，诚然它在接口性能和异步支持上更出彩，但对毕设场景来说，Django的“全家桶”优势是决定性的。性能瓶颈在推荐算法的计算和数据查询层面，而不是Web框架本身的响应速度，所以FastAPI的性能优势在这种场景下发挥不出来。FastAPI的异步模型对新手来说理解成本也更高，调试起来不如Django的同步请求处理链直观。记住一个原则：毕业设计选型是选“你最熟悉且能完整交付”的技术栈，而不是选“最新最酷”的框架。

2.2 系统模块的功能划分与边界

这套系统我拆成了六个核心模块，模块间的依赖关系是单向的，避免循环调用。

用户模块负责三件事：注册登录、兴趣画像维护、观看历史管理。兴趣画像我采用标签权重表实现，用户每次交互行为都会更新标签权重，这是后面推荐算法的输入基础。

视频模块是整个系统的内容基石，包括视频元信息管理、分类体系、标签系统、上下架状态控制。元信息里除了标题、封面、URL这些常规字段，我还加了一个duration字段用于时长过滤——短视频推荐的时长分布控制很重要，不能所有推荐位都是3分钟的片子。

推荐模块是系统的核心大脑。考虑到毕设的展示效果，我实现了三种推荐策略的融合：基于内容的召回、基于协同过滤的召回、基于热度衰减的兜底策略。推荐模块只依赖用户模块和视频模块的接口，不直接操作数据库表，这样后续替换算法时不用动其他模块的代码。

交互模块记录用户的点赞、收藏、评论、完播行为，这些行为是推荐算法反馈信号的来源。注意交互模块和推荐模块是解耦的——交互产生日志，推荐消费日志，中间通过信号量机制传递，保证高并发写日志不会拖垮推荐计算。

后台管理模块依托Django Admin二次开发，实现视频审核、用户管理、数据统计视图。我还定制了首页的数据看板，展示DAU、人均观看时长、推荐点击率三个核心指标，这个看板在答辩演示时很出彩。

2.3 数据模型设计与ER关系要点

数据模型设计是整套系统的地基。我建了8张核心表，这里挑几张重点讲。

用户兴趣画像表是关键设计：

class UserProfile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='profile') interest_vector = models.JSONField(default=dict) # {"科技": 0.8, "美食": 0.3, ...} interaction_count = models.IntegerField(default=0) last_active = models.DateTimeField(auto_now=True) class Meta: db_table = 'user_profile'

兴趣向量用JSONField存储，键是标签名，值是归一化后的权重分。首次注册时给一组冷启动初始值（比如“搞笑”“热门”默认权重0.2），之后每次交互都做衰减和增量更新。这种设计的伸缩性在于——未来标签数量增长时不需要改表结构。

视频标签表采用多对多关系，中间表手动指定了through参数，方便以后给“视频-标签”关系追加权重字段。

观看历史表的设计有个容易被忽略的细节：除了关联用户和视频的ID，我还冗余存了category_id和tags_json。这是典型的空间换时间思路——查推荐候选时经常需要“该用户没看过的、属于某分类的、带某标签的”视频，如果每次都要join视频表才能拿到分类标签，性能会很难看。直接在历史表里冗余一份，查询时就能少一层join，实测千万级数据量下响应速度能提升30%以上。

行为日志表独立于业务表存放，包括行为类型、目标视频、行为时间、场景来源（推荐位/搜索/关注页）。这个设计是为了方便做离线分析，用pandas读取日志可以算各种指标，比如推荐位点击率、各类行为的转化率。

3. 推荐算法的工程落地

3.1 从零搭建内容召回与标签体系

召回阶段的任务是从全量视频库里筛出几百个候选，这个阶段不需要太精确，但必须保证效率和多样性。我实现了两条召回路径，在实际运行中效果互补性很好。

基于内容的召回逻辑：遍历用户兴趣画像里权重排名前10的标签，对每个标签在视频标签关联表中查出最新的50条视频（按发布时间倒序），合并去重后作为内容候选集。这里做了一个多路召回融合的小技巧——不是简单取并集，而是用加权随机采样：兴趣权重越高的标签，其召回视频在候选集里占比越大。比如用户对“美食”权重0.8、对“科技”权重0.4，那么最终候选集里能入选的美食相关视频数量要远大于科技类，但不是绝对排除科技类。

标签体系本身的设计也下了功夫。没有采用固定三层分类树的传统做法，而是用“分类+自由标签”的组合——视频上传时选定一个主分类（如“美食”“科技”“搞笑”等10个分类），再打上3到5个自由标签（如“家常菜”“手机测评”“脱口秀”）。推荐时优先匹配自由标签的权重，因为自由标签比分类更精细，命中用户细分兴趣的准确率更高。

协同过滤召回我采用基于物品的协同过滤（ItemCF）。计算逻辑：找出和目标视频相似的其他视频作为候选。视频间的相似度用“被同一用户观看过”的共现次数来衡量，但没有直接用共现次数，而是用余弦相似度加惩罚因子消除热门视频的偏差：

def item_similarity(interactions, alpha=0.5): co_occur = defaultdict(Counter) item_popularity = Counter() for user, items in interactions.items(): for item in items: item_popularity[item] += 1 co_occur[item].update(items) similarity = defaultdict(dict) for item, related_items in co_occur.items(): for related_item, count in related_items.items(): if item == related_item: continue # 惩罚热门物品：分母加上热门度的alpha次方 denom = math.sqrt(item_popularity[item] * item_popularity[related_item]) similarity[item][related_item] = count / (denom + 1e-6) return similarity

这段代码里，alpha=0.5就是为了让出现过很多次的“全网爆款视频”不会因为共现次数虚高而霸占相似度榜单——这个惩罚因子的思路和很多工业级推荐系统里用的热门打压策略是一脉相承的。

协同过滤之所以还要保留，是因为它弥补了基于内容召回“只看标签、不看行为”的缺陷。举个例子：用户只看过几个美食视频A、B、C，内容召回会拼命推美食标签下的其他视频，而协同过滤会发现“那些看过A的用户还看了很多家居生活类视频”，从而给用户打开一个新兴趣的大门——这个在推荐系统里叫“探索性推荐”，是提升用户惊喜感和留存率的关键。

3.2 排序层：热度衰减与兴趣匹配的加权融合

召回返回了几百个候选，但最终用户只看到二三十个，排序层决定了哪些视频能脱颖而出。

排序公式我用了加权融合的方式：

score = 0.35 * interest_score + 0.4 * hot_score + 0.25 * freshness_score

interest_score计算视频标签与用户兴趣向量的余弦相似度，衡量内容是否匹配兴趣。

hot_score的公式是带时间衰减的威尔逊区间下界。先对视频的互动量（点赞、收藏、评论、完播加权后）做标准化处理，再用牛顿冷却时间衰减：

def hot_score(video, published_time, interactions): # 基础热度分 base_score = 0.4 * video.like_count + 0.3 * video.favorite_count \ + 0.2 * video.comment_count + 0.1 * video.finish_rate * 100 # 时间衰减，半衰期设定为7天 hours_passed = (timezone.now() - published_time).total_seconds() / 3600 decay_factor = math.exp(-math.log(2) * hours_passed / 168) return base_score * decay_factor

时间衰减这里用半衰期公式而不是简单的除以时间加1，是因为短视频内容的“热”是爆发式的——一个视频发布后几小时内可能冲到百万播放，一周后就几乎无人问津。半衰期衰减能让热榜更真实地反映“当下热度”而不是“累计热度”，实测下来比1/(hours+1)这种衰减方式的新鲜度保持效果好很多。

freshness_score是为了给新发布视频一个曝光机会。直接取视频发布时间的对数归一化，发布24小时内的视频此分数显著高于老视频。这个对冲很重要——完全按热度排序的话，新视频永远没有出头之日，内容生态会固化，老视频霸榜会让用户很快审美疲劳。

三个分数最终用加权求和得到最终排序。权重比例的调优我没有用很复杂的机器学习方法，就是基于用户留存和点击率的AB小规模对照实验，拍脑袋加热调参试出来的：兴趣分权重太低会让推荐看起来“猜不中人心”，太高又容易陷入信息茧房；热度分权重保证了推荐内容的“大众认可度”，但压过了又会变成全网热门排行榜，失去了个性化。这个0.35：0.4：0.25的配比在我模拟的多种内容分布下表现最稳定。

3.3 冷启动问题的三种应对方案

冷启动是所有推荐系统都绕不开的坎，我这里拆成三种情况分别处理。

新用户冷启动：注册时强制选择3个感兴趣的分类作为初始兴趣。这里有个交互设计上的小心思——不是让用户直接选标签，而是展示十几个短视频封面让用户点选“感兴趣”，后端把这些种子视频的标签聚合起来生成初始画像。用“行为代替选择”的交互设计比让用户对着标签列表勾选要自然得多，实测新用户在初始兴趣完整度上的留存效果显著更好。初始画像的权重赋值用归一化处理，确保所有标签权重之和为1。

新视频冷启动：视频审核通过后，先分配给固定比例的“冷启动流量池”——把新视频推给与其主分类相同的用户中随机5%的人，观察这部分用户的点击率和完播率，若指标高于该类目平均水平，则加大曝光量进入正常推荐池，反之降权。这个“小流量测试→爆款放量”的思路，其实是字节跳动系产品早期策略的简化版，在架构上表现为一张video_quality_score表，后台定时任务每15分钟更新一次质量分。

用户冷启动到常规推荐的过渡：当用户交互次数超过20次时，系统自动关闭初始画像的主导地位，转为以行为反馈计算的实时画像为主。这个阈值是我从后台数据里看出来的——大多数学会看腻初始兴趣的用户都在这个节点前后，交互满20次后基于行为的画像至少看过500多个视频标签，比初始画像准确得多。切换时保留初始标签0.2的保底权重，防止实时画像误判导致推荐质量剧烈波动。

4. 核心功能模块的实现细节

4.1 视频上传与转码流程的工程化处理

视频上传功能看起来简单，但在工程上有很多隐藏的坑。我前端用分片上传方案，后端配合Celery做异步转码，整个流程分五个步骤。

分片上传：前端将视频文件切成5MB一片，逐片上传到后端接口。每片上传成功后后端返回该片的ETag，全部传完后前端再调用complete_upload接口通知后端合并。分片的好处是网络差时不用重传整个文件，且能实现断点续传。切片之间的空隙拼接需要严格按照分片索引顺序进行。

服务端合并与校验：后端收到complete_upload请求后，按索引顺序将分片文件合并成完整文件。合并过程中计算文件的MD5值与前端上传前的MD5比对，防止传输过程中数据损坏。校验通过后将文件存储到对象存储服务，这里推荐MinIO——本地部署的轻量对象存储，接口兼容Amazon S3，后端代码里只需要改一个endpoint配置就可以，以后需要切到云厂商的OSS或者S3时不用改代码，只需要换配置。

转码任务：文件入对象存储后，Celery异步任务队列里塞一个转码任务，用FFmpeg把视频转成H.264编码的多个码率版本（标清480p、高清720p、超清1080p），同时截取视频第3秒的画面作为封面图。转码是CPU密集任务，Celery的worker节点配置了并发数为2——太高的并发数在毕设演示用的低配机器上会导致转码和Web服务抢CPU资源。

元信息入库：转码完成后，Celery任务回调更新视频表的状态字段为published，同时将封面URL、各码率播放URL写入视频记录。视频的标签分析也在这个环节做——从视频标题和上传者填写的标签中提取关键词，匹配到系统标签库。

审核环节：新视频默认状态是pending，管理员在Django Admin后台审核通过后才转为published状态进入推荐池。这个环节用Django自带的status字段加Admin的list_filter就能快速搞定，完全不需要额外开发页面。

4.2 推荐接口的性能优化：从慢查询到毫秒级响应

推荐接口是整个系统性能要求最高的接口，因为它是App首屏的数据来源。我一开始的实现方案是同步计算——用户请求推荐列表时实时调用推荐模块的召回和排序逻辑。上线实测数据量到10万条视频时，接口响应时间飙到3秒以上，完全不可接受。

后来我优化成了两级缓存架构。

第一级是推荐结果缓存。每个用户的推荐列表计算结果直接写Redis，key设计为rec:{user_id}:{页码}，过期时间15分钟。用户下拉加载下一页时，直接从Redis取已经算好的第二页结果。用户刷完前两页后触发一个异步任务预计算第三页的推荐结果并写入Redis——这样用户滑动时的等待感几乎消失。

第二级是召回候选集缓存。用户兴趣画像的标签权重变化频率远低于推荐结果刷新频率，因此基于内容召回的候选视频集合可以做缓存。我给每个标签都保存了一个候选列表在Redis里，rec_candidates:{tag_id}，过期时间30分钟。做召回时直接批量从Redis取各标签的候选集合，避免每次请求都查数据库。这个优化直接让召回阶段的耗时从900毫秒降到80毫秒左右。

接口响应时间从3秒优化到200毫秒以内，整个前后端的体验完全上了一个档次。建议这张性能优化日志在答辩时做成对比图展示，是很好的加分项。

缓存更新的设计还有个细节：当一个视频的互动量出现显著变化时，需要主动失效相关缓存。我实现了缓存失效事件总线——点赞、收藏、评论行为发生时，发出事件消息，相关处理器将对应视频的推荐结果缓存和候选集缓存标记为待刷新。这个设计避免了用户的实时互动“石沉大海”，让推荐结果能快速反映最新反馈信号。

4.3 用户画像的实时更新机制与反馈闭环

用户画像是推荐系统的“燃料”，它的实时性直接决定了推荐的灵敏程度。我采用的机制是“增量更新 + 定时衰减”。

增量更新的触发点是用户交互行为，包括点赞、收藏、评论、完播、滑走（负反馈信号）。每次行为发生，行为日志表追加一条记录，同时异步任务更新用户画像表：

def update_user_profile(user_id, video_id, behavior_type): video_tags = VideoTag.objects.filter(video_id=video_id).values_list('tag', flat=True) weight_map = { 'like': 1.0, # 点赞权重最高 'favorite': 1.2, # 收藏说明强烈兴趣 'comment': 0.8, 'complete': 0.6, # 完整看完是有效曝光 'dislike': -0.8, # 滑走/不感兴趣负反馈 } delta = weight_map.get(behavior_type, 0) profile = UserProfile.objects.get_or_create(user_id=user_id)[0] interest_vector = profile.interest_vector for tag in video_tags: interest_vector[tag] = interest_vector.get(tag, 0) + delta profile.interest_vector = interest_vector profile.save()

注意这个更新操作放在了Celery异步任务里，而不是同步执行。原因很简单——高频交互行为如果同步写库会成为性能瓶颈，而异步化后用大量请求堆积，后端批量处理的效果更平滑。

定时衰减用Celery的periodic_task实现，每天凌晨4点执行一次全量画像衰减。衰减公式是weight *= 0.95，这个衰减系数需要根据产品节奏调——如果短视频内容更新特别快，衰减系数应该更激进（比如0.9），让旧兴趣的权重快速让位于新兴趣。

反馈闭环的最后一环是推荐效果分析。行为日志表里记录了每次推荐的曝光和用户对推荐内容的反馈。我写了几个分析脚本：统计各推荐位的点击率、完播率、负反馈率；分析不同兴趣标签组合下的推荐效果差异；对比新旧用户的推荐满意度。这些分析结果反过来再次指导排序权重和冷启动策略的调整。最典型的例子是我通过分析发现“推荐位第4个视频的点击率显著低于前后位”的规律——这大概率是用户浏览习惯形成的“信息疲劳点”，后来我调整了推荐结果排序，把更长的视频放在这个位置，整体列表的平均完播率随之上升。

5. 部署运维与避坑指南

5.1 从开发机到服务器的一键部署脚本

很多同学写的毕设项目只在本地跑得通，一旦部署到Linux服务器就各种报错。这个项目我写了完整的部署脚本，核心思路是用Docker Compose编排所有服务，保证环境一致性。

目录结构：项目根目录下建了docker-compose.yml，编排了五个服务——web（Gunicorn跑Django）、celery-worker（异步任务）、celery-beat（定时任务）、redis、mysql。五个服务用Compose的depends_on控制启动顺序，MySQL和Redis先启动，Web和Celery等它们就绪后再启动。

部署流程三步走：第一步拉取代码后执行docker-compose build构建镜像；第二步执行docker-compose up -d启动全部服务；第三步执行docker-compose exec web python manage.py migrate初始化数据库表结构。整个部署流程在全新服务器上从零到跑通在15分钟内可以完成。

关键环境变量集中在.env文件里配置，包括数据库连接信息、Redis地址、MinIO对象存储的密钥、Django的SECRET_KEY。配置文件里明确写了禁止把.env文件提交进Git仓库，这个细节在答辩时提一句“我考虑了配置安全和密钥管理”，是很大的加分项。

静态文件和媒体文件的处理也值得一提。Django的DEBUG=False模式下不会自动提供静态文件服务，需要在Nginx层处理。我在Nginx配置文件里把/static/和/media/两个路径直接映射到服务器的静态文件目录，其余请求反向代理到Gunicorn的8000端口。这套配置虽然简单，但足够应付大多数毕设演示并发。

5.2 常见部署问题和性能陷阱排查

部署过程中我踩过比较典型的几个坑，记录下来供大家参考。

第一个坑是MySQL编码问题。项目用到中文的标签和标题，在建库时如果没指定utf8mb4字符集，存中文会出现乱码甚至直接报错。解决方式是在docker-compose.yml的MySQL环境变量里加上command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci，保证建表时默认字符集就是utf8mb4。

第二个坑是Celery任务丢失。Celery默认使用的内存作为任务队列的Broker，服务重启后任务全部丢失。解决方式是使用Redis作为Broker，并且开启Redis的持久化配置。我写了一个wait-for-it.sh脚本，在启动Celery前检查Redis是否就绪，避免Celery启动时连接不上Redis导致线程阻塞。

第三个坑是Nginx配置里上传大小的限制。网上的默认配置通常只允许1MB到2MB的上传，而短视频文件动辄几十上百MB，如果不修改client_max_body_size配置，前端分片上传在最后合并时会收到413错误。我把这个值设为200MB，同时在前端也做了一层文件大小预校验，上传前就拦截掉超过限制的文件。

性能方面的排查，最常用的是两条命令：docker-compose logs -f web看Django的请求日志，每个接口的响应时间都清晰可见；redis-cli --bigkeys扫描Redis中的大键。我遇到过一次Redis内存暴涨的问题，排查后发现是推荐结果缓存没有设置过期时间，一个用户缓存一直存着不清理，用户量大了以后内存就顶不住了。加上过期时间之后问题直接消失。

还有一个容易忽视的性能杀手是Django ORM的N+1查询。比如视频列表页要展示每个视频的上传者信息，如果视频表里只存了user_id而查询时不加select_related('user')，那么展示100个视频就要额外执行100次用户信息查询。我在所有涉及关联外键的查询上都加了select_related或prefetch_related，性能提升立竿见影。

5.3 答辩演示时的高效操作路径

答辩演示环节的操作路径很有讲究，我建议按“核心功能优先、其次数据可视化、最后算法效果对比”的顺序来展示。

开场先展示注册登录和首页推荐流，快速建立“这是一个完整系统”的第一印象；接着创建一个新账号，选完感兴趣的分类后刷新首页，展示冷启动推荐的有效性；然后播放一个视频并点赞收藏，返回首页再刷新，证明用户行为对推荐的即时影响。这个过程一气呵成，全程只需两分钟。

第二部分展示Django Admin后台。重点展示视频管理列表的筛选功能——按审核状态过滤、按分类过滤、显示播放量和互动量。同时展示数据看板页面，讲解三个核心指标的变化趋势。这里要提前准备好一批模拟数据，让图表看起来更饱满。

第三部分是推荐算法效果对比的展示。我准备了两个账号，一个用随机推荐逻辑、一个用完整的推荐算法，分别刷20个视频后回到首页，明显能看出两个账号的推荐结果差异——算法账号的推荐内容高度贴合其历史行为，随机账号则内容分散毫无规律。这个对比直观展示推荐系统的价值，比任何技术讲解都有说服力。

最后打开代码编辑器，直接展示核心推荐模块的代码结构。重点讲解排序融合公式的每一部分对应什么设计意图，再展示Redis缓存和异步任务的调用链。注意展示代码时不要逐行念，而是画调用流程图讲清楚“用户请求来了，系统经过哪几步把推荐结果返回给前端”的整体脉络。

答辩被问到最多的问题是“你这个推荐系统和抖音的推荐有什么区别”“推荐效果怎么量化评估”“数据量大了之后系统还能不能扛得住”。前两个问题可以直面回答“毕设场景做了合理的简化，但核心思路是相通的”“用离线指标加上在线小流量实验来评估”；第三个问题要诚实说明当前架构的瓶颈在推荐计算的实时性和存储层的单机限制，然后给出扩展方案——引入更多Celery worker、上读写分离、用ES替换MySQL做检索、推荐计算改用批处理预计算。答辩老师更看重的是你对系统局限性的清晰认知和改进思路的可行性，而不是项目本身有多完美。

6. 项目扩展方向与进阶优化建议

做完这套系统如果时间有余力，我建议往四个方向延伸。

接入日志分析平台：把行为日志输出到ClickHouse或ElasticSearch，用Kibana做可视化大盘，展示推荐位点击漏斗、兴趣标签分布、时段活跃情况。这个方向能显著提升系统的“数据感”，也为后续基于日志训练推荐模型打基础。

推荐算法升级为Embedding向量召回：把视频的标题和标签用预训练模型编码成向量，存入Milvus或Faiss向量数据库，推荐时直接计算用户向量和视频向量的相似度。这个方案能突破标签匹配的“词汇天花板”——两个视频即使没有共同标签，只要语义相近就能被召回。这个方向适合作为毕设的进阶方向，工程和算法的复杂度都上来了。

增加短视频社交玩法：包括关注、粉丝、私信、评论@、同城视频流等功能。社交关系的引入能给推荐系统带来新的信号——好友看过的视频、关注的人的视频在推荐列表里加权。这个方向扩展性很强，会用到Django Channels做实时通知推送，技术含金量也会提升。

搭建管理端的实时数据监控大屏：用WebSocket从后端推送实时事件流，前端用图表库绘制动态排行榜、实时互动热力图、新老用户占比趋势。毕设答辩时大屏展示的视觉效果很震撼。这个方向不需要改推荐算法，主要是工程实现，适合前端功底不错的同学。

总的来说，这套系统最核心的价值不在于单个算法有多先进，而在于把“用户—内容—交互—反馈—推荐优化”这个完整闭环做通了。从零到一跑通一个推荐系统，你收获的绝不仅仅是一个毕设分数，更是对推荐系统工程化的整体认知——这套思维框架在你以后做任何用户增长、内容分发、个性化服务方向的技术工作时，都会持续复用。