基于机器学习的就业岗位推荐系统全栈实践指南

这套“基于机器学习的就业岗位推荐系统”，我前后折腾了一个多月才把 Python + Django + Vue 这条完整链路跑通。从最初的爬数据、清洗数据，到训练推荐模型，再到写后端接口、搭前端页面，最后部署上线，每一步都踩了不少坑。如果你也在做计算机毕业设计，或者想系统学一下推荐系统的落地玩法，这篇文章应该能帮你省下大量试错时间。

先把这个项目能做什么说清楚：用户注册登录后，系统会根据他的技能标签、期望薪资、意向城市，以及历史浏览记录，从岗位库里筛选出一批匹配度最高的职位推给他。管理员端可以维护岗位信息，查看推荐效果。整个系统的核心技术栈就是标题里那四样：Python负责数据处理和算法训练，Django提供后端 API 和管理后台，Vue 做前端交互界面，机器学习模型负责算相似度、算推荐分。适合的人群很明确：正在做毕业设计的计算机专业学生、想快速入门推荐系统的开发者、以及想把前后端分离项目练熟的同学。

下面我按自己的实际开发过程，把这个项目从设计到上线完整拆给你看。

1. 项目整体拆解：为什么选这套技术栈与推荐方案

1.1 技术栈选型背后的考虑

先说 Django。很多学生纠结 Flask 和 Django 选哪个，我的看法是：毕设项目直接用 Django，理由很实在。首先，Django 自带 Admin 后台，用户管理、岗位管理这种最琐碎的部分，你几乎不需要写代码就能用起来，能省下大把时间。其次，Django 的 ORM 对新手极其友好，尤其在后面做“根据职位名称筛选”“根据技能标签匹配”这类查询操作时，比写原生 SQL 舒服太多。最后，毕设答辩时老师大概率会问“你这个项目有没有权限控制”“数据是怎么管理的”，Django 自带的认证系统、中间件机制，能让你在答辩时有话可说。

Vue 这边没什么悬念。前后端分离已经是现在的主流做法，Vue 生态成熟、教程多、打包部署方案也简单。更重要的是，推荐系统天然需要做“动态数据展示”，岗位列表、推荐结果、用户画像这些页面，用 Vue 的数据绑定来做，体验比 jQuery 时代的传统模板渲染好一个量级。前端这块我的建议是别贪多，把 Vue Router 的路由管理、Axios 的接口封装、Element UI 或 Element Plus 的表格表单组件用熟，就足够撑起一个完整的毕业设计了。

机器学习这块要重点说一下。很多同学一听到“机器学习”就以为是深度神经网络、大模型那些，实际做毕设完全不需要那么复杂。我的方案是对岗位描述做文本向量化，再计算用户画像和岗位之间的相似度，排序后产出推荐结果。这是典型的“基于内容的推荐”，算法上只用到了 TF-IDF + 余弦相似度这两招，全部用 scikit-learn 就能搞定，训练速度快、效果肉眼可见、答辩时还能把原理讲得清清楚楚。如果非要追求“高大上”，可以在此基础上叠加一个协同过滤模块，用用户的历史行为算岗位间的共现关系，我后面会详说。

1.2 推荐策略怎么选：内容推荐优先，协同过滤增强

推荐系统的经典算法无非两大类：基于内容（Content-Based）和协同过滤（Collaborative Filtering）。如果你去翻《机器学习西瓜书》或者周志华老师的课程资料，里面关于推荐的内容一般会先讲协同过滤，因为它纯粹依赖用户行为数据，不需要理解“物品是什么”。但实际做毕设时，我强烈建议你反过来：以内容推荐为主，协同过滤为辅。

原因很简单。协同过滤需要足够多的用户-物品交互记录，也就是海量的“谁看了什么”“谁投递了什么”这样的行为日志。你用爬虫或者手工造数据，很难造出大规模、有规律的行为数据，稀疏矩阵会让协同过滤的效果大打折扣，甚至出现“冷启动”问题——新用户没有任何行为，协同过滤完全失灵。而内容推荐不需要用户历史，只要把岗位描述清洗好、向量化，新用户一注册，填完技能和求职偏好，马上就能算出推荐结果。这在答辩演示时特别重要，评委第一次打开系统，你当场给他推荐出合理岗位，比让他等系统“学习”半天的体验强太多。

