基于Python的招聘网站数据爬取与分析系统实战

简介：本资源是一份面向高校计算机专业本科生及数据分析初学者的课程报告型实践项目，聚焦招聘市场数据的自动化采集与智能分析，解决求职者信息获取低效、企业岗位需求洞察不足等现实问题。压缩包共3个文件（1.42MB），包含PDF版完整报告（含绪论、技术原理、系统设计与测试等7章）、Markdown格式实现指南（含环境配置与关键代码说明）以及HTML交互式可视化看板示例，便于读者理解架构逻辑、复现核心流程并快速验证分析结果。已有105人学习下载，内容覆盖Scrapy分布式爬虫构建、Pandas数据清洗、PySpark多维统计、XGBoost薪资预测模型与Apriori技能关联挖掘等关键技术环节，配套文档结构清晰、步骤详实，特别适合课程设计参考、毕业设计选题拓展或数据分析实战入门。 我是一个特别喜欢研究数据的人，尤其是那种“逛招聘网站像看市场行情”的感觉。去年秋招那阵，我一边刷岗位一边觉得一个个点开看太蠢了，就动手写了一套基于Python的招聘网站数据爬取与分析系统。这套东西能自动抓取岗位信息、清洗归类、分析薪资区间、统计技能要求，最后直接生成可视化图表。这篇文章不聊虚的，把我从实战踩坑到完整实现的全过程整理出来，代码思路和关键步骤都会给到，适合有一定Python基础、想拿真实数据练手的人参考。

系统的核心逻辑其实很简单：模拟浏览器请求招聘网站的公开页面，从HTML里解析出岗位名称、公司、薪资、城市、经验要求、学历要求、技能标签字段，存入数据库，然后利用pandas做统计分析，pyecharts画图。整个过程拆开看，每一环都有值得抠的细节——比如请求头怎么伪装、解析规则怎么写才不容易挂、薪资字段怎么归一化处理、分析维度怎么选才能得出有价值的结论。说实话，这套系统做完，最大的收获不是代码量，而是彻底搞懂了“数据从哪来、怎么存、怎么用”的完整链路。

1. 项目整体设计思路与需求拆解

1.1 核心需求拆解

动手之前，先想清楚一个问题：你爬招聘网站到底是为了什么？我自己总结了两类需求。一类是求职者视角，想搞清楚某个城市、某个技术栈的岗位多不多、薪资大概什么水平、哪类公司招人多；另一类是行业分析视角，想通过岗位数量、薪资分布、技能要求的变化趋势，判断一个细分领域的热度。这两种需求对应的爬取策略和分析维度完全不一样。

我的目标是做一套个人可用的分析系统，所以颗粒度控制在“城市+关键词”级别。核心需求拆成四块：一是数据采集，从招聘网站搜索页抓取岗位列表，再进入详情页抓取完整JD；二是数据存储，把结构化字段存进MySQL，方便后续查询；三是数据处理，解决薪资格式不统一、岗位名称杂糅、技能词提取等脏数据问题；四是可视化分析，输出薪资分布图、城市岗位量对比、技能词云、经验要求占比图，直接回答“哪里机会多、钱给到多少、要什么技能”这三个问题。

需求拆解这块，我特别建议你把自己的目标写下来，避免做着做着变成“为了爬而爬”。我当时就是先列了十个问题，比如“上海Java开发平均薪资是多少”“拉勾的Python岗位和Boss直聘的Python岗位要求差异大吗”，后面所有代码都是围绕回答这些问题展开的。

1.2 系统整体架构与流程

系统的整体流程图我用文字描述一下：搜索关键词后，构造搜索页URL，发送请求拿到HTML；解析出岗位列表页里的详情链接和基础字段；完成列表页翻页循环后，进入详情页补充JD描述、技能标签、福利待遇字段；把解析结果交给异常过滤模块，过滤掉字段缺失的数据；做格式标准化后写入MySQL；最后通过pandas读取数据库，在Jupyter里做聚合分析并输出图表。

