企业官网建设流程全解析

简介：一份面向计算机专业学生及爬虫初学者的Python招聘岗位数据爬虫挖掘与可视化分析项目，可直接用于课程设计或期末大作业参考，完整覆盖数据采集、存储、分析与展示流程。压缩包共59个文件，约10.33MB，以Python源码为主（多个.py与.pyc），搭配SQL数据库文件、PPT演示文稿、HTML/CSS/JS可视化页面、PNG/JPG结果图及README说明，结构清晰便于按模块学习。项目内置腾讯招聘与51job招聘数据采集相关脚本、数据表及分析代码，配合演示文稿可快速理解爬虫设计思路、数据清洗与可视化方法。已有2083人学习下载，代码经调试可直接运行，适合需要完整项目实战或借鉴高分作业方案的学习者。

1. 招聘岗位爬虫挖掘与可视化：期末大作业里适用面最广的落地方向

期末课程设计最怕的不是没代码，而是代码跑不通、数据难看、答辩没话说。招聘岗位数据爬虫挖掘及可视化这个方向，恰好能把这三件事一次解决：它有明确的网页数据源，能完整走通“抓取—清洗—挖掘—可视化”这条链路，产出的图表又天生适合讲成答辩 PPT。这份资源就是按高分期末大作业的标准打包的：Python 爬虫源码、全量数据、数据挖掘与可视化脚本、PPT 文档都在里面。

适合正在赶课程设计的在校生，也适合想拿一个完整数据项目做作品集的入门开发者。照着复现一遍，从请求页面到最终图表都能自己跑通。提前说一个反直觉的结论：这套项目最容易翻车的不是反爬，而是编码、去重和图表离线加载这三处细枝末节。第五章会把这几条踩坑记录一条一条拆开讲。

2. 项目全景与运行准备：先看懂包结构，再决定从哪一步开始跑

2.1 包里都有什么：源码、数据、PPT 三段分离的好处

这类打包资源最忌讳一锅炖。把爬虫、分析和可视化拆成三个独立模块，意思是换关键词、改图表、补数据都不用推倒重来，这也是课程设计答辩时老师最愿意看到的工程化习惯。压缩包解压之后的目录结构大致是下面这个样子，文件名可能略有出入，但职责基本一致：

project/ ├── main.py # 一键执行入口 ├── spider/ │ └── job_spider.py # 爬虫抓取模块 ├── analysis/ │ └── analyze_jobs.py # 数据清洗与指标统计 ├── visual/ │ ├── charts.py # 可视化脚本 │ └── output/ # 生成的 HTML 图表 ├── data/ │ ├── jobs_raw.csv # 抓取后的原始数据 │ ├── jobs_clean.csv # 清洗后的分析数据 │ └── jobs.db # SQLite 中间库 └── docs/ └── 答辩PPT.pptx # 演示文档

spider 模块的输出是 data 目录下的原始 CSV 和 SQLite 数据库；analysis 模块读取原始数据，清洗后写出 jobs_clean.csv；visual 模块只认清洗后的文件，不碰原始数据。三个模块单向依赖，每一步的产出都是下一步的输入，所以单独调试任何一环都不影响其他环节。

拿到包之后不建议立刻双击 main.py。先用文本编辑器打开 data 目录下的原始数据，确认字段名和样例值，再打开 analysis 脚本看它做了哪些清洗动作。把这两件事做完，你对这个资源的理解就已经超过大部分只会跑通的同学。

2.2 环境搭建：Python 3.8+ 加七个依赖，版本锁死

我一直建议课程设计项目不要贪多，requests 加 BeautifulSoup 的组合足够应付招聘类页面的抓取，完全没必要上 Scrapy。后者虽然功能强，但配置文件、中间件、管道这些概念对期末作业来说学习成本高，出问题也不好排查。先建虚拟环境再装依赖，别直接往全局环境里塞。

python -m venv venv # Windows 激活命令：venv\Scripts\activate # macOS / Linux 激活命令：source venv/bin/activate pip install -r requirements.txt

