基于Python的大学生就业数据分析系统：从Django选型到可视化部署完整实践

最近来问我项目怎么做的人里，十个有六七个撞在同一个题目上：基于Python的大学生就业数据分析系统。更常见的问法是，有人直接拿“django-flask基于python”这种标题过来，说模板库里下载了，问能不能帮忙看看。这个题确实是毕业设计圈里火了很久的一类，因为它把数据采集、数据处理、Web开发、可视化分析全揉在了一个系统里，做完之后特别适合演示，答辩的时候也好讲。但我看得最多的翻车现场也很一致：数据是手工编的假数据，图表是找现成截图贴进去的，后台只搭了个空壳，框架到底干了什么完全说不出来。这篇文章我不打算讲什么高深的东西，就按照一套真实能跑、逻辑完整的系统来做拆解，从需求理解、技术选型、数据获取、系统实现到部署排坑，一条线走完。给正在准备这个题目、或者已经做到一半卡住的朋友一个可以直接照着做的完整参考。

1. 需求拆解与技术选型：先别急着敲代码，把几个关键问题想清楚

1.1 标题里的“django-flask”到底应该怎么理解

我头一回看到“django-flask基于python”这种题目的时候，也愣了几秒。Django和Flask是两个完全独立的Python Web框架，正常开发场景里几乎不可能把它们同时作为主力框架用在同一个业务系统里，硬凑在一起只会带来路由冲突、配置混乱、依赖打架这些麻烦。那为什么这种标题满地都是？大多数情况是选题系统自动生成的题目名称，把一堆相关技术关键词直接堆在一起；也有一部分同学误以为django-flask是一个完整框架名。

实操层面你只需要选一个。我给绝大多数人的建议是：选Django。

理由特别直白：这个项目的核心组成是后台管理、数据库模型、用户登录、图表数据接口，这几点恰好全是Django的强项。Django自带Admin后台，模型一写，增删改查的后台管理界面直接就有了，省掉一大截手写CRUD的时间；它的ORM用起来也顺手，查询、筛选、聚合都有现成接口；用户认证和权限控制同样是内置的。如果你选Flask，这些功能基本都要自己接第三方库或者自己从头写，整个项目的代码量至少多出两到三倍。

当然Flask也不是不能做。它足够轻，灵活度高，适合做纯接口服务。如果你对Django不太熟，已经用Flask做了大半，那继续用Flask也没问题，只要把结构写干净、功能闭环做完整就行。但如果你是刚开始做，选Django是最省力气的路线。

下面这张表是我根据实际体验整理的对比，给还在摇摆的人做个参考：

1.2 把“就业数据分析”拆成三个层次

很多同学拿到这个题目之后，第一反应是“画几张图表”，于是就开始找好看的图表模板。这不是不对，但如果只做到这一步，系统很容易变成一张皮，数据是死的，图和后端没有任何关系，答辩老师一问就露馅。

真正的就业数据分析系统，至少应该包含三个层次：

第一层是数据接入层。你要有办法拿到就业相关的原始数据，并且把它清洗成统一、标准、可用的格式。数据可能来自招聘平台公开的岗位信息、学校就业质量报告里的统计表、问卷系统导出的结果，甚至是一些整理好的Excel文件。这个层次解决的是“数据从哪里来、怎么变干净”的问题。

第二层是业务分析层。基于清洗好的数据，按不同维度做统计和挖掘，比如各专业就业率、平均薪资区间、热门行业分布、城市流向、岗位需求趋势、学历要求占比等。这一层是系统的核心价值所在。

第三层是决策辅助层。把分析出的结论变成直观的可视化报表，最好还能带一点“结论感”，比如某个专业近三年就业率持续走低、互联网行业岗位需求在上升，这些不是简单画图，而是帮助用户理解数据背后的信息。

你在这个项目里要重点展示的能力，不是“我用了 Django”或者“我会连数据库”，而是“我怎么样把一堆原始数据变成了对用户有实际价值的结论”。这个逻辑链条顺畅了，答辩分数不会低。