这个架构看起来简单，但有一个关键点容易被忽略——列表页和详情页的解析要分离。我一开始图省事，在列表页直接解析所有字段，结果发现有些网站的薪资信息是异步加载的，列表页拿不到；还有些网站的JD摘要和详情页正文不一致。后来老老实实做成两级采集，列表页拿索引，详情页拿全文，虽然请求量增加了，但数据质量明显上来了。

1.3 数据字段设计

设计字段是爬虫项目里最基础也最容易返工的一步。我的字段表结构如下：

• 岗位名称：string，即职位标题
• 公司名称：string
• 薪资范围：string，原始文本，例如“15-25K·14薪”，分析时再归一化拆解
• 城市/区域：string
• 经验要求：string，例如“3-5年”
• 学历要求：string
• 技能标签：string，逗号分隔，例如“Python,爬虫,数据分析”
• JD详情：text，用于后续关键词抽取
• 发布时间：datetime
• 来源链接：string，用于去重
• 抓取时间：datetime

字段设计的原则是“原始文本和解析字段并存”。比如薪资，我既保留“15-25K·14薪”这个原文，也会在后面清洗阶段生成薪资下限、薪资上限、平均月薪、薪资类型（年薪/月薪）这几个单独字段。这样做的好处是，万一后期想换个口径重新分析，原始数据还在，不用重新爬。

2. 爬虫核心实现与反爬应对细节

2.1 HTTP请求与请求头伪装

招聘网站的服务器会检查请求的User-Agent、Referer、Cookie等信息，如果看到像爬虫的请求，直接拒绝访问或返回验证码页面。我一开始用默认的requests库直接请求，返回状态码200，但页面内容是一段加密的JS，根本拿不到数据。这就是典型的反爬手段。

解决办法是构造一套完整的请求头，最关键的是User-Agent，尽量用真实浏览器的版本号，并且做成动态轮换。我准备了十几个常用的UA字符串，每次请求随机挑一个。Referer字段也很重要，要设置为对应网站的搜索页，否则部分站点会直接判非法来源。代码示例如下：

import random import requests UA_POOL = [ "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36" ] def get_headers(): return { "User-Agent": random.choice(UA_POOL), "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", "Referer": "https://www.example.com/jobs?query=python" }

这里有一点要提醒，UA轮换要配合session使用，保持同一会话内Cookie的一致性。我保留了一个requests.Session()对象，第一次访问搜索页时手动从响应里提取Cookie，后续请求自动携带。遇到需要登录才能查看完整内容的岗位详情，还需要在Cookie里加上登录后的认证信息，这个后面在2.4节展开讲。

2.2 请求频率控制与代理策略

招聘网站的验证码机制通常不会在第一次请求就触发，而是当你的请求频率超过一个阈值，或者短时间内连续访问大量不同岗位详情页时，才会弹出滑块验证。控制频率的核心思路是给每次请求加一个随机延时，避免固定间隔形成的规律。

我的延时策略是base_delay加随机抖动，base在1到3秒之间，抖动在0.5到1.5秒之间。实测下来，这个频率能保证一天只触发一次验证码，如果降到0.5秒固定间隔，半小时内就会触发滑块。代码方面可以用time.sleep实现，但为了更优雅，我写了一个简单的限速器类：

import time import random class RateLimiter: def __init__(self, min_interval=1.5, max_interval=3.0): self.min_interval = min_interval self.max_interval = max_interval self.last_request_time = 0 def wait(self): now = time.time() elapsed = now - self.last_request_time target = random.uniform(self.min_interval, self.max_interval) if elapsed < target: time.sleep(target - elapsed) self.last_request_time = time.time() limiter = RateLimiter() limiter.wait()

再往上就是代理策略。如果只是个人分析，几千条数据量，大多数情况下免费的代理就够用，但稳定性差，经常要用一个检测一堆。我搭建了一个小型代理池，用requests定期从几个免费代理列表网站抓取代理IP，然后异步验证可用性，存进Redis队列，每次请求从队列里弹出。为了控制成本，这个方案只在学校机房和实验室环境测试过，个人居家场景建议直接用高可用付费代理，价格不高但能省下大量维护时间。