我的最终方案是这样设计的：主推荐引擎用内容匹配，输入是岗位画像和用户画像，输出是相似度排名；同时加一个简单的行为加权模块，用户浏览过、收藏过的岗位类型，下一次推荐时同等条件下优先出现。这个方案既有算法深度，又不会因为数据不足导致效果崩掉。

1.3 数据怎么来：造数据比爬数据更靠谱

这块是很多人的第一个坑。你可能会想，既然做就业推荐，那就去某招聘网站爬几万条岗位数据。我劝你冷静一下：爬虫本身需要维护反爬策略，岗位数据的字段参差不齐，清洗工作量大到你怀疑人生。而且你无法控制爬下来的数据质量，万一出现大量重复岗位、乱码文本、缺失字段，后面做模型训练全是麻烦。

我的做法是：写一个 Python 脚本，按行业、岗位类型、技能要求生成高质量模拟数据。比如岗位表里包含职位名称、公司名称、薪资区间、工作城市、学历要求、技能标签、岗位描述文本。生成的时候我会刻意控制数据分布，让“Python开发”这类岗位的技能标签集中在 Django、Flask、Linux、MySQL上，“前端开发”集中在 Vue、JavaScript、Webpack上，这样模型学出来的相似度才有区分度。一共生成 2000 条左右的岗位数据，再配合 50 个模拟用户、每个用户 20-50 条行为记录，就足够支撑完整的推荐流程演示。

这里也告诉你一个数据生成的技巧：岗位描述文本不要用拼接模板，否则 TF-IDF 计算出来的向量会高度雷同。我是在一个基础模板上，随机插入项目经验、技术栈细节、业务方向这些补充句，模拟真实招聘文案的多样性。后面你训练模型时会发现，这一步直接决定了推荐结果的区分度。

2. 核心细节拆解：从用户画像到推荐算法，每一步都是关键

2.1 用户画像与岗位画像的定义方式

推荐系统的本质就是“匹配两个画像”。所以我花了比较多心思设计画像结构，这部分想清楚了，后面的算法实现反而很简单。

用户画像分两部分。一部分是结构化字段：意向城市、期望薪资下限、学历要求、工作年限。另一部分是技能标签，我把它做成了多选标签的形式：Python、Java、Vue、Django、MySQL、Redis、Docker 等十几个常用技能。用户注册时勾选，可以多选。这个设计的好处是：技能标签可以直接做精确匹配计算，结构化字段可以做硬性过滤，两者互补。

岗位画像同样分两部分：结构化字段包括工作城市、薪资区间、学历要求、经验要求；文本字段包括岗位描述、职责说明、技能要求描述，这部分是机器学习模型的输入。

这里我特别想提醒你一个细节：画像设计决定了推荐算法能用到什么程度，直接关系到论文的工作量和创新点。如果你只在画像里放“城市”和“薪资”，那推荐逻辑就是一个 SQL 查询，答辩时老师会觉得你没有做推荐系统。而有了技能标签和描述文本，你才能名正言顺地引入 TF-IDF、余弦相似度这些机器学习方法。

2.2 文本向量化与相似度计算的数学逻辑

先说人话版本：岗位描述是一段话，计算机没法直接理解“这段文字和那个技能标签像不像”。所以我们要把文字变成一组数字，这组数字就叫向量。TF-IDF 做的是这样一件事：看每个词在一篇文档里出现的次数（词频），同时看这个词在多少篇文档里出现过（逆文档频率）。出现次数多、但在所有文档里都不常见的词，权重就高，反之权重就低。“精通”“负责”这种到处都有的词，权重会被压得很低，“Kubernetes”这种特定技能词，权重就会被抬高。