1.3 技术栈搭配的底层逻辑

这个项目的技术栈，我推荐的组合是这样的：

• 语言：Python 3.8+
• Web框架：Django 4.x
• 数据库：SQLite（开发期）或 MySQL（部署期）
• 数据处理：Pandas、NumPy
• 可视化：Pyecharts（生成ECharts图表配置）或原生ECharts
• 数据采集：Requests + BeautifulSoup，或用 Scrapy
• 前端模板渲染：Django自带模板 + Bootstrap（或Vue做前后端分离）
• 认证：Django自带的用户系统

这套组合好在哪里？好就好在每一环都有现成的、稳定的库在支撑，而且是社区里被反复验证过的方案。比如你想把数据库里的数据按行业做一个分组聚合，Pandas一行groupby就搞定了；想生成一张交互式地图，Pyecharts给你准备好配置选项，前端交给ECharts渲染。

同等功能如果用Java来做，不是不行，但数据处理这块你得写更多代码。用Python做这个题，是因为它的分析生态太成熟了，你想查某个数据清洗方法，搜索一下全是同类的实践，求助也方便。

2. 数据从哪来、怎么变成能用的数据：采集与预处理完整方案

2.1 就业数据的三个可靠来源

很多人的项目卡在第一步——没有数据。比起上来就写爬虫，我建议你先明确数据来源，我实际用过且靠谱的来源有三种。

第一种是公开统计报告。每年各个高校都会公开发布毕业生就业质量报告，里面包含毕业生规模、分专业就业率、就业地区分布、行业分布、薪资水平等很多字段，数据非常规范，安全稳定。这类数据通常以PDF或网页形式存在，你可以手动整理为Excel，也可以写一小段脚本提取关键表格。

第二种是招聘平台的公开岗位数据。这类数据用来补充“岗位需求、技能要求、薪资水平、城市分布”这些维度，比传统的就业统计报告更能体现市场端的情况。采集时要注意合规性，控制请求频率，只抓取公开可浏览的列表页和详情页字段，不采集任何个人身份信息，也不用账号登录后的敏感接口。数据仅用于课程设计和学习研究，这个性质要在文档里写清楚。

第三种是问卷数据。如果你想做的是某个学校、某个专业的定制化分析，用问卷在毕业生群体里做一份匿名调研会非常有说服力。设计几个关键问题：是否就业、签约月薪、工作城市、行业类型、岗位方向、是否专业对口。只要收集到一两百份有效样本，整个系统就有了“一手数据”，答辩时这是很加分的。

实操建议：如果做毕业设计级别的系统，至少准备两个数据集。一个用官方公开统计数据，侧重展示宏观就业趋势；一个用招聘平台岗位明细数据，侧重展示岗位、薪资、行业等微观结构。两套数据在系统里分开管理，又能通过行业或城市字段做交叉分析，整个系统立刻就立体了。

2.2 字段设计与数据清洗：脏数据会毁掉所有分析

数据拿回来之后，第一步是设计统一的字段结构。我做岗位数据时，常用的一组核心字段是这样的：

清洗里面坑最多的是薪资字段。原始页面上写的是“8千-1.2万”，要是直接存成字符串，后面的所有薪资分析都做不了。我的做法是写一段解析函数，把“万”“千”这些单位全部换算成以“元”为单位的数字，然后拆出下限和上限。这个处理必须放在入库前，否则一旦数据进了库再回头清理，工作量会翻倍。

行业归类也是一个重点。招聘网站的行业分类特别碎，比如“计算机软件”“互联网服务”“网络游戏”其实在产品维度上都属于技术互联网大类。如果不做归一化，饼图会被切成几十个小扇区，完全没有可读性。我实际使用中会维护一张映射表，把相近的行业映射到十几到二十个大类，低成本高收益。