关于代理有一句忠告：确保代理的出口地区和你要访问的网站地区一致，否则部分招聘网站会直接返回“当前城市暂无数据”，这个坑我踩过，一度以为是代码问题，排查了半天才发现是代理出口在境外导致的。

2.3 页面解析与数据提取

拿到HTML后，常用的解析方式是BeautifulSoup配合解析器lxml。岗位列表页的结构通常是两层div列表，每项包含岗位链接、岗位名称、公司、薪资等。我会先用CSS选择器定位到列表容器，再逐项提取字段。

以某主流招聘网站为例，列表页的岗位名称在“class=job-title”的span标签里，详情链接在父级a标签的href属性中。提取代码大致如下：

from bs4 import BeautifulSoup def parse_list_page(html, base_url): soup = BeautifulSoup(html, "lxml") result = [] for item in soup.select(".job-list-item"): title_tag = item.select_one(".job-title") company_tag = item.select_one(".company-name") salary_tag = item.select_one(".salary") if not title_tag or not company_tag: continue link = item.get("href") if not link.startswith("http"): link = base_url + link result.append({ "job_title": title_tag.get_text(strip=True), "company": company_tag.get_text(strip=True), "salary_text": salary_tag.get_text(strip=True), "detail_url": link }) return result

解析规则的关键是找到稳定、唯一的CSS选择器。实际操作中我习惯先打开开发者工具，在Elements面板里定位目标字段，把class名复制下来，再用pytest写一个单元测试，确保每个字段至少能解析出一条样本数据。如果class名带了动态变化的hash值，就要往父级找更稳定的class，或者利用文本内容做正则匹配。

正则表达式在解析薪资、经验年限、学历要求时非常好用。比如从“15-25K·14薪”中提取薪资下限和上限：

import re def parse_salary(salary_text): # 示例输入 "15-25K·14薪" 或 "10-15K" 或 "2-4万·13薪" pattern = r"(\d+(?:\.\d+)?)[-~至](\d+(?:\.\d+)?)\s*([Kk万])" match = re.search(pattern, salary_text) if not match: return None, None low, high, unit = match.groups() low, high = float(low), float(high) if unit == "万": low *= 10 high *= 10 return low, high

这个函数会把“万”为单位的薪资统一换算成K，为后续分析铺平道路。正则测试不能省，我碰到过一个极端案例：“面议”两个字直接匹配不到，最终在清洗流程做特殊处理。

2.4 动态加载页面与登录态问题

有些招聘网站的岗位列表不是一次性全部渲染完成，而是你滚动到页面底部时通过Ajax接口请求下一页数据。这种情况下直接解析HTML只能拿到头几页数据。处理方式有两种：一是找到XHR接口地址，模拟Ajax请求直接获取JSON数据；二是用Selenium或Playwright驱动真实浏览器，等待JS渲染完成后解析DOM。

我在项目中两种方法都试验了。Ajax接口的方式效率高、请求量少、返回结构清晰，但有时接口的请求头里包含了一个动态生成的sign参数，需要通过JS计算，非常麻烦。Selenium方案虽然笨重，但胜在稳定，几乎不需要维护解析逻辑。我的建议是：如果目标网站有移动端页面，优先看移动端的XHR接口，很多网站的移动端接口反爬力度远低于PC端。但要注意，移动端返回的字段可能更精简，比如JD正文可能不完整，需要PC端详情页补充。

登录态这个问题也逃不掉。不少招聘网站的详情页会把完整JD隐藏起来，只展示前50个字，要求登录才能查看。我的做法是手动登录一次，通过浏览器开发者工具把Cookie复制出来，写进配置文件中。为了防止Cookie过期，使用前先判断是否失效，如果失效就人工更新。个人项目可以接受这种半自动流程，没必要写全套的自动登录和验证码识别，投入产出比太差。