有了向量之后，计算相似度就是计算两个向量之间的夹角余弦值。余弦值越接近 1，说明两个向量指向的方向越接近，也就是文本内容越相似。这个值直接作为推荐分数。你不用自己手写这些公式，scikit-learn 的TfidfVectorizer和cosine_similarity已经把两步封装好了。但答辩老师如果问原理，你需要能把这个逻辑讲清楚。

代码层面大概长这样：

from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity # job_texts: 每个岗位的描述文本列表 # user_text: 把用户技能标签拼成一段文本 vectorizer = TfidfVectorizer(token_pattern=r"(?u)\b\w+\b", max_features=5000) job_vectors = vectorizer.fit_transform(job_texts) user_vector = vectorizer.transform([user_text]) sims = cosine_similarity(user_vector, job_vectors).flatten() top_k = sims.argsort()[::-1][:10]

注意这里有个坑：用户文本里可能包含岗位描述里没有出现过的词。所以必须先用岗位语料库fit这个向量器，再对用户文本做transform，顺序不能反。我第一次写反了，导致新词被全部忽略，推荐结果完全失真。

2.3 协同过滤模块：让推荐结果有“人情味”

前面说了内容推荐是主力，但只靠内容推荐有个明显问题——系统永远推荐“和你填过的技能相似”的岗位，永远跳不出用户给自己设定的圈子。比如一个用户只填了 Python，那他就很难发现“数据分析师”这种其实很适合他的岗位。协同过滤的作用就是弥补这个盲区。

我实现的简化版协同过滤思路是：建立用户对岗位的行为矩阵，行为包括浏览、收藏、投递，分别赋予 1、2、3 的权重分，然后计算用户之间的相似度。当某个目标用户 U 收藏过一个岗位，而与他相似度最高的用户 V 也收藏过这个岗位，就把该岗位提权后排进 U 的推荐列表。

代码实现不复杂，核心就两步：

# 构建用户-岗位行为矩阵 interaction_matrix = user_job_matrix(user_id, job_id) # 稀疏矩阵 # 用皮尔逊相关系数计算用户相似度 from sklearn.metrics.pairwise import pairwise_distances user_sim = 1 - pairwise_distances(interaction_matrix, metric="correlation")

协同过滤的训练数据我同样是脚本生成的。这里有一个经验之谈：行为数据的生成要符合直觉，比如 Python 开发者的行为记录集中在他感兴趣的 Python 岗位、后端岗位，浏览和收藏行为要集中，不要随机乱点，否则用户相似度算出来全是噪声。你造了一小时数据，最后模型效果好不好，完全取决于你的数据编排是否符合常识。

2.4 Django ORM 实操：查询、删除对象那些绕不开的坑

Django 的 ORM 在毕设项目里承担了大量脏活累活。我整理几个你一定会用到的操作，顺便说说我踩过的坑。

查询岗位时，最常用的过滤器是filter、exclude、order_by。比如按薪资过滤：

jobs = Job.objects.filter(salary_min__gte=user.expected_salary_min) jobs = jobs.exclude(education_requirement__gt=user.education) jobs = jobs.order_by("-salary_max", "-recommend_score")

这里salary_min__gte的意思是 salary_min 大于等于某个值，双下划线在 Django ORM 里表示字段关系或查询条件，这是新手很容易卡壳的地方。如果你想做模糊查询，用job_title__icontains="python"，这个icontains不区分大小写，非常适合招聘岗位这种英文技能名的匹配场景。

删除对象这个操作我专门提醒一句：Django 的删除分两种格局。单个对象调用.delete()会级联删除所有外键关联的数据，比如你删掉一个岗位，所有外键指向它的收藏记录、行为日志全部会被清空。而QuerySet.delete()是批量操作，比如UserBehavior.objects.filter(user_id=10086).delete()会一次性删掉该用户的所有行为记录。我在开发时曾经因为调试数据，误删了一张核心表的外键级联数据，那个下午非常难熬。所以写删除功能前，一定要确认外键关系和on_delete参数，或者先用事务包一层，操作前打印受影响的数据条数。