这里给一个可用的依赖清单，按我的习惯会把版本锁死，免得半年后重新安装时某个库升级把代码搞挂：

requests==2.31.0 beautifulsoup4==4.12.2 lxml==4.9.3 pandas==2.0.3 pyecharts==2.0.3 jieba==0.42.1 wordcloud==1.9.2

逐个说明用途。requests 负责发 HTTP 请求，beautifulsoup4 做页面解析，lxml 是解析器引擎，比 Python 自带的 html.parser 容错性好、速度快；pandas 承担数据清洗和统计；pyecharts 负责生成交互式 HTML 图表；jieba 用于把岗位描述切词，配合 wordcloud 画词云。

注意：wordcloud 在新版 Python 上偶尔直接安装失败，因为对应版本的 wheel 没跟上。遇到这种情况不用硬磕，后面 4.3 我会给一个纯 pyecharts 的词云替代方案，效果差距不大。

2.3 执行链路：main.py 按什么顺序做四件事

main.py 的本质不是写逻辑，而是把三个模块按依赖顺序串起来。我见过不少同学喜欢把抓取、清洗、画图全部塞进一个文件，跑起来是省事，可一旦页面结构变了，改一处就牵动全身。这份资源的模块化拆分本来就是为了让你能单独替换某一段。

import subprocess import sys def main(): # 第 1 步：抓取，默认抓 5 页，关键词从命令行传入 subprocess.run( [sys.executable, "-m", "spider.job_spider", "--pages", "5"] ) # 第 2 步：清洗并输出统计字段 subprocess.run([sys.executable, "-m", "analysis.analyze_jobs"]) # 第 3 步：生成图表 subprocess.run([sys.executable, "-m", "visual.charts"]) print("三个模块执行完毕，请检查 visual/output 下的 HTML 文件") if __name__ == "__main__": main()

用 subprocess 而不是直接 import 函数，好处是模块之间没有强耦合，任何一步失败都不会让整个进程崩溃，日志也能清晰定位到具体模块。如果你想改成抓取不同关键词，按下面这种方式传参即可：

python main.py --keyword python --pages 10

--keyword 指定搜索词，--pages 控制翻页深度。这个参数设计很关键：演示阶段先抓两三页验证流程，确认没问题再加页数，别一上来就抓几十页。

提示：如果你只想复现数据分析和可视化部分，不想联网跑爬虫，完全可以直接跳过第 1 步。data 目录下已有的原始数据足够支撑第 2、3 步跑通。这是这套资源“能跑、能交、能讲”的关键设计。

3. 爬虫模块实战：解析策略、翻页节奏与数据落盘

3.1 页面分析：列表页和详情页各取什么字段

写爬虫之前先打开目标招聘网站，按 F12 切到开发者工具，找到岗位列表所在的 DOM 区域。列表页通常能拿到岗位名称、公司名称、薪资、城市、经验要求、学历要求、发布时间，这些字段已经够做大部分分析；详情页里才有职位描述和技能要求，是词云分析的数据来源。

抓取时我一般习惯先做一个小表格，把字段和对应位置记清楚，再动手写代码：

列表页的卡片结构一般是一个重复的 div 容器，里面包含上述字段。详情页则是一整个文章区域。列表页和详情页分开解析，是后面排查字段错位问题的基础。

3.2 用 Requests + BeautifulSoup 写岗位解析器

抓取请求的核心不是把代码写得多花哨，而是请求头、编码和超时这三件事。很多初学者只带一个 User-Agent 就发请求，遇到反爬强的站点直接返回 403。常见做法是带上 Accept 和 Referer，并统一通过 Session 保持会话。