3. 数据清洗与存储

3.1 数据清洗流程与异常处理

爬下来的数据就是原始数据，必须先过一遍清洗。我用的是pandas库，清洗流程分四步：格式统一、字段拆分、异常过滤、空值填补。

格式统一很关键。比如城市字段，“北京”后面可能带“·朝阳区”，岗位名称里可能有各种后缀，公司规模有的写“1000-9999人”，有的写“千人以上”，这类文本要尽量归一到标准格式。我的做法是维护一个映射表，把常见的异写映射到标准值。

字段拆分主要针对薪资，把“15-25K·14薪”拆分成salary_low、salary_high、salary_avg、salary_month_count四个字段。这里要额外注意“年薪”情况，比如“30-50万·24薪”，25万乘以12个月得到月薪范围再除以1000得到K单位值。

异常过滤处理两类情况：一是字段缺失或明显错乱，比如城市是None或空字符串；二是薪资范围下限大于上限，这种多半是解析正则产生了错误匹配。空值填补不能瞎填，对于缺失的薪资采用全数据集的中位数填补，并在结果表里标记是否填补过，方便后续分析时排除。

import pandas as pd import numpy as np def clean_data(df): # 去掉关键字段为空的行 df = df.dropna(subset=["job_title", "company"]) # 薪资文本转结构化字段 df[["salary_low", "salary_high"]] = df["salary_text"].apply( lambda x: pd.Series(parse_salary(x)) ) df["salary_avg"] = (df["salary_low"] + df["salary_high"]) / 2 # 过滤无效薪资 df = df[df["salary_low"].notna()] df = df[df["salary_low"] <= df["salary_high"]] # 城市字段按实际城市名取第一位 df["city"] = df["city"].str.split("·").str[0] return df

清洗这块最容易忽略的是编码问题。HTML页面声称是UTF-8，但实际可能包含GBK编码的内容，解析出来是乱码。处理方式是在requests的response对象上显式指定编码：

response.encoding = response.apparent_encoding

这个设置能解决90%的乱码问题。剩下的10%就需要在清洗阶段用正则去替换常见的乱码字符串了。

3.2 数据存储与增量更新策略

存储方案我选了MySQL，原因很简单：有事务、支持SQL聚合、方便连接BI工具。建表语句跟字段设计一一对应。为了控制数据库体积，文本型字段统一用VARCHAR(3000)存储JD正文，索引设在来源链接上，去重时直接用这个字段做唯一性约束。

写入数据库用pandas的to_sql方法，replace模式会造成数据覆盖，不适合持续采集，所以我采用“先查询已有链接，再插入新数据”的增量模式。代码示例：

from sqlalchemy import create_engine engine = create_engine("mysql+pymysql://user:pass@localhost:3306/job_analysis?charset=utf8mb4") def insert_new_data(df): existing_links = pd.read_sql("SELECT source_url FROM jobs", engine)["source_url"].tolist() new_df = df[~df["source_url"].isin(existing_links)] if not new_df.empty: new_df.to_sql("jobs", engine, if_exists="append", index=False) return len(new_df)

增量更新为后续做周期性趋势分析打好了基础。比如每个月跑一次爬虫，积累三个月数据，就能看到同一岗位的薪资中位数是否在变化，这是单纯一次性爬虫做不到的深度价值。

4. 岗位分析模块实现

4.1 薪资分析：不同维度的对比

薪资分析是我整个系统里产出最直观的部分。拿到清洗好的数据集后，我优先做三个维度的对比：城市维度的平均薪资、不同经验年限的薪资梯度、不同技能关键词对应的薪资差异。

城市维度的计算逻辑是按城市分组，求salary_avg的中位数和分位数。因为薪资分布是比较典型的右偏分布，少数高薪岗位会拉高均值，用中位数更能代表普遍水平。分析结果用pyecharts画柱状图，坐标轴按薪资中位数降序排列，城市间差异一目了然。