还有一个小技巧：查询用户画像和推荐行为的关系时，可以用select_related和prefetch_related避免 N+1 查询。职位数量一多，页面接口会变慢，这两个方法能大幅减少 SQL 查询次数，答辩时提一嘴“我做了查询优化”，印象分直接拉满。

2.5 登录鉴权与前端路由：JWT 方案怎么和 Vue 配合

毕设系统里，用户登录和权限校验是必考题。很多初学者喜欢用 Django 自带的 Session 机制，配 Cookie 使用，这在前后端不分离的老项目里没问题。但你的项目既然是前后端分离，前端跑在 Vue 开发服务器上（比如 localhost:8080），后端跑在 Django（比如 localhost:8000），跨域请求下 Session 的 Cookie 设置会变得非常别扭。我最开始试过在前端手动处理 Cookie 的跨域携带，各种踩坑之后直接换了方案——JWT。

JWT 的原理不复杂：用户登录成功后，后端签发一个包含用户 id 和过期时间的加密令牌，前端把它存到 localStorage 或 Vuex 里，之后每次请求在请求头带上Authorization: Bearer <token>即可。后端通过自定义中间件解析并验证这个 token，再取出当前用户。

Django 侧我用的是djangorestframework-simplejwt这个库，配置方式非常简单：

REST_FRAMEWORK = { "DEFAULT_AUTHENTICATION_CLASSES": ( "rest_framework_simplejwt.authentication.JWTAuthentication", ), }

前端用 Axios 拦截器统一加请求头：

axios.interceptors.request.use(config => { const token = localStorage.getItem("token"); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; });

这样设计的好处是明显的：后端不需要管 Session，前端也不用操心 Cookie 跨域，整个登录态管理变得非常干净。前端路由守卫里再做一个前置判断，没拿到 token 就强制跳转登录页，一套完整流程就通了。

这里还有一个细节：Django REST Framework 的 JWT 默认 token 有效期是 5 分钟，对毕设演示来说太短了。我当时开着项目写前端，每过几分钟接口就报 401，排查了半天才发现是 token 过期了。把ACCESS_TOKEN_LIFETIME改成 60 分钟或更长，调试体验会顺畅很多。

2.6 前后端通讯与实时推送：Django WebSocket 的增强玩法

如果你的毕设想要加亮点，“像实时推送推荐结果”是一个非常出彩的功能点。基础做法是前端定时器轮询后端接口，每 30 秒拉一次最新推荐。但更高阶一点的做法是用 WebSocket，后端有新的岗位推荐生成时，主动推送给前端。

我当时用的是 Django Channels 来实现 WebSocket。这里要提醒你，Channels 的安装配置比普通 Django 应用稍微复杂，需要切换 ASGI 服务器，还要配置 Redis 作为 channel layer。如果你怕麻烦，轮询方案在毕业设计里完全够用，毕竟推荐结果不是秒级变化数据。

如果你决定上 WebSocket，核心思路是这样：用户登录后建立 WebSocket 连接，连接名包含用户 id；Django 侧在推荐模型跑完后，向对应的 channel 发送消息；前端监听消息并更新推荐列表。整个链路打通后，演示效果非常有冲击力——你可以在后台新增一条符合用户画像的岗位，前端推荐列表“自己”刷新出来，这种动态效果比静态展示图有说服力得多。

3. 实操过程与核心环节实现：从环境搭建到部署上线的完整路径

3.1 环境准备：Python、Node、虚拟环境一网打尽

这个项目的环境准备说难不难，说简单也不简单，卡住新手的往往是一些基础环节。Python 建议直接装 3.9 或 3.10 版本，Django 4.x 对这两个版本支持最好。装 Python 的时候有个坑：Windows 上安装时要把“Add Python to PATH”勾上，否则后面命令行里敲python会报找不到命令。

装完 Python 后，建议用虚拟环境隔离项目依赖，我在项目根目录下运行的命令是：

python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install django djangorestframework djangorestframework-simplejwt pip install scikit-learn pandas numpy channels channels-redis

