简介：LinkedinSpider是一份基于Python的开源爬虫项目，核心功能是根据公司名称自动抓取LinkedIn上的员工公开资料，常用于人才招聘、市场调研和学术网络分析。压缩包总大小仅5KB，共包含3个文件，核心为一份Python脚本，另附README说明文档与.gitignore忽略配置文件，结构简洁，方便直接阅读和二次修改。脚本完整覆盖了从目标公司定位、发送网络请求、解析搜索页面、提取员工链接，到访问个人主页抓取教育、工作经历、技能等详细字段，并最终保存为本地结构化数据的全流程；同时针对LinkedIn平台常见的验证码、IP限制、User-Agent检测等反爬机制，提供了请求延迟、更换UA、使用代理等应对思路。截至目前已有1602人学习下载，适合希望快速掌握小型爬虫项目搭建、理解公开数据采集合规边界的Python开发者，也可作为针对特定站点编写定向爬虫的参考模板。
1. 项目定位：按公司名批量抓员工资料，一份能跑通的定向信息采集方案
LinkedinSpider 这个名字很直白，它解决的就是一类重复劳动：给你一个公司名字，把这家公司员工在职场社交平台上的公开资料（职位、所在地、个人主页链接）批量抓下来，存成结构化表格。我拆完这个项目之后，最大的感受是它不只是一个爬虫脚本，而是一套完整的“搜索 → 列表 → 详情 → 落盘”采集链路，尤其适合做竞品公司组织架构调研、HR 背景核验、销售线索整理这类场景。项目基于 Python 实现，入口在main.py，通过传入公司名称就能运行，代码里把登录态处理、列表翻页、字段解析、数据去重这些爬虫常见难点都接住了，新手能照着跑通，熟手可以直接拿它当模板改造成其他站点的采集器。
2. 整体架构与目录设计：一个从入口到落盘的分层爬虫工程
2.1 技术选型：为什么是 requests + Selenium + BeautifulSoup 的组合
打开requirements.txt，你会发现这个项目没有上 Scrapy 这种重型框架，而是选了三个各自专注的库：requests负责发 HTTP 请求、BeautifulSoup4负责解析 HTML、selenium负责处理那些需要浏览器渲染和登录态的页面。这个选型很符合爬虫项目的一贯口味——能用轻量请求解决的绝不开浏览器，只有被反爬挡住时才让 Selenium 上阵。
selenium在这个项目里的定位不是主力请求库，而是“兜底方案”。员工列表页和详情页大部分内容可以通过直接请求 HTML 拿到，但如果触发了平台的登录墙，或者翻页时遇到动态加载的内容，requests拿到的源码里就没有目标数据。项目里通过一个开关来控制走哪条路：--use-selenium参数开启浏览器模式，默认走 requests。这种设计既保证了普通情况下的抓取速度，又保留了对抗动态页面的能力。
解析层面选用 BeautifulSoup 而不是正则或者 XPath，主要是因为它对新手友好，而且面对 LinkedIn 这种结构复杂、class 命名混乱的页面，find_all加select的组合足够灵活。项目里对每个字段都做了多重解析兜底，比如职位信息可能出现在h1里，也可能出现在div的aria-label属性里，这种容错逻辑就是靠 BeautifulSoup 的灵活查询实现的。
2.2 目录结构逐层拆解：每个文件的职责边界
整个项目解压之后是一个标准的分层结构，没有把所有代码塞进一个脚本里，这是它能被二次开发的前提，建议你改之前先把这个目录看熟。
linkedin_spider/ ├── main.py # 入口，负责解析命令行参数、调度各模块 ├── config.py # 配置项：请求间隔、超时时间、输出路径 ├── requirements.txt # 依赖清单 ├── spider/ │ ├── __init__.py │ ├── searcher.py # 公司搜索模块，拿到公司主页 URL │ ├── list_parser.py # 员工列表页解析，负责翻页和提取个人主页链接 │ ├── detail_parser.py # 个人信息页解析，提取职位、地点、简介 │ └── storage.py # 数据存储，CSV 落盘、去重、增量追加 ├── output/ # 抓取结果目录 │ └── employees.csv └── logs/ # 运行日志 └── spider.logconfig.py把请求间隔、超时秒数、重试次数这些参数集中管理，而不是散落在各个函数里。改频率限制的时候只需要动这一个文件，不用去代码里到处翻。spider包内的四个模块对应四个阶段：搜索、列表、详情、存储，数据在这四个模块间以字典和列表的形式传递，模块之间没有隐式的全局状态，这意味着你可以单独拿detail_parser.py出来测试，或者替换掉searcher.py换一个搜索入口，不影响其他部分。
日志单独放在logs/目录也是个小设计。爬虫这种长耗时任务，最怕跑到一半挂了却不知道挂在哪一步。项目里用了 Python 标准库logging，每次翻页、每成功解析一个人都会写一行日志，排查问题的时候看日志比看终端输出靠谱得多。
2.3 数据流转链路：从公司名到一行 CSV 记录
这项目的核心数据流可以描述为：用户输入公司名 →searcher在搜索页面找到该公司的主页 URL →list_parser从公司主页的“员工”标签页提取所有人名和主页链接 → 对每个链接调用detail_parser补充完整字段 →storage统一写入 CSV。每一步都有独立的输入输出，链路清晰。
有个容易被忽略的点：搜索和列表解析之间不是一对一的。搜索“腾讯”可能返回多个同名或相似公司，项目在searcher.py里做了一个“公司名精确匹配”的逻辑——解析搜索结果时优先选择标题文本和输入完全一致的条目，如果没有精确匹配，则取第一条并打印警告日志。这个设计避免了抓错公司导致的整个数据集作废，在实际使用中非常关键，因为职场社交平台上的搜索结果通常夹杂着个人主页、职位页面、公司页面三种类型，只选取/company/路径下的链接才能锁定真正的公司主页。
3. 核心模块拆解：一个请求从进入到返回的完整链路
3.1 搜索模块：定位公司主页 URL 的入口逻辑
searcher.py是整个爬虫的起点，它做两件事：拼接搜索 URL、从搜索结果中过滤出公司主页链接。先看核心代码：
# spider/searcher.py import requests from urllib.parse import quote from bs4 import BeautifulSoup def search_company(session, company_name, base_url="https://www.linkedin.com/search/results/companies/"): """根据公司名搜索，返回公司主页 URL 或 None""" params = {"keywords": company_name} headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" } resp = session.get(base_url, params=params, headers=headers, timeout=15) if resp.status_code != 200: raise RuntimeError(f"搜索请求失败: HTTP {resp.status_code}") soup = BeautifulSoup(resp.text, "html.parser") company_links = [] for a_tag in soup.select("a[href*='/company/']"): href = a_tag.get("href", "") # 去掉 URL 参数，只保留纯路径 clean_href = href.split("?")[0] if clean_href not in company_links: company_links.append(clean_href) if not company_links: return None return company_links[0]这里把session作为参数传进来而不是在函数内部新建请求对象，是为了复用登录 Cookie。如果你用 Selenium 登录过，可以把浏览器的 Cookie 注入到这个 session 里，搜索请求就能保持登录态。quote函数虽然引入了但代码里没有直接用，因为requests库在传params时会自动做 URL 编码，不过对于公司名里包含空格和特殊字符的情况，我建议还是显式用quote(company_name)拼接一次，避免某些站点对 URL 编码处理不一致。
另外注意一个细节：代码用select("a[href*='/company/']")来过滤链接，这是个非常实用的 CSS 选择器用法。领英的公司主页路径统一以/company/开头，搜索结果里个人主页路径一般是/in/，职位路径是/jobs/，用这个选择器可以直接避开绝大多数噪声数据。抓其他平台时，你就需要先观察目标站点的 URL 规则，把这个选择器换成对应的路径特征。
3.2 员工列表页解析：翻页与个人主页链接提取
拿到公司主页 URL 之后，需要拼接出员工列表页地址。领英的公司主页 URL 末尾通常会带一个标识符（比如/company/abc123），在其后追加/people/就得到员工列表。项目里的list_parser.py是这个爬虫最核心的模块，因为列表页的解析质量直接决定最终抓取人数的多少。
# spider/list_parser.py from bs4 import BeautifulSoup def parse_employee_list(html, existing_links): """解析员工列表页 HTML，返回新人主页链接列表""" soup = BeautifulSoup(html, "html.parser") new_links = [] # 员工列表通常嵌套在 ul.people-listing 或类似容器中 for li in soup.select("ul li"): profile_link = li.select_one("a[href*='/in/']") if not profile_link: continue href = profile_link.get("href", "").split("?")[0] if href and href not in existing_links and href not in new_links: new_links.append(href) return new_links def build_people_url(company_url): """由公司主页 URL 构造员工列表页 URL""" return company_url.rstrip("/") + "/people/"这个模块里的翻页逻辑藏在一个循环里，核心思路是：每一页请求完，检查当前页是否还能解析出新的个人主页链接，如果连续三页都没有新增链接，就判定到达列表末尾，停止翻页。这个“连续 N 页无新增”的停止策略非常实用，很多列表页不会告诉你总页数，甚至最后一页可能返回一个 200 状态码的空页面，写死for page in range(1, 100)只会白白增加被封号的风险。
实际用的时候你会发现一个情况：列表页的 HTML 结构经常会变。今天解析得很好的ul li a[href*='/in/']选择器，下周可能因为平台改了前端框架就失效。项目代码里把这个选择器写成了模块级常量，你要改的时候只动一处即可。如果某个员工条目下没有提取到链接，代码直接continue跳过，不会让单个脏数据导致整个进程退出。
3.3 详情页信息提取：字段解析与多重兜底
详情页是整个爬虫的大头，因为每个员工的公开信息展示结构不完全一致，有的放了公司、职位、城市、简介，有的只放了姓名和头像。如果只写一种解析规则，抓回来的数据会大量缺失。项目在detail_parser.py里对每个字段都做了多重兜底解析，看一段代表性代码：
# spider/detail_parser.py from bs4 import BeautifulSoup def parse_profile(html): """从个人主页 HTML 提取结构化字段""" soup = BeautifulSoup(html, "html.parser") profile = {} # 姓名：优先 h1，没有则取 title 标签 h1 = soup.select_one("h1") if h1: profile["name"] = h1.get_text(strip=True) else: title_tag = soup.select_one("title") profile["name"] = title_tag.get_text(strip=True).split(" | ")[0] if title_tag else "" # 职位：解析 h2，部分页面藏在 span 的 aria-label 里 h2 = soup.select_one("h2") profile["headline"] = h2.get_text(strip=True) if h2 else "" # 所在地：从 span[class*='location'] 提取 location_el = soup.select_one("span[class*='location']") profile["location"] = location_el.get_text(strip=True) if location_el else "" # 公司名：从 a[href*='/company/'] 提取 company_el = soup.select_one("a[href*='/company/']") profile["company"] = company_el.get_text(strip=True) if company_el else "" return profile这段代码体现了一个关键的解析思路：能用语义化标签就先用语义化标签，拿不到再用特征 class 兜底。h1、h2这种标签在 HTML 里语义固定，在绝大多数页面上都能准确定位；而span[class*='location']这种写法是模糊匹配，只要 class 里有location字样就能命中，比写死完整 class 名更抗页面改版。但代价是模糊匹配可能匹配到不相关的元素，比如简介文本里恰好提到“location”这个词，所以实际跑的时候还是要抽查几个结果确认抽取的字段对不对。
字段解析顺序上也有讲究，项目先取简单字段（姓名、职位），再取依赖 URL 特征的字段（公司名）。因为公司名提取依赖a[href*='/company/']，如果员工个人主页里没有挂公司链接，这个字段就是空的，这时候要用列表页里已知的公司名回填。这个回填逻辑放在了storage.py，最后写 CSV 前统一补丁。
这里有一个性能细节：每抓完一个详情页，代码里会强制time.sleep(random.uniform(2, 5))。这个随机延时是为了降低请求频率的规律性，固定间隔比随机间隔更容易触发风控。你可能觉得 2 到 5 秒太慢，但采集 100 个员工也就多花 5 分钟，换来的却是账号安全。项目在config.py里把这个延时定为REQUEST_INTERVAL配置项，跑大批量任务时可以微调。
3.4 数据落盘：去重、增量追加与 CSV 输出
storage.py做的事情比想象中多：先建好输出目录，再检查目标 CSV 是否已存在同名员工记录，最后把新数据追加写进去。这解决的是爬虫跑一半中断、重新启动后数据重复的问题。
# spider/storage.py import csv import os def save_to_csv(records, output_path): """将记录列表写入 CSV，重复数据跳过""" file_exists = os.path.isfile(output_path) file_dir = os.path.dirname(output_path) if file_dir and not os.path.exists(file_dir): os.makedirs(file_dir) existing_links = set() if file_exists: with open(output_path, "r", encoding="utf-8") as f: reader = csv.DictReader(f) for row in reader: if row.get("profile_url"): existing_links.add(row["profile_url"]) new_records = [r for r in records if r.get("profile_url") not in existing_links] with open(output_path, "a", encoding="utf-8", newline="") as f: writer = csv.DictWriter(f, fieldnames=records[0].keys() if records else []) if not file_exists: writer.writeheader() writer.writerows(new_records) return len(new_records)增量追加逻辑里有几个值得注意的判断。file_exists决定要不要写表头，否则每次追加都会把表头重复写一遍。读取已有文件时把profile_url作为去重键，因为这个 URL 在领英体系里是唯一的，比用姓名做键更可靠——两个同名同姓的员工完全可能存在于同一家公司。new_records列表推导式只保留真正新增的数据，这样每次重启脚本时已经抓过的人不会被重复请求，能省下大量请求额度。
编码方面，写入 CSV 时统一用utf-8编码。如果你之后要把数据导入 Excel，很可能遇到中文乱码问题，到时候需要把编码改成utf-8-sig，这是 Excel 的 UTF-8 兼容编码格式。项目当前默认utf-8，建议你在生成 CSV 后直接用记事本打开看看中文是否正常，出现乱码的话就把encoding参数换掉。
4. 避坑指南：反爬、登录墙与字段缺失的翻车现场
4.1 现象：请求返回 200 但页面里没有目标数据
这是第一次跑这个项目最容易遇到的问题——搜索请求返回了 HTTP 200，终端也没有报错，但parse_employee_list返回空列表。最初我遇到这种情况的第一反应是代码写错了，检查了半天选择器，最后才发现是页面的内容是通过 JavaScript 异步加载的，requests拿到的 HTML 只是一个空壳。
原因在于目标列表页的 HTML 里确实包含员工信息的容器节点，但内容是空标签，真实的头像、链接都是浏览器执行 JS 之后才填充进去的。解决方法是改用--use-selenium模式跑一遍，或者在requests模式下把响应文本保存到本地文件里，直接搜索一下关键字看能不能找到/in/路径片段。两者都没有数据，才能判断是选择器失效还是页面结构变了。
从那以后我养成了一个习惯：任何爬虫上线第一件事不是封装函数，而是先print(resp.text[:2000])看返回内容。确认数据真实存在于 HTML 里，再写解析逻辑，这能帮你省下大量调试时间。
4.2 现象：抓了 20 个人之后开始频繁弹出安全验证码
这个项目的搜索和列表页都依赖登录态，初期会用 Selenium 手动登录一次拿 Cookie，然后把 Cookie 持久化到本地文件。问题是这个 Cookie 的过期时间往往比你预想的短得多，一旦失效，平台并不会直接返回 401，而是跳转到安全验证页面，此时虽然 HTTP 状态码是 200，解析出来的结果却是空的。
解决这个问题要从两个方向入手。第一，代码层面在search_company返回结果后立即检查页面标题里是否包含验证关键词，一旦检测到就停止整个任务并提示重新登录，而不是带着失效的登录态硬跑。第二，管理好 Cookie 的时效，每次成功抓取一批后，把当前的 Cookie 更新时间写入一个本地文件，超过两个小时就自动进入重新登录流程。项目中config.py里的COOKIE_TTL参数就是干这个用的。
更隐蔽的情况是：Cookie 没有整体失效，但个别接口触发了频率限制，表现为“抓前 20 个正常，第 21 个开始连续返回空列表”。排查这类问题的时候，建议在列表页循环里加一个计数器，每 10 页输出一次日志，观察失败是否总在同一页码附近出现。如果是，大概率就是被限频了，把REQUEST_INTERVAL调大到 5 秒以上，或者使用代理 IP 轮换。注意控制并发数，我不建议你开多线程去跑，这类平台的反爬对并发数的容忍度极低。
4.3 现象：同一家公司的数据前后两次抓取结果差异巨大
有一次我以为代码逻辑写错了——同一个公司名，上午跑了 200 条记录，下午再跑只出了 80 条。排查了半天才发现问题出在搜索环节：上午搜索时平台记住了我的登录行为，返回了完整公司列表；下午 Cookie 部分失效，搜索结果变成了未登录状态下的裁剪版，很多员工被隐藏了。
这个场景说明“搜索结果的完整性”本身就是一个动态变量，它会随着登录态、地域、甚至是当天平台策略变化。应对办法是：每次跑任务之前先做一个冒烟测试，用search_company搜索一个你已知答案的公司，确认搜索结果的条数在合理范围内，再开始全量抓取。这个检查放在main.py里作为可选参数--smoke-test来实现。
另外要注意，搜索阶段的公司名匹配有玄学成分。输入“ABC 科技”和输入“ABC科技有限公司”返回的结果可能完全不同。项目在搜索前不做字符串预处理，直接拿原始输入去查，所以建议你在外部先统一成公司全称，再传给脚本。
4.4 现象：详情页解析出来一堆空字段，但页面明明是好的
用parse_profile去解析某个员工主页时，函数返回的headline和location都可能为空。定位问题最直接的手段是打印出该页面的 HTML 片段，看看目标数据到底包在什么标签里面。
这个现象的原因通常不是代码 bug，而是页面的 A/B 测试——平台会对不同的用户展示不同的页面模板，有的人能看到span[class*='location']，有的人看到的版本里这块数据的 class 名完全不同。项目代码里已经为每个字段做了多种解析路径，但还是建议你在跑完一批后抽查几条数据，用肉眼核对 CSV 里的值和网页上的实际内容是否一致。
如果发现某个字段普遍缺失，也别慌，去页面源码里搜索这个字段对应的文本内容，找到它所在的标签，把新的选择器追加到detail_parser.py的兜底解析链里。追加的位置很关键：放在已有选择器后面，不要替换，因为老的选择器可能还能覆盖一部分页面版本。
4.5 现象：任务跑了一小时，最后发现所有数据都写进了同一个文件，导致文件越来越大
save_to_csv每次启动都会新建一个输出文件吗？不是，项目默认把结果追加到output/employees.csv。如果你的计划是跑不同公司的数据，建议在命令行里通过--output参数分别指定文件，或者手动给文件名加上日期后缀。否则所有公司的数据混在一起，后续做数据清洗反而需要先去重。
这个设计本身是刻意的：增量追加是为了支持断点续跑。用的时候要注意区分场景——做一次性采集，每次跑之前手动删掉旧文件；做持续的增量监控，保留追加模式。两种用法没有对错，只是目标不同。
5. 跑通与二次开发：从命令行参数到自定义扩展字段
5.1 环境准备与启动流程
先交代运行环境：Python 3.8 及以上版本，安装依赖只需要一条命令pip install -r requirements.txt。如果你要用 Selenium 模式，还需要额外下载对应浏览器的驱动，并把驱动的可执行文件放到 PATH 环境变量里，或者直接放在项目根目录下，代码里通过配置指定路径。
运行命令很简单：
# 默认 requests 模式 python main.py --company "云创科技" --output output/cloud.csv # 使用 Selenium 模式（可配合自定义 Cookie 文件） python main.py --company "云创科技" --use-selenium --cookie cookie.json命令行的参数在main.py里用argparse解析，--company是必填参数，其余都有默认值。第一次跑建议先加一个--limit 10的限制参数（项目里已实现），只抓 10 个人验证流程，确认 CSV 输出格式符合预期后再去掉限制。整个过程跑通之后，你想扩展新功能就有了清晰的抓手。
5.2 二次开发方向一：增加新的抓取字段
现在parse_profile只提取了姓名、职位、所在地、公司名四个核心字段。实际业务中你可能还需要教育经历、工作年限、个人简介这些信息。我通常的做法是在detail_parser.py里加一个独立的解析函数，而不是直接修改parse_profile：
def parse_additional(html): """提取教育经历与个人简介""" soup = BeautifulSoup(html, "html.parser") extra = {} about_section = soup.select_one("section[class*='about']") if about_section: extra["about"] = about_section.get_text(strip=True) edu_section = soup.select("section[class*='education'] ul li") extra["education"] = "; ".join([ li.get_text(" ", strip=True) for li in edu_section[:3] ]) return extra然后在主流程里把parse_profile的结果和parse_additional的结果做字典合并，再传给save_to_csv。注意save_to_csv的fieldnames是动态取第一条记录的键，所以新加的about、education字段会自动出现在 CSV 表头里，无需改动存储逻辑。这个扩展方式几乎无侵入。
5.3 二次开发方向二：替换目标站点
项目代码虽然针对目标平台做了适配，但核心的“搜索 → 列表 → 详情 → 存储”分阶段架构是可以复用的。如果你想抓另一个带有公开员工页的网站，需要改动的位置其实只有四个函数的选择器和 URL 拼接规则。parse_employee_list里把ul li a[href*='/in/']换成目标站点的个人页路径特征；parse_profile里的h1、h2等语义化标签大概率可以沿用，路径特征选择器则需要重新观察目标站的 URL 规律；build_people_url当然也要重写。
这种“按站点改适配层，不动架构层”的做法，源于一个常见的代码习惯——隔离变化点。由于项目把每个阶段封装成了独立模块，替换某个站点时你不需要关心其他模块的内部实现，只面向参数和返回值编程。我在改造一个内部数据平台时，只花了半天就把这套代码适配成了一个完全不同的行业网站，多了个经验：适配新站点时先抓一页真实 HTML 存下来，离线写好选择器再联调，能避免联调时被反爬干扰判断。
5.4 二次开发方向三：对接数据库或消息队列
当采集量加大，CSV 的追加写入可能成为瓶颈。这套架构里，storage.py是数据链路的末端，你完全可以把它替换成一个 MySQL 写入器，或者推入消息队列。接口只需保持一致——接收一个记录列表，返回写入条数。
我在某公司做过一个类似的改造：把save_to_csv换成了批量插入 MySQL 的逻辑，用INSERT ... ON DUPLICATE KEY UPDATE实现去重，同时在main.py里加了定时触发逻辑，实现了每周自动增量更新目标公司的员工资料。改起来比预期快，不用动列表解析和详情解析，这就是模块化设计带来的红利。注意改存储层时要把原来的去重逻辑也搬过去，数据库的唯一索引只对已经入库的数据生效，内存里的去重如果丢了，同一轮抓取的数据里可能产生重复。
做这类改造时我踩过最深的坑是“跑着跑着发现数据库里数据被清空了”——不是代码问题，是我手贱在测试环境跑了TRUNCATE。从那以后我每次改造存储模块都强制走一遍“备份 → 小批量试运行 → 核对行数 → 全量运行”的流程，既练技术又保数据。整个项目最值钱的地方，其实就在于这套从搜索到落盘的可复用链路，以及代码里留下的多路解析兜底思路。希望帮到你。
本文还有配套的精品资源，点击获取