经验年限的薪资分析需要先把文本拆成标准区间。比如“1-3年”对应low=1，high=3，“3-5年”对应low=3，high=5，然后按区间分组。这里要特别注意“经验不限”和“在校生/应届生”两类，单独归类，不要混进数值区间。

技能关键词与薪资的关联分析是我觉得最有挖掘价值的模块。把JD详情文本按“#”号分隔的技能标签提取出来，可以统计每个技能的岗位数量和平均薪资。我当时做了一个很简单的分析，发现同一时间段内，带“LLM”标签的岗位数量虽然少，但平均薪资比纯“Python”标签高出一截，这个信息对求职方向选择非常有参考意义。

4.2 技能关键词提取与岗位画像

技能标签的提取在招聘网站里通常有两种来源：一种是官网已经分好类的标签，比如“Python，爬虫，数据分析”，这种直接切分即可；另一种是隐藏在JD正文里的自然语言描述，需要自己抽取。

抽取操作使用关键词词典匹配最简单可控。我构建了一个Python技能词典，覆盖常见语言、框架、数据库、云平台关键词，然后对JD正文做词频统计。示例代码：

from collections import Counter SKILLS = ["Python", "Java", "C++", "Go", "MySQL", "Redis", "Docker", "K8s", "TensorFlow", "PyTorch", "Spark", "Hadoop"] def extract_skills(jd_text): found = [] for skill in SKILLS: if skill.lower() in jd_text.lower(): found.append(skill) return found

匹配方式用最简单的子串匹配就行，如果JD里写了“需要熟悉Python开发”就能识别出来。但要注意大小写问题，统一转小写后再匹配，同时避免误匹配，比如“MySQL”和“MyS”这类前缀重叠的词要优先处理长词。

技能画像的呈现方式是生成词云图。我用wordcloud库生成圆形的技能云图，大小表示岗位需求数量，颜色深浅表示平均薪资高低。这个可视化方案在很多技术分享里出现过，但真正自己跑一遍才能体会到，词云图在展示“最大共性”方面确实比表格有冲击力，只是要注意它会掩盖长尾技能，所以词云图只作为辅助，真正的分析还得看数据表格。

4.3 可视化图表设计

我的图表都是用pyecharts生成，它的好处是支持交互式图表，生成HTML文件后可以在浏览器里缩放、悬浮查看数值。常用的几种图表：

• 柱状图：城市岗位数量对比、Top20技能占比
• 箱线图：不同经验年限区间的薪资分布
• 饼图：学历要求占比
• 地图：岗位在全国各省份的分布密度
• 折线图：某岗位关键词的招聘热度随时间的变化

生成图表的核心代码不长，比如城市岗位数柱状图：

from pyecharts.charts import Bar from pyecharts import options as opts def plot_city_job_count(city_stats): bar = Bar() bar.add_xaxis(city_stats["city"].tolist()) bar.add_yaxis("岗位数量", city_stats["count"].tolist()) bar.set_global_opts(title_opts=opts.TitleOpts(title="城市岗位数量Top15"), xaxis_opts=opts.AxisOpts(axislabel_opts=opts.LabelOpts(rotate=-30))) bar.render("city_job_count.html")

箱线图在pyecharts里的参数稍微复杂一点，需要把每组数据拆成列表传入，但这个图非常推荐大家尝试，因为薪资分布的箱线图比单纯的均值柱状图信息量大多了，一组数据就能看出中位数、四分位距和离群点，对理解一个岗位的真实薪酬水平帮助很大。我跑完不同城市的Python岗位箱线图之后，明显感觉到某些城市薪资均值高但下限低，另一类城市薪资中位数低但下限高，中位数和均值给出的职业建议完全不同。

5. 常见问题盘点与实操避坑记录

5.1 高频问题速查表

以下是我在项目开发过程中遇到的真实问题，按出现频率排序，整理成一份速查表：

这份表格是我在项目途中边踩坑边记录的。发现问题后养成记录习惯，后面排查问题能省大量时间。新手遇到问题第一反应往往是怀疑自己代码写错了，但实际上请求被拦和页面结构变化占据了大半问题来源。