再一个容易被忽视的点是城市等级。如果你想分析“一线城市薪资是不是真的更高”，那就不能把每个城市当独立变量，要把城市映射为一线、新一线、二线、三线及以下。这一层可以自己维护一份城市等级表，也可以按城市GDP和人口规模去做聚类，但毕设项目里手写映射表就够了。

2.3 数据清洗的一小段参考代码

下面是我实际处理薪资字段时经常用的一个函数，逻辑很简单，但能处理很多格式混乱的情况。这里只放核心片段，方便你照着自己项目里的情况去改。

import re import pandas as pd def parse_salary(salary_str): if not isinstance(salary_str, str): return None, None # 统一替换中英文符号 salary_str = salary_str.replace('，', ',').replace('—', '-').replace('－', '-') nums = re.findall(r'[\d.]+', salary_str) if not nums: return None, None if '万' in salary_str: factor = 10000 elif '千' in salary_str: factor = 1000 else: factor = 1000 # 默认按“元/月”处理 if '-' in salary_str: min_sal = float(nums[0]) * factor max_sal = float(nums[1]) * factor if len(nums) > 1 else min_sal elif '以上' in salary_str or '起' in salary_str: min_sal = float(nums[0]) * factor max_sal = min_sal * 2 # 保守估计 else: min_sal = float(nums[0]) * factor max_sal = float(nums[0]) * factor return int(min_sal), int(max_sal) # 批量处理示例 df['salary_min'] = df['salary_text'].apply(lambda x: parse_salary(x)[0]) df['salary_max'] = df['salary_text'].apply(lambda x: parse_salary(x)[1])

注意，上面这段代码不是万能的，比如“面议”这种值需要单独处理，直接过滤掉或者标记为缺失。我当时处理的时候还专门加了一列表示薪资是否有效，后续做统计时只保留有效薪资的记录。

2.4 合规与伦理：爬虫数据必须守住底线

这一节写给所有用爬虫采集数据的同学。你采集的是招聘平台公开页面上的职位信息，不是用户个人隐私。做的时候一定要记住几条边界：只用公开可见的数据；代码里控制请求频率，比如每次请求间隔3到5秒；不要在采集过程中尝试登录用户后台；不要采集个人信息，包括姓名、联系方式、身份证号等；在论文或报告里注明“数据用于非商业学习和研究”。这不是应付答辩用的漂亮话，而是实际操作中保护自己的关键底线。

3. 系统架构设计与核心实现：把完整项目一步步搭起来

3.1 Django项目结构与基础配置

假设你已经用Django创建了项目，名字可以叫employment_analysis。核心结构大概是这样的：

employment_analysis/ ├── manage.py ├── employment/ │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── users/ # 用户登录与权限 │ ├── data_sources/ # 原始数据管理、导入导出 │ ├── analysis/ # 数据分析与聚合服务 │ └── report/ # 图表展示与报表页面 ├── static/ # 静态文件 ├── templates/ # 模板文件 └── data/ # 原始数据文件目录

我习惯用apps子目录把不同模块分开，而不是把全部应用都平铺在根目录。这样做有什么好处？当你的系统有用户管理、数据管理、分析统计、报表展示这些模块的时候，按业务边界切分会让你在开发后期省很多力气。

settings.py里头的几项要特别注意：

INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'apps.users', 'apps.data_sources', 'apps.analysis', 'apps.report', ] DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': BASE_DIR / 'data' / 'db.sqlite3', } } LANGUAGE_CODE = 'zh-hans' TIME_ZONE = 'Asia/Shanghai' USE_TZ = True

SQLite在开发期足够用，数据量撑到几万条没有压力。如果要换成MySQL，只需要改DATABASES配置，模型层不用动，这就是ORM带来的便利。

3.2 核心模型设计

一个就业数据分析系统的数据模型，常见的核心表有这几张：

• JobInfo：岗位数据表，存招聘平台采集到的岗位明细。
• EduStatistic：统计报告表，存官方就业报告里的宏观统计数据。
• UserProfile：扩展用户表，关联Django自带User。
• AnalysisResult：分析结果缓存表，存跑批算好的聚合结果，避免每次打开页面都重复计算。