import requests from bs4 import BeautifulSoup HEADERS = { "User-Agent": ( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/120.0.0.0 Safari/537.36" ), "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Referer": "https://example.com/", } SESSION = requests.Session() SESSION.headers.update(HEADERS) def fetch_page(keyword: str, page: int) -> str: url = "https://example.com/jobs" params = {"query": keyword, "page": page} resp = SESSION.get(url, params=params, timeout=10) resp.encoding = resp.apparent_encoding # 防止中文乱码 resp.raise_for_status() return resp.text

逻辑说明：把 headers 挂在 Session 上，后续所有请求都会自动携带，不用每个请求重复传。params 参数交给 requests 自动拼 URL，比字符串拼接优雅也更安全，特殊字符会被正确编码。timeout 设 10 秒是底线，避免某个请求卡死导致整个脚本挂住。

resp.apparent_encoding 是 requests 根据页面内容反推的编码，比默认的 ISO-8859-1 可靠。不过它需要额外读取一部分内容，对性能有一点影响，如果确认目标站是 UTF-8，也可以直接写死 resp.encoding = "utf-8"。

拿到 HTML 后解析：

def parse_jobs(html: str) -> list[dict]: soup = BeautifulSoup(html, "lxml") result = [] # 先定位到每一个岗位卡片，再在卡片内部取字段 for card in soup.select("div.job-card"): title_el = card.select_one(".job-title") company_el = card.select_one(".company-name") salary_el = card.select_one(".salary") city_el = card.select_one(".city") link_el = card.select_one("a.job-link") if not all([title_el, company_el, salary_el, city_el]): continue # 字段不全的卡片直接跳过，不塞垃圾数据 result.append({ "title": title_el.get_text(strip=True), "company": company_el.get_text(strip=True), "salary": salary_el.get_text(strip=True), "city": city_el.get_text(strip=True), "url": link_el.get("href", ""), }) return result

select 定位所有岗位卡片，select_one 在每个卡片内部找对应字段。先锁定卡片容器再取子元素，比直接从全局页面里 select_one 要稳得多，这也是后面避坑章节里字段错位问题的关键解法。

get_text(strip=True) 会去掉文本首尾空白和换行，避免存进数据库的字段带着一堆 \n 和空格。字段不全时用 continue 跳过，宁缺毋滥。

3.3 翻页控制与去重：请求频率、循环条件、断点续跑

翻页的过程中最容易出问题的不是页面解析，而是请求频率。我见过不少同学直接 for 循环秒抓几十页，结果抓一半 IP 被限流，整个脚本白跑。我一般会在每两次请求之间加一个 1 到 3 秒的随机停顿，并且用页内是否有数据作为循环停止条件，而不是盲目写死页数。

import random import time KEYWORD = "python" MAX_PAGES = 10 all_jobs = [] for page in range(1, MAX_PAGES + 1): html = fetch_page(KEYWORD, page) jobs = parse_jobs(html) if not jobs: print(f"第 {page} 页无数据，提前停止翻页") break all_jobs.extend(jobs) print(f"第 {page} 页抓取 {len(jobs)} 条，累计 {len(all_jobs)} 条") # 随机停顿，模拟真实浏览节奏 time.sleep(random.uniform(1, 3))

random.uniform(1, 3) 是随机浮点数，分布在 1 到 3 秒之间。随机间隔的意义在于让请求时间序列不那么规律，大幅降低被风控识别的概率。如果站点对频率特别敏感，可以把上限调整到 5 秒。

还有个容易忽略的点：翻页条件。有些站点到了最后一页会返回空列表，但也有些站点会重复返回最后一页的内容。判断条件应该用“本页是否解析出新数据”，而不是“是否达到设定页数”。

去重建议在抓取阶段就做，别等清洗时才做。岗位链接是天然的唯一键，同一个招聘信息通常不会出现两条一样的 URL。

seen_urls = set() unique_jobs = [] for job in all_jobs: url = job["url"] if url and url not in seen_urls: seen_urls.add(url) unique_jobs.append(job) print(f"去重后剩余 {len(unique_jobs)} 条")

seen_urls 是一个集合，判断 url 是否出现过的时间复杂度是 O(1)。如果重复数据已经进入了 CSV 或者数据库，也没关系，下一章清洗部分会讲基于 pandas 的第二道去重防线。

3.4 数据落盘：为什么我选了 SQLite 而不是 CSV

很多教程会把抓取结果直接写进 CSV，对于小数据量确实够用。但课程设计的完整流程应该是可重复的，今天抓一遍、明天再抓一遍，CSV 文件就会越堆越乱。SQLite 的 UNIQUE 约束能在数据库层直接挡掉重复记录，这是 CSV 做不到的。

import sqlite3 conn = sqlite3.connect("data/jobs.db") cursor = conn.cursor() cursor.execute(""" CREATE TABLE IF NOT EXISTS jobs ( url TEXT PRIMARY KEY, title TEXT, company TEXT, salary TEXT, city TEXT, experience TEXT, education TEXT, crawled_at TEXT DEFAULT (datetime('now', 'localtime')) ) """) cursor.executemany( """ INSERT OR IGNORE INTO jobs (url, title, company, salary, city, experience, education) VALUES (?, ?, ?, ?, ?, ?, ?) """, [ (job["url"], job["title"], job["company"], job["salary"], job["city"], job.get("experience", ""), job.get("education", "")) for job in unique_jobs ] ) conn.commit() conn.close()

url 设为主键，天然满足唯一性。INSERT OR IGNORE 的意思是遇到主键冲突就跳过这条记录，不会报错中断，这正是断点续跑需要的特性——中途失败了，重新运行一次脚本，已经存在的记录会被自动忽略。

crawled_at 字段用数据库默认值记录抓取时间，方便答辩时展示“这批数据是什么时候采集的”。executemany 批量插入比逐条 execute 快一个量级，几百条数据虽然感觉不明显，但养成习惯对以后处理更大规模的数据有帮助。

4. 数据挖掘与可视化：把原始岗位文本变成六张能讲的图

4.1 数据清洗：把“10-15K”拆成可计算的数值字段

原始数据里的薪资是字符串，比如“10-15K”“20-30K·14薪”“面议”。这种格式没法直接做均值、排序和分布统计，所以清洗的第一步是把薪资文本拆成 salary_low 和 salary_high 两个数值字段，再算一个中位数用于对比。

import pandas as pd import re raw = pd.read_csv("data/jobs_raw.csv", encoding="utf-8-sig") clean = raw.copy() def split_salary(s): if not isinstance(s, str) or "面议" in s: return None, None nums = re.findall(r"\d+", s) if len(nums) == 0: return None, None if len(nums) == 1: return int(nums[0]), int(nums[0]) return int(nums[0]), int(nums[1]) clean["salary_low"], clean["salary_high"] = zip( *clean["salary"].map(split_salary) ) # 计算月薪中位数，单位为 K clean["salary_mid"] = ( clean["salary_low"].fillna(0) + clean["salary_high"].fillna(0) ) / 2 # 把城市里的“上海-徐汇区”统一成“上海” clean["city"] = clean["city"].str.split("-").str[0] clean.to_csv("data/jobs_clean.csv", index=False, encoding="utf-8-sig") print(clean.shape)

逻辑说明：split_salary 用正则把字符串里所有数字抽出来。一个数字表示固定薪资，两个数字表示区间。“面议”或者其他非字符串值统一返回空值，后续分析时可以用 fillna(0) 或者直接过滤掉。

这里有个细节容易被忽略：读 CSV 时指定 encoding="utf-8-sig"，写入时也指定 utf-8-sig。utf-8-sig 会在文件开头写入 BOM 头，Windows 的 Excel 打开时才不会乱码。这是一个血泪教训，后面避坑章节会专门讲。

4.2 挖掘维度：城市、薪资、经验、技能四根分析主线

招聘数据最值得挖掘的四根主线，我归纳成下面这个表格。每一行对应答辩 PPT 里的一张图，也对应一个能讲清楚的分析结论：

答辩时最容易冷场的时刻是老师问“你为什么做这张图”。提前把每张图的结论写死，比如“北京岗位数量是成都的两倍，但薪资中位数差距不大”，比临场编理由强太多。这些结论都来自分析脚本输出，不是编出来的。

经验字段的清洗也要注意，“经验不限”和“在校生/应届生”属于低门槛类别，“5-10年”属于高门槛类别。分析时可以把经验字段先归一化成几个档位，否则饼图上会冒出十几个类别，看不出规律。

4.3 可视化输出：pyecharts 交互式 HTML 图表和答辩演示配合

可视化我推荐 pyecharts，原因有两个：图表是交互式的，鼠标悬停能看到具体数值，答辩演示效果好；其次是输出 HTML 文件，不会遇到 matplotlib 中文乱码这种陈年问题。需要强调一点，pyecharts 的 2.x 版本 API 是链式调用，网上随便搜到的老代码大多是 1.x 风格，直接复制大概率报错。

from pyecharts import options as opts from pyecharts.charts import Bar # 按城市统计岗位数量，取前 10 city_count = ( clean.groupby("city") .size() .sort_values(ascending=False) .head(10) ) bar = ( Bar( init_opts=opts.InitOpts( width="1000px", height="600px", page_title="招聘岗位城市分布 TOP10", ) ) .add_xaxis(city_count.index.tolist()) .add_yaxis("岗位数量", city_count.values.tolist()) .set_global_opts( title_opts=opts.TitleOpts(title="招聘岗位城市分布 TOP10"), xaxis_opts=opts.AxisOpts(axislabel_opts=opts.LabelOpts(rotate=30)), ) ) bar.render("visual/output/city_top10.html")

逻辑说明：groupby 之后按数量降序排列取前 10，再把 index 和 values 分别转成列表传给 pyecharts。x 轴标签旋转 30 度是为了避免城市名重叠。init_opts 里的宽度和高度直接控制生成图表的画布尺寸，答辩投屏之前先在自己电脑上打开看一眼，比例不对再调。

词云部分，如果 wordcloud 装好了就用常规写法，装不上就退一步用 pyecharts 内置的 WordCloud：

from pyecharts.charts import WordCloud # 假设 jieba 分词结果是一个 (词, 频次) 列表 words = [("Python", 120), ("数据分析", 98), ("机器学习", 76)] cloud = ( WordCloud() .add(series_name="技能词频", data_pair=words, word_size_range=[20, 100]) .set_global_opts(title_opts=opts.TitleOpts(title="岗位技能词频")) ) cloud.render("visual/output/skill_wordcloud.html")

word_size_range 控制词的大小范围，数值越大词越突出。data_pair 接收的是二元组列表，格式别传错。这里建议把 jieba 分词结果过滤掉“要求”“负责”“岗位”这类无意义词，否则词云里全是套话，看不出技术栈特征。

5. 常见问题与避坑：四条实测踩坑记录

5.1 CSV 中文乱码：Excel 打开全是问号，爬虫端和 pandas 端都要管

现象：用 Excel 直接打开 jobs_raw.csv，中文字段全部变成乱码或者问号，但在记事本里打开是正常的。

原因：Windows 版 Excel 默认用 GBK 编码读取 CSV，而这套脚本写入时用的是 UTF-8，两边对不上。另外 requests 抓取时如果没有主动设置 resp.encoding，requests 会按 HTTP 头里的 charset 解析，很多招聘网站不返回这个头，默认就可能解析出错。

解决：抓取时用 resp.encoding = resp.apparent_encoding 或者直接写死 utf-8；pandas 读写 CSV 时统一指定 encoding="utf-8-sig"。utf-8-sig 会在文件开头写 BOM 头，Excel 识别到 BOM 就会自动按 UTF-8 解码，这个细节一次设置，之后所有环节都不再乱码。

5.2 翻页到一半返回空白：请求频率太快被限流，别硬闯

现象：前 10 页抓得好好的，第 11 页开始返回空列表，或者返回一个带验证码提示的页面，解析结果是全空。

原因：请求频率太高，IP 触发了站点风控。很多招聘网站对搜索类接口有每分钟请求次数限制，连续快速翻页最容易触发。

解决：抓取循环里强制加随机停顿，时间间隔从 1 到 3 秒起步，遇到风控严格的目标站拉到 3 到 6 秒。如果已经触发了验证码，最好的做法是停止脚本等待一段时间，不是换着 UA 继续撞。课程设计场景下完全没有必要和反爬死磕，稍等十分钟再跑，或者直接改用包里现成的 data 数据，把时间花在分析上。

5.3 字段错位：select_one 选错节点时，数据会串行

现象：岗位名称和公司名称互相串位，比如“阿里巴巴”出现在岗位名称列，或者某些记录的薪资字段是空的。

原因：页面结构里可能有两套相似的 DOM，一套是真正的岗位卡片，另一套是广告位或者推荐位。直接对全局页面用 select_one 取字段，偶尔会命中错误节点，尤其当字段缺失时，select_one 会跳到别的卡片里去找。

解决：始终遵循“先定位卡片容器，再在容器内取字段”的解析方式。每个字段取回来之后做一次格式校验，最简单的办法是检查 salary 字段里是否包含数字或者“面议”，不满足就跳过这条记录。清洗阶段再做一次字段完整性检查，两个环节叠加，错位数据基本进不了最终数据集。

5.4 答辩机没网：pyecharts 图表白屏

现象：在自己电脑上打开的 HTML 图表一切正常，拿到答辩教室的电脑上双击打开，图表区域一片空白。

原因：pyecharts 默认从公共 CDN 加载 ECharts 的 JavaScript 文件，答辩教室断网或者网络受限时，JS 加载不出来，图表自然渲染不了。

解决：生成图表时指定本地 JS 文件路径，或者直接截图保存成 PNG。本地化方式是在 Bar 的 init_opts 里加一个 js_host 参数，指向本地 ECharts 文件所在目录。但更稳妥的做法是：答辩前一晚把每张图都打开截图，把图片插入 PPT 里，HTML 只作为现场演示的补充。图片永远不会因网络问题失效，这也是最保险的准备方式。

from pyecharts import options as opts from pyecharts.charts import Bar bar = Bar( init_opts=opts.InitOpts( width="1000px", height="600px", js_host="./echarts.min.js", # 本地化 JS 文件 ) )

6. 数据验收技巧：交作业前十分钟跑一遍自检脚本

6.1 三分钟的自动化检查，让数据口径经得起问

答辩前一天最焦虑的事情永远是“老师问数据是不是真的怎么办”。与其到时候支支吾吾，不如提前写一个自检脚本，把数据量、缺失率、图表存在性全部检查一遍，打印出一张清晰的结果清单。这个脚本看起来简单，但每次跑完都能给你吃一颗定心丸。

import os import sqlite3 import pandas as pd # 检查 1：数据库记录数是否达标 conn = sqlite3.connect("data/jobs.db") total = pd.read_sql("SELECT COUNT(*) AS c FROM jobs", conn)["c"][0] # 检查 2：薪资缺失率是否在可解释范围 salary_missing = pd.read_sql( "SELECT COUNT(*) AS c FROM jobs WHERE salary='面议'", conn )["c"][0] conn.close() print(f"数据总量: {total} 条") print(f"面议薪资占比: {salary_missing / max(total, 1):.1%}") # 检查 3：关键图表文件是否存在 required_charts = [ "visual/output/city_top10.html", "visual/output/skill_wordcloud.html", ] for path in required_charts: exists = os.path.exists(path) print(f"图表 {path}: {'存在' if exists else '缺失'}") assert exists, f"缺少图表文件: {path}" assert total >= 500, f"数据量不足，当前 {total} 条" print("自检通过，可以安心答辩")

逻辑说明：前两个检查从 SQLite 里直接统计记录数和薪资缺失率，第三个检查确认图表文件真实存在，最后用一个总断言兜底。跑完之后输出的信息既给你看，也是答辩时可以直接念给老师听的“数据质量说明”。

这个脚本还能延伸出一个很实用的习惯：每次重新抓完数据，先跑一遍自检再生成 PPT，确保所有图表对应的是最新数据，而不是拿上一版图表临时顶替。数据口径不一致是答辩翻车的重灾区，老师一旦发现图表里的数字和你口头表述对不上，整个项目的可信度都会打折扣。

从那以后我每做一个数据类项目，都会强制在最后一步走一遍这套快速自检流程：入库记录数、关键字段缺失率、图表文件存在性，三件事缺一不可。希望帮到你。

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