前端环境需要 Node.js 和 npm。Vue 项目我用 Vite 脚手架创建，比 Webpack 老方案快很多：

npm create vite@latest frontend -- --template vue cd frontend npm install vue-router axios element-plus npm run dev

这里有几个版本兼容性的坑要提前说。Element Plus 目前要求 Vue 3，如果你习惯看老教程用 Element UI，那是 Vue 2 的组件库，装进 Vue 3 项目里会直接报错。Vite 和 Node 也有版本绑定，Node 版本过旧会提示不支持。建议动手前先把 Node 升到 18 以上，能省掉一堆奇奇怪怪的报错。

3.2 推荐模型的完整训练流程与核心代码

整个项目里最核心的代码就是推荐引擎这一块，我详细展开讲讲。项目文件结构我分成三块：数据处理脚本、模型训练脚本、推荐服务脚本。

数据处理脚本负责从数据库导出岗位数据并清洗。你会遇到的实际问题是：岗位描述文本里混着 HTML 标签、特殊字符、空值。我的清洗步骤是正则去掉尖括号标签、去掉标点符号、把所有英文技能名统一小写。这一步不做干净，TF-IDF 会把<p>和Python当成两个独立特征。

模型训练脚本的核心逻辑是：

import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity # 1. 从数据库导出岗位数据 jobs = pd.DataFrame(list(Job.objects.all().values("id", "job_title", "skills", "description"))) # 2. 合并技能标签和描述文本为单一文本字段 jobs["text"] = jobs["skills"] + " " + jobs["description"] # 3. 训练向量器并保存，供后续接口调用 vectorizer = TfidfVectorizer() job_matrix = vectorizer.fit_transform(jobs["text"]) # 4. 选一个用户做验证 sample_user_text = "python django mysql redis" user_vec = vectorizer.transform([sample_user_text]) sim_score = cosine_similarity(user_vec, job_matrix).flatten() # 5. 输出 Top 10 岗位 id top10 = sim_score.argsort()[::-1][:10] print(jobs.iloc[top10]["job_title"])

模型训练完以后，需要把向量器和岗位向量矩阵保存下来，推荐接口才能秒级响应。我用的joblib保存：

import joblib joblib.dump(vectorizer, "models/vectorizer.pkl") joblib.dump(job_matrix, "models/job_matrix.pkl")

推荐服务模块加载这两个文件，再接一个查询函数，就是完整的线上推理逻辑了。这套流程跑通之后，你在 Django 的视图里调用推荐模块，接口返回的是排序后的岗位 id 列表，再通过 ORM 查出完整信息返回前端。

3.3 Django REST Framework 接口设计与 Vue 调用

后端接口我按 RESTful 风格设计的，最核心的几个接口如下表：

视图层用 DRF 的 APIView 写，权限上推荐接口必须要登录：

from rest_framework.views import APIView from rest_framework.permissions import IsAuthenticated from rest_framework.response import Response class RecommendJobsAPIView(APIView): permission_classes = [IsAuthenticated] def get(self, request): top_ids = get_recommend_list(request.user.id) job_list = Job.objects.filter(id__in=top_ids) # 按推荐分数重排 job_map = {job.id: job for job in job_list} ordered = [job_map[jid] for jid in top_ids if jid in job_map] return Response(JobSerializer(ordered, many=True).data)

前端用 Axios 调用时，推荐页面的核心逻辑就是拿到 token 后请求：

const result = await axios.get("/api/recommend/jobs/"); this.jobList = result.data;

Vue 这边还要注意路由设计。我用的 Vue Router 是 history 模式，这在本地开发没问题，但部署到 Nginx 时，如果直接刷新 /recommend 这个地址，会返回 404。原因是 Nginx 默认只认根路径下的真实文件。解决办法是在 Nginx 配置里加一句 try_files：

location / { try_files $uri $uri/ /index.html; }