JobInfo的模型可以参照这个思路设计：

from django.db import models class JobInfo(models.Model): job_id = models.CharField(max_length=50, unique=True, verbose_name='岗位ID') job_name = models.CharField(max_length=200, verbose_name='岗位名称') company_name = models.CharField(max_length=200, verbose_name='公司名称') salary_min = models.IntegerField(null=True, blank=True, verbose_name='薪资下限') salary_max = models.IntegerField(null=True, blank=True, verbose_name='薪资上限') industry = models.CharField(max_length=100, verbose_name='行业分类') city = models.CharField(max_length=50, verbose_name='城市') city_tier = models.CharField(max_length=20, blank=True, verbose_name='城市等级') edu_req = models.CharField(max_length=50, verbose_name='学历要求') job_category = models.CharField(max_length=50, default='其他', verbose_name='岗位类别') publish_date = models.DateField(null=True, blank=True, verbose_name='发布日期') class Meta: db_table = 'job_info' indexes = [ models.Index(fields=['industry']), models.Index(fields=['city']), models.Index(fields=['job_category']), ]

数据库索引在设计阶段就要想好。岗位数据的查询绝大多数是按行业、城市、岗位类别这几个维度去做过滤和聚合的，索引加在上面能明显提升查询速度。虽然数据量小的时候感觉不出来，但答辩被问到性能优化时，你能说出来“我在哪些字段上建了索引、为什么”，这就是实际经验的体现。

3.3 图表接口与前端渲染：用Pyecharts还是原生ECharts

可视化是这类系统的门面。我推荐的方案是Pyecharts + ECharts。Pyecharts本质上是一个Python库，负责把图表配置生成JSON格式的option，前端再用ECharts渲染。这样做的好处是，你可以直接用Python做数据聚合，然后把聚合结果传给图表对象，再序列化给前端，不用在JavaScript里再写一遍数据处理逻辑。

举个最简单的例子，统计各行业岗位数量分布并生成柱状图，视图层大致是这样：

import json from django.http import JsonResponse from django.views import View from apps.data_sources.models import JobInfo from pyecharts.options import InitOpts from pyecharts.charts import Bar class IndustryBarView(View): def get(self, request): # 使用Django ORM聚合，也可以先取回DataFrame再聚合 from django.db.models import Count qs = JobInfo.objects.values('industry').annotate(count=Count('id')).order_by('-count')[:10] industries = [item['industry'] for item in qs] counts = [item['count'] for item in qs] bar = Bar(init_opts=InitOpts(width='800px', height='500px')) bar.add_xaxis(industries) bar.add_yaxis('岗位数量', counts) bar.set_global_opts(title_opts={'text': '行业岗位数量Top10'}) return JsonResponse({'code': 200, 'data': json.loads(bar.dump_options())})

前端模板里要做的就简单了，定义一个div容器，然后从接口拿配置，调用ECharts渲染：

fetch('/api/charts/industry-bar/') .then(res => res.json()) .then(result => { if (result.code === 200) { const chart = echarts.init(document.getElementById('industryChart')); chart.setOption(result.data); } });

这种前后端通过JSON标准格式交互的方式，比起直接在模板里生成一段HTML片段要干净很多，而且更接近真实企业开发的做法。答辩的时候把这个设计讲出来，会显得你确实懂前后端协作，而不是只把示例代码复制了一遍。

3.4 图表方案选型：不要让Pyecharts版本坑到你

Pyecharts的使用中有个需要特别注意的地方：版本兼容性。v1.x和v0.x的API有过一次大换血，网上资料有不少是新旧混着讲的。如果你的项目里一直报一些莫名其妙的参数错误，先看一下安装的是不是最新版本，再检查引用的API是不是对应版本。我用的时候是直接固定版本安装的：

pip install pyecharts==2.0.7

