尧图网站建设 
简介这是一份面向高校计算机相关专业学生的Python毕业设计项目围绕招聘网站数据爬取与可视化展开。项目基于Pycharm与Python3.7开发采用Requests库完成岗位信息采集将数据存入MySQL后利用Echarts在前端呈现饼图、折线图、直方图等多种图表适合课程设计、毕业设计或Python爬虫与数据可视化入门进阶。压缩包共59个文件包含9个Python源码、12个pyc编译文件、2个SQL数据库脚本以及png、jpg等图表截图和演示PPT涵盖爬虫、数据分析、Web展示和答辩演示完整流程整体约10.34MB。目前已有919人学习下载。资源内含经过完整测试的源码、数据量更充足的MySQL数据脚本及演示文稿可直接运行查看多维度招聘岗位可视化分析效果便于在此基础上进行二次开发或完成毕业设计答辩展示。1. 招聘网站爬虫可视化这套毕设到底在做什么答辩前一周最慌的不是代码跑不通而是导师问一句“你的数据怎么证明是真的”。基于Python的招聘网站爬虫及可视化这个题目本质上是把“数据获取—清洗入库—接口输出—图表渲染”整条链路串成一个能演示、能答辩、能扩展的完整项目。它解决的是两个需求一是用爬虫拿到真实的招聘岗位数据二是用可视化的方式把数据讲清楚——哪个城市岗位多、哪些技能薪资高、薪资分布长什么样。这套方案适合两类人选毕设题目还没定的计算机/数据类专业学生以及想快速搭一套“爬虫可视化”练手项目的开发者。它的成本不高一台普通笔记本就能跑核心依赖也就是requests、SQLAlchemy、Flask、ECharts这几个耳熟能详的库。真正花时间的不是写代码而是对付反爬、清洗脏数据、把图表调到能看这三个环节。2. 动手前的选型requests、Selenium、存储与可视化框架怎么搭配2.1 先画数据链路爬虫不是“抓到页面”就结束一个招聘爬虫项目最忌讳的事情是爬虫写完了才发现数据没法用。我习惯把整个项目拆成四段采集、清洗、存储、展示。用一句话描述就是“从招聘网站列表页抓取岗位标题、公司名、薪资、城市、发布时间清洗后写进数据库后端接口把聚合结果给前端图表”。选型跟着链路走。采集层用requests还是Selenium取决于目标站点是服务端渲染还是前端渲染存储层用SQLite还是MySQL取决于数据量和你对答辩分数的要求展示层用ECharts还是原生图表取决于你想不想让页面“看起来很厉害”。先定数据链路再选技术栈能避免后面返工。2.2 采集层requests打底Selenium做兜底常见做法是优先用requestsBeautifulSoup。requests负责拿HTMLBeautifulSoup负责解析DOM节点。这个组合的优点是轻、快、好调试一个列表页几十毫秒就能抓完。问题在于目前不少招聘网站的列表数据已经改由前端接口返回你直接用requests拿HTML看到的可能是一个空壳页面。遇到这种情况第一选择不是立刻上Selenium而是打开浏览器的开发者工具在Network面板里找XHR请求。招聘网站的岗位数据往往有一个JSON接口直接请求这个接口返回结构化数据比解析HTML干净得多。Selenium的定位是兜底。当接口带复杂加密参数、或者页面必须渲染完才能拿到数据时再用Selenium调浏览器。代价是慢每个页面启动浏览器要几秒跑一千个页面要半小时起步而且内存占用大。我的原则是“能requests就别Selenium能找接口就别渲染页面”。2.3 存储层SQLAlchemy SQLite论文和答辩都够用多数毕设场景下数据量在几万条以内SQLite完全够用。它不需要单独装服务文件即数据库答辩现场拷走就能跑。为了保证代码可读性和可扩展性我会用SQLAlchemy做ORM而不是直接写原生SQL。选SQLAlchemy的理由有三个。第一建表、插入、查询都变成Python对象操作代码更好讲第二后面的可视化接口要按城市、薪资区间做聚合查询ORM的group_by写起来比手拼SQL省事第三如果答辩完想换成MySQL只需要改一行连接串不需要动业务代码。表结构上岗位信息表至少要有岗位名、公司名、薪资、城市、发布时间、学历要求这几个字段。2.4 展示层Flask提供数据接口ECharts负责把数据变好看可视化部分我推荐“Flask ECharts”的组合这是Python爬虫可视化项目里最常见的搭配也是答辩时最容易出效果的方式。Flask只做一件事提供几个JSON接口返回按城市统计的岗位数量、按薪资区间统计的岗位分布、Top10热门岗位这类聚合数据。ECharts负责渲染。它支持折线图、柱状图、地图、饼图而且API非常直观前端页面几十行JavaScript就能出图。如果你想让答辩现场更有冲击力可以再做一张“可视化大屏”——深色背景、多图表联动、自动轮播数据这种方案被大量课程设计采用因为它确实能在短时间内把项目档次拉高。3. 招聘数据爬取的最小可运行方案从列表页到入库3.1 构造请求头与页面解析先拿到第一页数据下面这套代码是完整可跑的目标站点换成常见的招聘网站列表页都能用。先写一个最基础的采集函数。import requests from bs4 import BeautifulSoup def fetch_job_list(url, headers): 请求列表页返回HTML文本 resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() # 状态码非200时主动抛异常 return resp.text def parse_job_list(html): 解析HTML提取岗位字段并清洗空白字符 soup BeautifulSoup(html, lxml) jobs [] for item in soup.select(.job-list-item): # 选择器按目标站点结构调整 title_node item.select_one(.job-name) company_node item.select_one(.company-name) salary_node item.select_one(.salary) if not title_node or not company_node: continue # 缺关键字段的直接跳过不污染数据 jobs.append({ title: title_node.text.strip(), company: company_node.text.strip(), salary: salary_node.text.strip(), }) return jobs这段代码里有两个关键参数。timeout10是请求超时时间防止某个页面卡住拖垮整轮爬取headers是请求头至少要带User-Agent否则很多站点会直接拒绝陌生请求。解析时用lxml作为BeautifulSoup的解析器比默认的html.parser快不少站点结构复杂时也不容易断。选择器部分我加了注释实际使用时用浏览器的开发者工具把对应class名替换进去即可。3.2 分页循环与请求间隔别让爬虫变成“攻击”列表页往往有几十页分页逻辑一般是URL里带页码参数。抓取时有两个必须控制的参数每页数据条数和请求间隔。import time def crawl_all_pages(base_url, total_pages, headers): 按页爬取并合并结果每页之间强制间隔 all_jobs [] for page in range(1, total_pages 1): url base_url f?page{page} try: html fetch_job_list(url, headers) all_jobs.extend(parse_job_list(html)) print(f第 {page} 页完成累计 {len(all_jobs)} 条) except Exception as exc: print(f第 {page} 页失败: {exc}) continue # 单页失败不中断整轮任务 time.sleep(2) # 请求间隔单位秒 return all_jobstime.sleep(2)是我推荐的保底间隔。有些招聘站点对请求频率非常敏感1秒以内连续请求会触发风控间隔拉到2秒虽然慢但胜在稳定。total_pages不要贪多毕设抓2000到5000条数据足够支撑可视化分析爬太多既浪费时间又增加被封风险。单页失败用continue跳过保证整个任务能跑完这个容错逻辑在答辩演示时很重要——demo跑一半中断很尴尬。3.3 用SQLAlchemy入库与去重数据落到数据库才叫“做完”抓到的数据不能只存在内存里否则进程一关就全没了。建表、插入、去重这一步用ORM来做。from sqlalchemy import create_engine, Column, String, Integer from sqlalchemy.orm import declarative_base, sessionmaker Base declarative_base() class Job(Base): __tablename__ jobs id Column(Integer, primary_keyTrue, autoincrementTrue) title Column(String(200)) company Column(String(200)) salary Column(String(50)) city Column(String(50)) publish_time Column(String(50)) engine create_engine(sqlite:///jobs.db) Base.metadata.create_all(engine) Session sessionmaker(bindengine) def save_jobs(job_list): 按标题公司城市去重后批量插入 session Session() added 0 for job in job_list: exists session.query(Job).filter_by( titlejob[title], companyjob[company], cityjob.get(city, ) ).first() if not exists: session.add(Job(**job)) added 1 session.commit() session.close() print(f新增 {added} 条跳过 {len(job_list) - added} 条重复)这段代码里的去重逻辑值得说明一下以“标题公司城市”作为唯一依据比单靠标题去重可靠得多。同一家公司可能长期挂着相似岗位不同分公司也同名加上城市字段能大幅降低误杀。批量插入比逐条插入快很多但要注意内存占用一万条以内完全没问题。入库后数据文件就是那个jobs.db答辩时把这个文件一起带上数据可复现性就有了。4. 招聘网站爬虫的五个踩坑现场反爬、乱码、空字段与脏数据4.1 现象爬了两页就被封IP第三页开始全是403这是最经典的翻车现场。原因是请求频率太快或者User-Agent是默认的Python-requests服务器一眼认出是爬虫。解决分三步走。第一请求头伪装完整一点只带一个User-Agent不够建议把Accept、Accept-Language、Referer一起带上。第二请求间隔调到3秒以上或者用随机间隔让访问节奏更像真人。第三加一个简单的重试机制遇到403时等5秒重试一次连续失败三次就放弃当前页。4.2 现象页面抓下来了中文全是乱码遇到乱码是因为requests拿到的页面编码和实际编码不一致。有些站点页面声明是UTF-8实际返回的是GBK直接.text解析就会出问题。解决方式是用resp.encoding resp.apparent_encoding让requests通过页面内容去推测真实编码再赋值给响应对象。如果还乱码就用resp.content.decode(gbk, errorsignore)强制按GBK解码。这个坑在招聘网站尤其常见因为不少站点的历史页面还保留着GBK编码。4.3 现象岗位字段解析出来全是空列表HTML结构看起来没问题选择器也没写错但解析结果就是空。原因大概率是页面内容由JavaScript动态渲染requests拿到的HTML里根本没有岗位节点。解决方法是回到开发者工具的Network面板找XHR接口直接请求JSON数据源字段更规整、解析更简单。如果接口加密复杂再退一步用Selenium渲染。判断依据很简单右键页面查看源代码如果源代码里能看到岗位信息就是服务端渲染requests能搞定看不到就是前端渲染找接口或用Selenium。4.4 现象薪资字段格式五花八门没法直接统计同一批数据里可能有“10k-15k”“8千-1.2万”“面议”三种薪资。这是招聘网站数据的常态也是很多人做可视化时卡住的地方。我的处理方式是单独写一个薪资清洗函数把“10k-15k”这类统一转成区间中值也就是12500“8千-1.2万”优先按中文单位换算遇到“面议”直接标记为None不参与图表统计。清洗完的数据单独存一列可视化接口只读清洗后的字段原始数据保留作对比。这个过程虽然枯燥但它直接决定后面的图表是否有说服力。4.5 现象SQLAlchemy报错提示字段不存在或类型不匹配原因是不同站点的字段命名不一致比如有的叫job_name有的叫positionName。写代码时图省事直接拼接字段入库时就炸了。解决方式是在爬虫和数据库之间加一层字段映射。定义统一的内部字段名爬虫解析完先做一层dict转换把站点的原始字段映射到内部字段再交给入库函数。这样即使换了一个招聘网站只需要改映射表不用改建表和入库逻辑。5. 把数据做成可视化大屏Flask接口与ECharts图表参数5.1 数据聚合查询图表要的数据不是明细是统计结果可视化接口不该直接返回明细数据而是返回聚合结果。按城市统计岗位数量、按薪资区间统计岗位占比、按岗位名统计Top10这三个查询基本能撑起一张完整的招聘数据分析看板。from sqlalchemy import func def get_city_stats(session): 按城市聚合岗位数量按数量降序 rows session.query(Job.city, func.count(Job.id)).group_by(Job.city).all() return [{name: city, value: count} for city, count in rows]func.count就是SQL里的COUNT配合group_by实现分组统计。这里有个细节值得注意聚合查询返回的是元组列表需要手本文还有配套的精品资源点击获取 招聘网站爬虫与数据可视化：从采集到展示的完整实战解析
简介这是一份面向高校计算机相关专业学生的Python毕业设计项目围绕招聘网站数据爬取与可视化展开。项目基于Pycharm与Python3.7开发采用Requests库完成岗位信息采集将数据存入MySQL后利用Echarts在前端呈现饼图、折线图、直方图等多种图表适合课程设计、毕业设计或Python爬虫与数据可视化入门进阶。压缩包共59个文件包含9个Python源码、12个pyc编译文件、2个SQL数据库脚本以及png、jpg等图表截图和演示PPT涵盖爬虫、数据分析、Web展示和答辩演示完整流程整体约10.34MB。目前已有919人学习下载。资源内含经过完整测试的源码、数据量更充足的MySQL数据脚本及演示文稿可直接运行查看多维度招聘岗位可视化分析效果便于在此基础上进行二次开发或完成毕业设计答辩展示。1. 招聘网站爬虫可视化这套毕设到底在做什么答辩前一周最慌的不是代码跑不通而是导师问一句“你的数据怎么证明是真的”。基于Python的招聘网站爬虫及可视化这个题目本质上是把“数据获取—清洗入库—接口输出—图表渲染”整条链路串成一个能演示、能答辩、能扩展的完整项目。它解决的是两个需求一是用爬虫拿到真实的招聘岗位数据二是用可视化的方式把数据讲清楚——哪个城市岗位多、哪些技能薪资高、薪资分布长什么样。这套方案适合两类人选毕设题目还没定的计算机/数据类专业学生以及想快速搭一套“爬虫可视化”练手项目的开发者。它的成本不高一台普通笔记本就能跑核心依赖也就是requests、SQLAlchemy、Flask、ECharts这几个耳熟能详的库。真正花时间的不是写代码而是对付反爬、清洗脏数据、把图表调到能看这三个环节。2. 动手前的选型requests、Selenium、存储与可视化框架怎么搭配2.1 先画数据链路爬虫不是“抓到页面”就结束一个招聘爬虫项目最忌讳的事情是爬虫写完了才发现数据没法用。我习惯把整个项目拆成四段采集、清洗、存储、展示。用一句话描述就是“从招聘网站列表页抓取岗位标题、公司名、薪资、城市、发布时间清洗后写进数据库后端接口把聚合结果给前端图表”。选型跟着链路走。采集层用requests还是Selenium取决于目标站点是服务端渲染还是前端渲染存储层用SQLite还是MySQL取决于数据量和你对答辩分数的要求展示层用ECharts还是原生图表取决于你想不想让页面“看起来很厉害”。先定数据链路再选技术栈能避免后面返工。2.2 采集层requests打底Selenium做兜底常见做法是优先用requestsBeautifulSoup。requests负责拿HTMLBeautifulSoup负责解析DOM节点。这个组合的优点是轻、快、好调试一个列表页几十毫秒就能抓完。问题在于目前不少招聘网站的列表数据已经改由前端接口返回你直接用requests拿HTML看到的可能是一个空壳页面。遇到这种情况第一选择不是立刻上Selenium而是打开浏览器的开发者工具在Network面板里找XHR请求。招聘网站的岗位数据往往有一个JSON接口直接请求这个接口返回结构化数据比解析HTML干净得多。Selenium的定位是兜底。当接口带复杂加密参数、或者页面必须渲染完才能拿到数据时再用Selenium调浏览器。代价是慢每个页面启动浏览器要几秒跑一千个页面要半小时起步而且内存占用大。我的原则是“能requests就别Selenium能找接口就别渲染页面”。2.3 存储层SQLAlchemy SQLite论文和答辩都够用多数毕设场景下数据量在几万条以内SQLite完全够用。它不需要单独装服务文件即数据库答辩现场拷走就能跑。为了保证代码可读性和可扩展性我会用SQLAlchemy做ORM而不是直接写原生SQL。选SQLAlchemy的理由有三个。第一建表、插入、查询都变成Python对象操作代码更好讲第二后面的可视化接口要按城市、薪资区间做聚合查询ORM的group_by写起来比手拼SQL省事第三如果答辩完想换成MySQL只需要改一行连接串不需要动业务代码。表结构上岗位信息表至少要有岗位名、公司名、薪资、城市、发布时间、学历要求这几个字段。2.4 展示层Flask提供数据接口ECharts负责把数据变好看可视化部分我推荐“Flask ECharts”的组合这是Python爬虫可视化项目里最常见的搭配也是答辩时最容易出效果的方式。Flask只做一件事提供几个JSON接口返回按城市统计的岗位数量、按薪资区间统计的岗位分布、Top10热门岗位这类聚合数据。ECharts负责渲染。它支持折线图、柱状图、地图、饼图而且API非常直观前端页面几十行JavaScript就能出图。如果你想让答辩现场更有冲击力可以再做一张“可视化大屏”——深色背景、多图表联动、自动轮播数据这种方案被大量课程设计采用因为它确实能在短时间内把项目档次拉高。3. 招聘数据爬取的最小可运行方案从列表页到入库3.1 构造请求头与页面解析先拿到第一页数据下面这套代码是完整可跑的目标站点换成常见的招聘网站列表页都能用。先写一个最基础的采集函数。import requests from bs4 import BeautifulSoup def fetch_job_list(url, headers): 请求列表页返回HTML文本 resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() # 状态码非200时主动抛异常 return resp.text def parse_job_list(html): 解析HTML提取岗位字段并清洗空白字符 soup BeautifulSoup(html, lxml) jobs [] for item in soup.select(.job-list-item): # 选择器按目标站点结构调整 title_node item.select_one(.job-name) company_node item.select_one(.company-name) salary_node item.select_one(.salary) if not title_node or not company_node: continue # 缺关键字段的直接跳过不污染数据 jobs.append({ title: title_node.text.strip(), company: company_node.text.strip(), salary: salary_node.text.strip(), }) return jobs这段代码里有两个关键参数。timeout10是请求超时时间防止某个页面卡住拖垮整轮爬取headers是请求头至少要带User-Agent否则很多站点会直接拒绝陌生请求。解析时用lxml作为BeautifulSoup的解析器比默认的html.parser快不少站点结构复杂时也不容易断。选择器部分我加了注释实际使用时用浏览器的开发者工具把对应class名替换进去即可。3.2 分页循环与请求间隔别让爬虫变成“攻击”列表页往往有几十页分页逻辑一般是URL里带页码参数。抓取时有两个必须控制的参数每页数据条数和请求间隔。import time def crawl_all_pages(base_url, total_pages, headers): 按页爬取并合并结果每页之间强制间隔 all_jobs [] for page in range(1, total_pages 1): url base_url f?page{page} try: html fetch_job_list(url, headers) all_jobs.extend(parse_job_list(html)) print(f第 {page} 页完成累计 {len(all_jobs)} 条) except Exception as exc: print(f第 {page} 页失败: {exc}) continue # 单页失败不中断整轮任务 time.sleep(2) # 请求间隔单位秒 return all_jobstime.sleep(2)是我推荐的保底间隔。有些招聘站点对请求频率非常敏感1秒以内连续请求会触发风控间隔拉到2秒虽然慢但胜在稳定。total_pages不要贪多毕设抓2000到5000条数据足够支撑可视化分析爬太多既浪费时间又增加被封风险。单页失败用continue跳过保证整个任务能跑完这个容错逻辑在答辩演示时很重要——demo跑一半中断很尴尬。3.3 用SQLAlchemy入库与去重数据落到数据库才叫“做完”抓到的数据不能只存在内存里否则进程一关就全没了。建表、插入、去重这一步用ORM来做。from sqlalchemy import create_engine, Column, String, Integer from sqlalchemy.orm import declarative_base, sessionmaker Base declarative_base() class Job(Base): __tablename__ jobs id Column(Integer, primary_keyTrue, autoincrementTrue) title Column(String(200)) company Column(String(200)) salary Column(String(50)) city Column(String(50)) publish_time Column(String(50)) engine create_engine(sqlite:///jobs.db) Base.metadata.create_all(engine) Session sessionmaker(bindengine) def save_jobs(job_list): 按标题公司城市去重后批量插入 session Session() added 0 for job in job_list: exists session.query(Job).filter_by( titlejob[title], companyjob[company], cityjob.get(city, ) ).first() if not exists: session.add(Job(**job)) added 1 session.commit() session.close() print(f新增 {added} 条跳过 {len(job_list) - added} 条重复)这段代码里的去重逻辑值得说明一下以“标题公司城市”作为唯一依据比单靠标题去重可靠得多。同一家公司可能长期挂着相似岗位不同分公司也同名加上城市字段能大幅降低误杀。批量插入比逐条插入快很多但要注意内存占用一万条以内完全没问题。入库后数据文件就是那个jobs.db答辩时把这个文件一起带上数据可复现性就有了。4. 招聘网站爬虫的五个踩坑现场反爬、乱码、空字段与脏数据4.1 现象爬了两页就被封IP第三页开始全是403这是最经典的翻车现场。原因是请求频率太快或者User-Agent是默认的Python-requests服务器一眼认出是爬虫。解决分三步走。第一请求头伪装完整一点只带一个User-Agent不够建议把Accept、Accept-Language、Referer一起带上。第二请求间隔调到3秒以上或者用随机间隔让访问节奏更像真人。第三加一个简单的重试机制遇到403时等5秒重试一次连续失败三次就放弃当前页。4.2 现象页面抓下来了中文全是乱码遇到乱码是因为requests拿到的页面编码和实际编码不一致。有些站点页面声明是UTF-8实际返回的是GBK直接.text解析就会出问题。解决方式是用resp.encoding resp.apparent_encoding让requests通过页面内容去推测真实编码再赋值给响应对象。如果还乱码就用resp.content.decode(gbk, errorsignore)强制按GBK解码。这个坑在招聘网站尤其常见因为不少站点的历史页面还保留着GBK编码。4.3 现象岗位字段解析出来全是空列表HTML结构看起来没问题选择器也没写错但解析结果就是空。原因大概率是页面内容由JavaScript动态渲染requests拿到的HTML里根本没有岗位节点。解决方法是回到开发者工具的Network面板找XHR接口直接请求JSON数据源字段更规整、解析更简单。如果接口加密复杂再退一步用Selenium渲染。判断依据很简单右键页面查看源代码如果源代码里能看到岗位信息就是服务端渲染requests能搞定看不到就是前端渲染找接口或用Selenium。4.4 现象薪资字段格式五花八门没法直接统计同一批数据里可能有“10k-15k”“8千-1.2万”“面议”三种薪资。这是招聘网站数据的常态也是很多人做可视化时卡住的地方。我的处理方式是单独写一个薪资清洗函数把“10k-15k”这类统一转成区间中值也就是12500“8千-1.2万”优先按中文单位换算遇到“面议”直接标记为None不参与图表统计。清洗完的数据单独存一列可视化接口只读清洗后的字段原始数据保留作对比。这个过程虽然枯燥但它直接决定后面的图表是否有说服力。4.5 现象SQLAlchemy报错提示字段不存在或类型不匹配原因是不同站点的字段命名不一致比如有的叫job_name有的叫positionName。写代码时图省事直接拼接字段入库时就炸了。解决方式是在爬虫和数据库之间加一层字段映射。定义统一的内部字段名爬虫解析完先做一层dict转换把站点的原始字段映射到内部字段再交给入库函数。这样即使换了一个招聘网站只需要改映射表不用改建表和入库逻辑。5. 把数据做成可视化大屏Flask接口与ECharts图表参数5.1 数据聚合查询图表要的数据不是明细是统计结果可视化接口不该直接返回明细数据而是返回聚合结果。按城市统计岗位数量、按薪资区间统计岗位占比、按岗位名统计Top10这三个查询基本能撑起一张完整的招聘数据分析看板。from sqlalchemy import func def get_city_stats(session): 按城市聚合岗位数量按数量降序 rows session.query(Job.city, func.count(Job.id)).group_by(Job.city).all() return [{name: city, value: count} for city, count in rows]func.count就是SQL里的COUNT配合group_by实现分组统计。这里有个细节值得注意聚合查询返回的是元组列表需要手本文还有配套的精品资源点击获取