这个坑我印象非常深刻，因为当时部署后直接刷新页面白屏，害我以为前端代码打包错了，排查了半天才想起来是 history 路由的锅。后面真实部署时建议直接用 hash 模式，省心，不过 history 模式配好之后地址栏好看一些。

3.4 部署上线：Linux + uWSGI + Nginx 还是 Docker？

毕设项目通常要求提供一套可运行的部署方案，老师也可能现场问“你这个系统怎么部署到服务器上”。我的建议是把 Docker 方案和传统方案都掌握，因为两者各有适用场景。

传统方案是 Linux 服务器上用 uWSGI 跑 Django，Nginx 托管前端静态文件并反向代理后端 API。具体步骤概括如下：服务器上安装 Python 和 Node，把前后端代码 clone 到 /opt 目录；打包 Vue 项目生成 dist 静态文件，放到 Nginx 的 html 目录；用 uWSGI 启动 Django，通过 socket 文件与 Nginx 通信。这套方案的好处是可控性强、透明、排查问题方便，对理解整个系统运行原理有很大帮助。

Docker 方案则主打快速复现。我用 docker-compose 编排了三个容器：前端 nginx 容器、后端 Django 容器、Redis 容器。Dockerfile 的编写逻辑是：后端镜像基于 python:3.10-slim，装好依赖后启动 gunicorn 运行 Django；前端镜像基于 node 构建出 dist 后，用 nginx 镜像托管。这样一条docker-compose up -d就能把整站拉起来，对答辩环境移植特别友好。

我实际部署时选择的是 Docker 方案，因为服务器上原本就有 Docker 环境，不需要额外折腾 Python 版本和虚拟环境。这里也想顺带提醒一句，Linux 下安装 Python 如果不用 Docker，建议直接用 apt 装系统版本，或者自己编译源码，网上教程很多但是版本一定要和本地开发保持一致，否则模型依赖的 scikit-learn 版本对不上，导入会出错。

3.5 论文结构参考：让毕设“有肉可写”

很多同学写进度到一半才发现论文没素材，但如果你按我上面的开发路径走，论文素材几乎就是现成的。一个比较稳的论文结构是：

第一章绪论，写研究背景和意义，落脚在就业信息过载、传统招聘平台信息匹配效率低这些现实痛点上。第二章相关技术介绍，分别简述 Python、Django、Vue、机器学习与推荐算法，这里记得写 TF-IDF 和协同过滤的原理。第三章需求分析，画用例图说明用户、管理员两类角色的功能需求，分析系统的功能需求和非功能需求。第四章系统设计，写整体架构、数据库表结构、接口设计。第五章核心算法与实现，推荐系统的向量化流程、相似度计算、推荐生成是重点，可以附上实验数据：随机抽取 50 个测试用户，统计推荐结果的准确率和覆盖率。第六章系统测试，写测试用例和执行结果，顺便展示系统截图。第七章总结与展望。

我特别建议你在第五章加一个实验对比：分别用“纯 SQL 筛选”和“TF-IDF + 协同过滤”给同一批用户生成推荐列表，对比命中用户期望岗位的比例。这个对比一放，论文的算法价值就立住了。答辩的时候老师很可能会问推荐效果到底怎么样，这时候你拿出准确率的数字，比空口说“效果不错”有说服力得多。

4. 常见问题与排查技巧实录：这些坑我替你踩过了

4.1 环境与依赖类问题

先列一个最高频的报错：python命令在终端里找不到。这通常发生在 Windows 上装完 Python 后没勾选 Add to PATH。解决办法是打开“系统设置 -> 环境变量”，把 Python 的安装目录和 Scripts 目录手动加到 Path 里。Linux 上如果没装 Python，各个发行版也都有自己的包管理器，Debian/Ubuntu 系统直接apt install python3 python3-pip就行。这里提醒一句，Linux 下用pip3而不是pip指向 Python 3 版本。

第二个常见问题是安装 scikit-learn 失败。Windows 上如果 Python 是 64 位而安装包源不稳定，可以改用国内镜像源：

pip install scikit-learn -i https://pypi.tuna.tsinghua.edu.cn/simple