另外，Pyecharts生成的图表默认是HTML模式，但如果你要做数据接口，记得用dump_options()拿到JSON配置，就跟我上面的示例一样。这是我在实际开发中踩过坑之后养成的习惯。

3.5 完整功能演示流程设计

系统做完了，演示顺序特别重要。我的建议是按照一个故事线来走：

先进后台，展示数据管理模块。打开岗位数据列表，展示采集到的数据总量，顺便让老师看到一个具体岗位记录的字段内容。然后打开统计报告数据页，说明这部分数据来自官方公开报告。

第二步切换到图表分析页。先展示一个总览大屏式的页面，上面有四五个核心卡片：总岗位数、平均薪资、最热门行业、就业率变化趋势。然后是行业分布饼图、城市薪资箱线图、学历要求占比图、岗位类别柱状图。

第三步展示一个筛选联动交互。比如页面上有一个“选择专业方向”的下拉框，选了之后图表全部更新。这一交互直接用Django视图接收参数、重新聚合、返回新图表配置来实现。演示到这里，一套从数据到图表再到交互的闭环就完整了。

为了让演示数据稳定可信，建议正式演示时使用3000到5000条左右的数据。太多会拖慢加载，太少则图表过于稀疏。

4. 实操过程中最常踩的坑与排查实录

4.1 Django和Flask“同时用”的坑

这个坑几乎是这个题目特有的一种情况。有的同学看到题目写了“django-flask”，就把两个框架都装上，这里建一个Django应用，那里又起一个Flask服务，最后的局面是：项目里有两套配置文件、两套路由，依赖还互相冲突，最后连启动都费劲。

我的看法是：不管题目写成什么样，交付的时候你要么只用Django，要么只用Flask。如果你确实想体现“Python生态很丰富”，完全可以用Django写主系统，再单独用Scrapy做数据采集服务。这两个是不同层面的东西，不会冲突，还能讲出一个完整的采集+分析+展示链路。

如果你已经装混了，可以先检查虚拟环境里的依赖列表，把不需要的框架卸载掉，然后统一用Django的命令来管理项目。如果你项目里已经写了不少Flask路由，那反过来也可以，只是需要自己补上后台管理这块功能。关键是别把两套东西放在一个进程里。

4.2 中文乱码、数据库连接与时区问题的排查

中文乱码这个问题，在Windows本地开发时特别常见。如果用的是MySQL，创建数据库时字符集就要定好：

CREATE DATABASE employment_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

如果已经建好了库，也要把表和连接的字符集统一改成utf8mb4。Django的DATABASES配置里同样可以加上字符集设置：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'employment_db', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }

时区问题也是一个容易疏忽的地方。Django默认的TIME_ZONE是UTC，如果你的程序里要显示“发布日期”和“更新时间”，不调整的话显示出来的时间会和你本地时间差8个小时。settings里明确设置TIME_ZONE和USE_TZ后，大部分问题都能解决。

还有一个细节：如果你在Pandas里处理时间字段，读出来的字符串可能带时区后缀，best practice是先统一转成datetime类型再存库，避免Django的DateField接收字符串时解析出错。

4.3 图表加载慢、数据接口报错：数据处理与序列化的坑

这类项目最常见的运行时错误，几乎都集中在“数据查询出来之后没法转JSON”这一个环节。比如ORM查询出的Decimal类型不能被json.dumps直接序列化；Pandas算出来的NaN在转JSON时也会变成非法值；还有datetime类型也是序列化的重灾区。

我的通用解决办法是：在视图中写一个统一的response封装，处理所有特殊类型：

import json from django.core.serializers.json import DjangoJSONEncoder from django.http import JsonResponse import numpy as np def make_response(data=None, msg='success', code=200): return JsonResponse({ 'code': code, 'msg': msg, 'data': data, }, encoder=DjangoJSONEncoder) # 遇到NaN时，在转dict之前先做填充 def clean_nan(value): if isinstance(value, (float, np.float64)) and (value != value): # NaN判断 return 0 if isinstance(value, dict): return {k: clean_nan(v) for k, v in value.items()} if isinstance(value, (list, tuple)): return [clean_nan(v) for v in value] return value