5.2 不得不提的避坑经验

第一坑：不要用固定Sleep间隔。我最初写法是每请求完一次强制sleep(2)，结果请求频率非常规律，短时间大量请求后直接被封了IP。后来改成RateLimiter类，用随机间隔模拟人类浏览节奏，情况好了很多。人类浏览网页的节奏是有随机性的，在3秒到6秒之间随机等待，比精确到每秒的固定等待要有效得多。

第二坑：合理使用Session和Cookie。我曾在请求列表页时手动携带Cookie，但详情页没带，结果部分岗位详情跳回到登录页，导致大量无效数据。后来把Session统一初始化一次，之后所有请求都走同一个Session，问题解决。Session维持的是服务器端会话，cookie在其生命周期内保持一致，这是模拟浏览器行为的正确方式。

第三坑：详情页请求量是列表页的十几倍。爬1000个岗位就要请求1000次详情页，如果频率控制好，大约需要2到3小时。这个时间成本要在设计时就考虑好，不要等到爬了一半才发现耗时太长。我实际的经验是，把任务拆成两步：先用一个脚本爬列表页并存入待抓取队列，再用另一个脚本从队列里读取详情链接去爬详情页，这样即使中途崩了，也只需要重跑详情页部分，不用重新请求列表页。

5.3 反爬升级的应对策略

招聘网站的反爬机制会不定期升级，很可能你昨天还在用的解析规则，今天就失效了。应对策略有三点：一是维护解析规则配置化，把选择器字符串放在一个dict里，不要写死在代码里，网站改版时只改配置不用动主逻辑；二是给爬虫加日志系统，记录每页请求的响应码、解析数量、异常信息，方便定位是请求被拦截还是解析规则挂了；三是定期检查数据完整性，突然发现某个字段全为空，大概率不是网站改版就是被反爬识别了。

不过这里要特别说清楚，爬虫的边界在于你只爬取公开数据且遵守目标网站的robots协议和用户条例。个人学习分析用途完全没问题，但如果要做商业用途或对网站造成访问压力，就需要先取得相应的数据使用许可。做技术分享也要注意这点，我写的代码都是基于公开页面信息的分析和学习，不涉及绕过登录验证等破解行为。

6. 扩展：系统性提升分析价值的三个方向

这套系统跑通后，可以继续往三个方向扩展。

第一是定时调度。用crontab或APScheduler每周末自动执行一次抓取任务，积累三个月后，你就能分析出岗位数量的环比变化、平均薪资的涨跌趋势。这个能力是单次爬虫做不到的，对判断行业热度很有参考价值。

第二是多渠道数据融合。招聘数据不只来自招聘网站，还可以结合企业官网的招聘频道、技术社区的热度数据、公开的薪酬报告等做交叉验证。反过来，不同渠道的数据格式差异很大，清洗环节的压力会上升，需要多做一层标准化映射。

第三是引入更细分的分析模型。比如用TF-IDF提取岗位JD中的关键要求，再按技能组合做关联分析，看哪些技能经常被同时要求。这类分析不需要特别高深的算法，但输出结果非常有说服力，对求职准备和职业规划都有现实帮助。

这套系统本身写成Python大概只需要几百行核心代码，但它真正迭代起来之后，分析的价值会远超代码量本身。我在跑完第一版分析的时候，看到自己规划的薪资数据图表从零到有呈现出来的瞬间，还是很有成就感的。做数据爬取与分析，前期大量的打磨在清洗规则和反爬策略上，真正到分析环节，利用pandas和pyecharts很快就能出自己的第一版报告。如果你也想动手做一套，建议先确定一个明确的分析问题，再倒推需要的字段和爬取范围，一次性做完，不要边走边改。最后再分享一个小技巧：数据的时效性极其关键，招聘数据的分析结论最好基于最近一个月的数据，太久之前的数据对职业决策的参考价值会明显下降。

本文还有配套的精品资源，点击获取