如果还是报错，多半是 Python 版本太新或太旧，建议换 3.9 再试。scikit-learn 的依赖 numpy、pandas 也一样，优先考虑换源和换版本两个操作，90% 的安装问题都能解决。

4.2 数据与推荐效果类问题

推荐结果全是“什么东西都推荐”或者“推荐的岗位驴唇不对马嘴”，不用怀疑，问题基本出在文本向量化环节。第一检查 TF-IDF 的 fit 顺序，必须先用岗位语料训练，再去转换用户文本。第二检查清洗逻辑，如果技能标签里的英文词和岗位描述里的英文词大小写不一致，就会被当成两个不同词，相似度直接变成 0。第三检查停用词，TfidfVectorizer默认不处理中文停用词，如果用户画像里有“的”“了”“和”这类字，也会变成无关特征干扰结果。我的做法是自定义停用词表，同时给技能标签手动加高权重，比如用户勾选了 Python，在拼接用户文本时写三遍“python”，提升它在 TF-IDF 里的重要性。

还有同学会遇到协同过滤矩阵太大导致内存问题。2000 个岗位乘以 200 个用户，行为矩阵只有几十万条记录，其实不算大，但如果用稠密矩阵存储就会浪费内存。解决办法是scipy.sparse稀疏矩阵存储，或者直接限制用户取最近 30 天的行为数据。

4.3 前后端联调类问题

跨域是前后端分离项目里绕不过去的一道坎。前端跑 8080 端口，后端跑 8000 端口，浏览器会拦截跨域请求。解决方案是 Django 这边装django-cors-headers，在 settings.py 里配置：

CORS_ALLOWED_ORIGINS = [ "http://localhost:5173", "http://localhost:8080", ]

这里有个隐蔽的坑：如果你前端改过端口，比如 Vite 默认是 5173 而老教程是 8080，需要把两个都写上，否则报错找半天都不知道是端口没匹配上。

前端接口报 401 多了，你要先看是不是 token 过期。前文说过 JWT 默认 5 分钟有效期的问题，调长或做无感刷新都行。另外 Vue 路由刷新后白屏的问题，前面也提到了，加 Nginx try_files 或者改用 hash 模式，二选一即可。

还有一个 Vue 的经典问题值得记一笔：项目里如果引用了需要额外解码能力的媒体资源（比如有些播放器格式需要对应的插件配置），会有很多同学卡在“前端页面显示异常”这个状态。我的建议是普通毕设项目不要上这些花活，所有图片、视频资源统一用标准格式，省时间保平安。

4.4 问题速查表

5. 开发顺序与时间安排建议

做这种全栈项目，最忌讳的是东写一块西写一块，最后哪里都通了但连不起来。我按自己的经验给你排一个时间线，照这个顺序来，每一步的产出都能被下一步直接使用。

第一阶段先搞数据与模型。不要一上来就写 Django，先用脚本把岗位数据生成好，把 TF-IDF + 相似度的推荐模型跑通。这阶段最重要的产出是：你拿到了一个可以运行的推荐脚本，输入一个用户画像，输出 10 个岗位 id。这个脚本就是你整个项目的心脏，后面所有代码都围着它转。我当时在这个阶段花了一周，主要是磨数据和调清洗逻辑。

第二阶段写 Django 后端。建好岗位表、用户表、行为表的模型，把 DRF 接口搭出来。推荐接口暂时可以用模型脚本里的离线计算结果顶替，先不用考虑实时性。这个阶段的里程碑是：用 Postman 调用接口，能拿到正常的岗位列表 JSON。

第三阶段写 Vue 前端。把登录注册、岗位列表、推荐展示、个人中心这几个页面搭好，接上后端接口。这里要注意顺序：先把登录流程打通，因为推荐接口需要 token 鉴权，登录不通后面全是白搭。前端开发时如果接口报错，先看后端控制台日志，大多数情况下是后端字段名对不上。