DjangoJSONEncoder能帮你解决大部分日期和Decimal的序列化问题，NaN需要自己处理。这个我在项目里吃过大亏，第一次做图表接口的时候，数据里因为有个NaN，前端ECharts直接报错不渲染，排查了整整一个小时才发现是序列化问题。

4.4 部署与演示环境问题

毕业设计阶段，我不太建议同学一上来就搞Docker和Nginx那套，太重了。最简单可靠的演示方案是本地运行开发服务器，或者部署到一台云服务器上，用runserver做临时演示。

部署时最容易翻车的是环境不一致。我见过不少同学在自己电脑上跑得好好的，换一台电脑就起不来了，原因是依赖没有固定版本。所以项目里一定得有requirements.txt，并且写清楚Python版本。

pip freeze > requirements.txt

换机器、换环境之后，安装依赖的时候也要用虚拟环境隔离，不然全局环境的包冲突会让你头大：

python -m venv venv source venv/bin/activate # Windows下是 venv\Scripts\activate pip install -r requirements.txt python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runserver 0.0.0.0:8000

注意runserver只是开发用途，如果被问到生产环境怎么部署，你要能答出用Gunicorn+Nginx+MySQL这套常规组合。答得出来是一回事，但答辩现场不需要你真去折腾生产环境。

4.5 答辩高频问题速查表

我整理了一些这类项目答辩时大概率会被问到的题目，提前准备，心里不慌：

5. 从“能演示”到“有亮点”：扩展方向与我的实操体会

5.1 三个不复杂的扩展方向

如果你做完基础版本还有余力，想在答辩时多一点差异化表现，我推荐这三个不太复杂、但很出效果的扩展方向。

第一个是薪资预测模型。用线性回归，根据学历、城市等级、行业、岗位类别这些特征预测岗位薪资区间。数据量不需要太大，几百条有效记录就能训练一个显示效果还不错的模型。答辩的时候把这个模块展示出来，再讲一句“这是用特征工程加回归模型做的预估”，整个系统的分析深度一下子就上去了。

第二个是岗位需求词云。从岗位名称和岗位描述里做分词，统计高频词，渲染成词云图。比如“Python”“数据库”“算法”“React”这类关键词能直观反映市场主流技能需求。词云图视觉冲击力很强，是演示时的加分项。

第三个是专业岗位推荐。根据用户的专业类别，匹配岗位数据里对应的岗位方向，做一个简单的推荐页。这个功能在模型上不用做得很复杂，基于标签匹配就能实现，但产品感很强，符合“系统”的定位。

5.2 实际操作中的一些体会

做了这类项目，又看着别人做了很多次之后，我的感受很直接：数据清洗的工作量大概率超过你的预想。很多同学会低估脏数据带来的麻烦，觉得采集完就能直接分析。等你开始做的时候就会发现，光是把“薪资范围”从各种格式里拆出来、把行业映射成统一分类、筛掉明显异常值，就要占用项目里不少的时间。这不是坏事，这本身就是数据分析流程里最有价值的部分。

另外一个体会是，演示顺序决定了答辩效果。同样的系统，漫无目的地从一个页面跳到另一个页面，和按照“数据接入—数据管理—分析挖掘—可视化报表—交互筛选”这条主线来走，是完全不同的体验。在正式演示前自己把流程完整走几遍，确保每一步点下去都能出现预期结果。最后准备一份备用数据，万一现场网络出现问题，也不至于整个流程断掉。

最后一条建议送给所有正在做这个项目的朋友：数据量控制在3000到5000条，图表控制在6到8张，把系统里的逻辑闭环打磨清楚，比硬堆一堆功能点要强太多。这个项目真正的价值不只是“完成毕业设计”，而是完整地体验一遍“从一堆原始数据里找出规律、再把它呈现给别人”的过程，这套能力放到真实的工作环境里一样能派上用场。