第四阶段做细节增强。加 WebSocket 实时推送、加行为记录、调推荐效果、写测试用例。这四个阶段下来，论文的第五章素材基本就齐了。第五阶段是部署，把自己项目打包到服务器上跑通，顺便把部署过程截图留下来，论文第六章可以直接用。

对了，源码和论文的准备有一个节奏建议：建议从一开始就按照论文的章节结构开发，比如写每一个模块时同步记录截图和测试数据。很多同学最后赶论文，原因是开发完以后完全不想回头去补文档。你边做边记，最后论文就是一道填空题，非常轻松。

6. 答辩时的加分点与避坑策略

最后一个环节，说说毕业设计答辩的评估角度，毕竟这个系统的最终目标是帮大家顺利毕业。根据我带过的项目经验和身边同学的反馈，评委老师最关注的通常不是代码多复杂，而是三件事：系统是否完整可运行、算法是否真实有效、你对自己的项目理解是否深入。

系统完整性最简单粗暴的检验方式就是现场演示：登录、填画像、看推荐、管理员后台维护岗位。这四个环节千万不能出 bug，尤其是登录和推荐接口，一定要在答辩前反复测试。我当时的做法是准备一个已经训练好的模型和一个测试账号，演示前先手动跑一遍所有流程，确保万无一失。

算法有效性方面，其实有一点可以提前积累：准备一个你模型输出的具体 case。比如选取一个用户画像为“Python 后端、期望薪资 15-20K、城市武汉”的测试用户，打印出推荐结果，分析为什么排第一的岗位匹配度高。这种“能讲出细节”的案例，比列一堆空洞的效果指标更能让评委信服。

项目理解深度方面，你要能顺畅回答三连问：推荐系统是怎么实现个性化推荐的？为什么选 TF-IDF 而不是 Word2Vec？冷启动问题是怎么处理的？答案我都藏在前面各小节里了——TF-IDF 做文本向量化、余弦相似度算匹配、冷启动用内容推荐兜底。把这些用自己的话讲一遍，回答思路清晰，基本就稳了。

再讲一个容易忽视的点：代码里不要留无用的调试信息。答辩时老师会现场打开代码看，如果你源码里全是 print 调试数据、注释混乱、还有临时测试用的死代码，印象分会减不少。提交前花一小时做代码清理，该删的删，该写的注释用简洁中文写清楚，这是性价比极高的准备工作。

关于推荐系统的最后几点体会

走到这里，你基本已经把这个项目的完整脉络掌握得差不多了。如果让我这个“过来人”说点更深的体会，我想强调两件事。

第一，推荐系统不是一个跑完算法就结束的模块，它是一条串联用户、数据、后端、前端的完整链路。你在这个项目里学到的不是某几个公式，而是“如何把一个想法变成一套别人能用的系统”的能力。这种全栈思维，比单一技术栈的掌握值钱很多。

第二，调试推荐效果时要有点耐心。模型训练好以后，第一次推荐结果往往不理想，这不代表算法错了，很可能是数据问题。我当时为了达到一个满意的推荐效果，前前后后调整了三次数据生成脚本，每次都要重新训练模型。这个循环过程看似枯燥，但恰恰是它让你真正理解每个特征在起什么作用。那些一调试不出来就放弃的同学，最后普遍在答辩时被问得比较狼狈。

如果以后你想继续扩展这个项目，我建议往这两个方向走：一是引入深度学习模型，比如 Embedding 技术，把用户和岗位映射到同一向量空间；二是做成实时推荐，用上 Kafka、Flink 这类流式处理框架，处理用户的实时行为流。当然，这对毕设来说已经是超纲题了，留着作为你入学研究生或者工作后的进阶方向更合适。

这套基于机器学习的就业岗位推荐系统，代码量其实不大，算法也不算复杂，但麻雀虽小五脏俱全。做完它，你等于把 Web 开发、数据库设计、算法应用、系统部署这些能力都过了一遍，这大概就是毕业设计最大的价值所在。按我上面讲的顺序一步步来，遇到问题就翻翻这一篇的问题排查部分，这套系统真正跑通只是时间问题。