截至 2026 年 4 月，在 GitHub 上搜索“linkedin scraper”大约会返回 。其中大多数都会浪费你的时间。 刺耳吗？也许吧。但这是我在审查了最显眼的 8 个仓库、阅读了数十个 GitHub issue 讨论串，并交叉比对 Reddit 和抓取论坛上的社区反馈后得出的结论。模式反复出现：高星仓库吸引关注，LinkedIn 的反爬团队研究代码，检测规则被修补，用户最后拿到的却是失效的选择器、CAPTCHA 循环，甚至账号被直接封禁。一位 Reddit 用户直截了当地概括了现状——LinkedIn 加强了“更严格的速率限制、更好的机器人检测、会话追踪，以及频繁变更”，老工具现在“很快就会失效，或者让账号/IP 被标记”。如果你是销售、招聘，或运营经理，只想把 LinkedIn 数据放进表格里，那么你上个月克隆下来的仓库，很可能已经没用了。这篇指南会帮你判断哪些 GitHub 项目真的值得花时间，如何避免把账号搞废，以及什么时候干脆跳过代码才更明智。
GitHub 上的 LinkedIn 爬虫是什么？
LinkedIn 爬虫 GitHub 项目通常是一个开源脚本——多为 Python，有时是 Node.js——用来自动从 LinkedIn 页面提取结构化数据。常见目标包括：
- 个人资料：姓名、头衔、公司、所在地、技能、经历
- 职位信息：职位名称、公司、所在地、发布时间、职位链接
- 公司页面：概览、员工数、行业、关注者数量
- 动态与互动：内容文本、点赞、评论、分享
从实现方式上看，大多数仓库会采用两种路径之一。基于浏览器的爬虫会依赖 Selenium、Playwright 或 Puppeteer 来渲染页面、点击流程，并通过 CSS 选择器或 XPath 提取数据。还有一小部分会直接调用 LinkedIn 内部的（未公开）API 接口。更近的一波——在 GitHub 上仍然不多，但正在增长——会把浏览器自动化和像 GPT-4o mini 这样的 LLM 结合起来，把页面文本解析成结构化字段，而不是依赖脆弱的选择器。
这里存在一个根本的受众错位。这些工具是为熟悉虚拟环境、浏览器依赖和代理配置的开发者设计的。但搜索“linkedin scraper github”的人里，很大一部分其实是招聘、SDR、RevOps 经理和创始人，他们只是想把数据行放到表格里。
这也是 issue 讨论串里大多数挫败感的来源。
为什么人们会转向 GitHub 做 LinkedIn 抓取
吸引力很明显：免费、可定制、没有供应商绑定、对数据管道有完全控制权。如果某个 SaaS 工具改价或关停，你的代码还在。
| 用例 | 需要的人 | 通常提取的数据 |
|---|---|---|
| 线索生成 | 销售团队 | 姓名、头衔、公司、个人主页链接、邮箱线索 |
| 候选人搜寻 | 招聘团队 | 个人资料、技能、经历、所在地 |
| 市场研究 | 运营与战略团队 | 公司数据、员工数、职位发布 |
| 竞争情报 | 市场团队 | 动态、互动、公司更新、招聘信号 |
但“免费”只是许可证标签，不是运营成本。真实开销包括：
- 搭建时间：即便是友好的仓库，环境配置、浏览器依赖、Cookie 提取和代理配置，通常也要 30 分钟到 2 小时以上
- 维护成本：LinkedIn 会定期更改 DOM 和反爬防护——今天还能用的爬虫，下周就可能坏掉
- 代理费用：住宅代理带宽通常是按 计价，具体取决于供应商和套餐
- 账号风险：你的 LinkedIn 账号是最大的风险资产，而且不像代理 IP 那样可替换
仓库健康评分表：如何评估任何 LinkedIn 爬虫 GitHub 项目
大多数“最佳 LinkedIn 爬虫”榜单只按 star 数排序。star 只能说明历史关注度，不能代表当前可用性。一个有 3,000 个 star、但自 2022 年后再没提交的仓库，是博物馆展品，不是生产工具。
在执行 git clone 之前，先用这套框架筛一下：
| 标准 | 为什么重要 | 红旗信号 |
|---|---|---|
| 最近一次提交时间 | LinkedIn 经常改 DOM | 浏览器驱动型仓库超过 6 个月没更新 |
| 未解决/已关闭 issue 比例 | 维护者响应速度 | 未解决与已关闭比超过 3:1，尤其最近出现“blocked”或“CAPTCHA”报告 |
| 反检测功能 | LinkedIn 封禁很积极 | README 里完全没提 cookies、sessions、节奏控制或 proxies |
| 认证方式 | 2FA 和 CAPTCHA 会破坏登录流程 | 只支持基于密码的无头登录 |
| 许可证类型 | 商业使用的法律风险 | 没有许可证或条款含糊不清 |
| 支持的数据类型 | 不同场景需要不同仓库 | 只支持一种数据类型，而你需要多种 |
最省时间的一个诀窍：在决定投入某个仓库之前，先在 Issues 标签页里搜“blocked”“banned”“CAPTCHA”或“not working”。如果最近的 issue 里这些词很多，而且维护者没有回应，那就直接放弃。这个仓库已经输了。
2026 年审计到底发现了什么
我把这套评分表应用到了 GitHub 上 8 个最显眼的 LinkedIn 爬虫仓库。结果并不乐观。
| 仓库 | Stars | 最近提交 | 2026 年还能用吗？ | 主要范围 | 关键备注 |
|---|---|---|---|---|---|
| joeyism/linkedin_scraper | ~3,983 | 2026 年 4 月 | ✅ 有条件可用 | 个人资料、公司、动态、职位 | 基于 Playwright 重写、复用会话——但最近 issues 显示存在安全拦截和职位搜索失效 |
| python-scrapy-playbook/linkedin-python-scrapy-scraper | ~111 | 2026 年 1 月 | ✅ 适合教程/公开数据 | 个人、公司、职位 | 集成 ScrapeOps 代理；免费方案每月允许 1,000 次请求、1 个线程 |
| spinlud/py-linkedin-jobs-scraper | ~472 | 2025 年 3 月 | ⚠️ 仅适合职位 | 职位 | 支持 Cookie、实验性代理模式——如果你只需要公开职位列表，这个有用 |
| madingess/EasyApplyBot | ~170 | 2025 年 3 月 | ⚠️ 工具不对 | Easy Apply 自动化 | 这不是数据爬虫——它是自动投递职位申请 |
| linkedtales/scrapedin | ~611 | 2021 年 5 月 | ❌ | 个人资料 | README 里还写着“working in 2020”；issues 显示有 pin 验证和 HTML 变更问题 |
| austinoboyle/scrape-linkedin-selenium | ~526 | 2022 年 10 月 | ❌ | 个人资料、公司 | 曾经有用，但到 2026 年已经太旧了 |
| eilonmore/linkedin-private-api | ~291 | 2022 年 7 月 | ❌ | 个人资料、职位、公司、动态 | 私有 API 封装；未公开接口变化不可预测 |
| nsandman/linkedin-api | ~154 | 2019 年 7 月 | ❌ | 个人资料、消息、搜索 | 曾经很有意思；文档记录显示大约每小时 900 次请求后会触发速率限制 |
在这 8 个仓库里，只有 2 个 对 2026 年读者来说算得上真正可用，而且还得加很多限制说明。这在 GitHub 上做 LinkedIn 抓取时一点都不罕见——这就是常态。
防封禁手册：代理、速率限制与账号安全
账号封禁是最大的运营风险。即便技术能力很强的爬虫也会在这里翻车。代码能跑，账号却保不住。用户报告称，即便用了代理和长时间延迟，也会在抓取仅 后被标记。
速率限制：社区是怎么说的
不存在一个绝对安全的数字。LinkedIn 评估的是会话年龄、点击节奏、突发模式、IP 信誉和账号行为，而不只是原始数量。社区数据大致落在这些区间：
- 有用户报告称，即便用了代理和每次 33 秒节奏控制，仍在 40–80 个个人资料 后被检测到
- 另一位建议把量控制在 每天每账号 30 个个人资料 左右
- 更激进的操作者声称可以做到 并分散到全天
- 记录了大约 1 小时 900 次请求 后会出现内部速率限制警告
实用结论是：每天每账号少于 50 次个人资料浏览 属于较低风险区。每天 50–100 次 属于中等风险，此时会话质量非常关键。每天每账号超过 100 次 则进入越来越激进的区间。
代理策略：住宅代理 vs. 数据中心代理
住宅代理仍然是 LinkedIn 的标准选择，因为它们更像普通终端用户流量。数据中心 IP 更便宜，但在复杂网站上更容易被标记——而 LinkedIn 正是那种会盯上廉价流量的复杂网站。
当前价格参考：
- ：每 GB 3.00–4.00 美元，视套餐而定
- ：每 GB 4.00–6.00 美元，视套餐而定
要按会话轮换，不要按请求轮换。按请求轮换会制造一种比单个 IP 更明显的“这是代理基础设施”的指纹。
备用账号流程
社区对这点的建议很直接：不要把你的主 LinkedIn 账号当成可随意消耗的抓取基础设施。
如果你坚持使用账号型抓取：
- 用一个独立于你主职业身份的账号
- 把资料完善好，并让它在抓取前像真人一样使用几天
- 不要把真实手机号绑定到抓取账号上
- 把抓取会话与真实外联和消息发送完全分开
值得注意的是：LinkedIn 的 （2025 年 11 月 3 日生效）明确禁止使用虚假身份和账号共享。备用账号做法在操作上很常见，但在合同层面并不干净。
如何处理 CAPTCHA
CAPTCHA 不只是麻烦，它还意味着你的会话已经处于被重点监控状态。可选方案包括：
- 手动完成后继续会话
- 复用 cookies，而不是反复重新执行登录流程
- 使用像 这样的解题服务（图像 CAPTCHA 约每 1,000 个 0.50–1.00 美元，reCAPTCHA v2 约每 1,000 个 1.00–2.99 美元）
但如果你的流程经常触发 CAPTCHA，那么解题服务那点成本根本不是重点。你的整套方案在隐蔽性上已经输了。
风险光谱
| 量级 | 风险等级 | 推荐做法 |
|---|---|---|
| < 50 个个人资料/天 | 较低 | 浏览器会话或 cookie 复用、慢节奏、不要激进自动化 |
| 50–500 个个人资料/天 | 中到高 | 住宅代理、养号、会话复用、随机延迟 |
| 500+/天 | 非常高 | 商业 API 或带内置反检测的维护型工具；单靠公开 GitHub 仓库通常不够 |
开源悖论：为什么热门的 LinkedIn 爬虫 GitHub 仓库坏得更快
用户提出了一个很合理的担忧：“把它做成开源版本，就等于让 LinkedIn 直接看清你在做什么，然后提前阻止你。” 这种担心并不偏执，而是结构上成立的。
可见性问题
高 star 数会同时产生两个信号：对用户来说是可信度，对 LinkedIn 安全团队来说却是靶子。仓库越受欢迎，LinkedIn 就越可能专门针对它的方式做拦截。
你可以在审计数据里看到这个生命周期。linkedtales/scrapedin 曾经足够知名，还特意宣称能适配 LinkedIn 的“new website”——那是在 2020 年。但后来它没能跟上后续的验证和布局变化。nsandman/linkedin-api 曾经记录过一些有用技巧，但它最后一次提交比当前的反机器人环境早了好几年。
社区补丁的优势
开源仍然有一个现实优势：当 LinkedIn 改变防护时，活跃的维护者和贡献者可以更快打补丁。joeyism/linkedin_scraper 是这次审计里最典型的例子——它依然会冒出 blocked-auth 和 broken-search 的问题，但至少还在持续更新。很多 fork 往往比原仓库更快实现新的绕过技巧。
你应该怎么做
- 不要把单个公开仓库当成永久基础设施
- 关注那些在实现更新绕过技术的活跃 fork
- 如果用于生产环境，可以考虑维护一个私有 fork（这样你的具体适配不会公开）
- 预计在 LinkedIn 调整检测或界面行为时要改方法
- 多准备几种方案，不要把全部筹码押在一个工具上
AI 抽取 vs. CSS 选择器：实用对比
2026 年最值得关注的技术分野，不是 GitHub 对无代码，而是基于选择器的抽取与语义抽取之间的差异——而且这个差异比大多数综述文章承认的都重要。
CSS 选择器是怎么工作的，以及它为什么会坏
传统爬虫会检查 LinkedIn 的 DOM，并把每个字段映射到 CSS 选择器或 XPath 表达式。只要页面结构稳定，这种方式就很出色：精度高、边际成本低、解析速度快。
失败模式也同样明显。LinkedIn 一旦改类名、嵌套结构、懒加载行为，或者把内容放到不同的认证墙后面，爬虫就会立刻坏掉。仓库审计里的 issue 标题已经把故事讲得很清楚：“changed HTML”“broken job search”“missing values”“authwall blocks”。
AI/LLM 抽取是怎么工作的
更近的一种模式概念上更简单：渲染页面、收集可见文本、让模型输出结构化字段。很多无代码 AI 爬虫以及一些新的定制工作流，都是基于这个逻辑。
按照当前 （输入每 100 万 token 0.15 美元，输出每 100 万 token 0.60 美元），一次纯文本抽取一个个人资料通常只要 每个资料 0.0006–0.0018 美元。对于中等规模工作流来说，这小到几乎可以忽略。
直接对比
| 维度 | CSS 选择器 / XPath | AI/LLM 抽取 |
|---|---|---|
| 搭建成本 | 高——需要检查 DOM、为每个字段写选择器 | 低——用自然语言描述想要的输出即可 |
| 页面改版后的失效情况 | 立即失效 | 自动适应（按语义读取） |
| 结构化字段准确率 | 选择器正确时约 99% | 约 95–98%（偶尔有 LLM 解释错误） |
| 处理非结构化/可变数据 | 没有自定义逻辑就很弱 | 很强——AI 能理解上下文 |
| 每个资料成本 | 几乎为零（只算算力） | 约 0.001–0.002 美元（API token 成本） |
| 标注/分类 | 需要单独后处理 | 一次就能分类、翻译、标注 |
| 维护负担 | 持续修选择器 | 几乎为零 |
你该选哪一个？
对于超大规模、结构稳定、由工程团队负责的管道，基于选择器的解析在成本上仍可能占优。对于大多数抓取几百而不是几百万个资料的小型和中型用户来说，AI 抽取是更好的长期投入，因为 LinkedIn 布局变化带来的开发时间成本，往往比你节省下来的模型 token 更贵。
当 GitHub 仓库过于重型：无代码路径
大多数搜索“linkedin scraper github”的人，并不想变成浏览器自动化维护者。
他们想要的是表格里的几行数据。
用户在 issue 讨论串里明确抱怨 GitHub 爬虫的可用性：“它不处理 2FA，而且没有 UI，所以并不好用。” 这个受众里包括招聘、SDR 和运营经理——不只是 Python 开发者。
自建还是购买
| 因素 | GitHub 仓库 | 无代码工具（例如 Thunderbit） |
|---|---|---|
| 搭建时间 | 30 分钟到 2 小时以上（Python、依赖、代理） | 2 分钟以内（安装扩展、点击即可） |
| 维护 | LinkedIn 变更时你自己修 | 工具提供方负责更新 |
| 反检测 | 你自己配置代理、延迟、会话 | 内置在工具里 |
| 数据结构化 | 你自己写解析逻辑 | AI 自动建议字段 |
| 导出选项 | 你自己搭建导出管道 | 一键导出到 Excel、Google 表格、Airtable、Notion |
| 成本 | 免费仓库 + 代理成本 + 你的时间 | 有免费层；大规模按积分计费 |
Thunderbit 如何无代码处理 LinkedIn 抓取
处理这个问题的方式和 GitHub 仓库不同。你不需要写选择器，也不需要配置浏览器自动化，只要：
- 安装
- 打开任意 LinkedIn 页面（搜索结果、个人资料页、公司页）
- 点击“AI 建议字段”——Thunderbit 的 AI 会读取页面并提出结构化列（姓名、头衔、公司、所在地等）
- 如有需要，调整列，然后点击提取
- 直接导出到 Excel、Google 表格、 或 Notion
由于 Thunderbit 每次都会用 AI 语义读取页面，所以 LinkedIn 改变 DOM 时它不会轻易失效。这和定制 Python 脚本里集成 GPT 的方法逻辑相同，但被封装进了一个你无需维护代码的无代码扩展里。
对于 ——从搜索结果列表点进单个资料页来丰富你的数据表——Thunderbit 会自动处理。浏览器模式也适用于需要登录的页面，无需单独配置代理。
谁还应该用 GitHub 仓库？
GitHub 仓库仍然适合：
- 需要深度定制或特殊数据类型的开发者
- 抓取量极大、按积分计费会很敏感的团队
- 需要在 CI/CD 流水线或服务器上跑抓取的人
- 要把 LinkedIn 数据接入更大自动化工作流的人
对于其他人——尤其是销售、招聘和运营团队—— 能把整个搭建与维护循环都省掉。
分步骤：如何评估并使用 GitHub 上的 LinkedIn 爬虫
如果你已经决定 GitHub 是正确路线，这里有一个分阶段工作流，能尽量减少时间浪费和账号风险。
第 1 步：搜索并初筛仓库
在 GitHub 搜索“linkedin scraper”，并按以下条件筛选：
- 最近有更新（过去 6 个月内）
- 语言与你的技术栈匹配（Python 最常见）
- 范围与你的实际需求匹配（个人资料 vs. 职位 vs. 公司）
先列出 3–5 个看起来还活着的仓库。
第 2 步：应用仓库健康评分表
用前面的评分表逐个筛。删掉以下类型的仓库：
- 过去一年没有提交
- 有未解决的“blocked”或“CAPTCHA”问题
- 只支持密码认证
- 完全没提 sessions、cookies 或 proxies
第 3 步：搭建环境
本次审计中常见的安装命令包括：
1pip install linkedin-scraper
2playwright install chromium
3pip install linkedin-jobs-scraper
4LI_AT_COOKIE=<cookie> python your_app.py
5scrapy crawl linkedin_people_profile常见卡点有：
- 缺少
session.json文件 - 浏览器驱动版本不匹配（Chromium/Playwright）
- 需要从浏览器 DevTools 提取 Cookie
- 代理认证超时
第 4 步：先跑一个小规模测试
从 10–20 个个人资料开始。检查：
- 字段是否正确解析？
- 数据是否完整？
- 有没有触发安全检查？
- 输出格式是否可用，还是一堆原始 JSON 噪音？
第 5 步：谨慎扩量
加入随机延迟（请求间隔 5–15 秒）、降低并发、复用会话，以及住宅代理。不要在新账号上直接冲到每天几百个资料。
第 6 步：导出并整理数据
大多数 GitHub 仓库输出的是原始 JSON 或 CSV。你仍然需要：
- 去重
- 标准化职位和公司名称
- 将字段映射到你的 CRM 或 ATS
- 为合规记录数据来源
（如果你想跳过这一步，Thunderbit 会自动处理结构化和导出。）
LinkedIn 爬虫 GitHub vs. 无代码工具：完整对比
| 维度 | GitHub 仓库（CSS 选择器） | GitHub 仓库（AI/LLM） | 无代码工具（Thunderbit） |
|---|---|---|---|
| 搭建时间 | 1–2 小时以上 | 1–3 小时以上（+ API 密钥） | 2 分钟以内 |
| 技术门槛 | 高（Python、CLI） | 高（Python + LLM API） | 无 |
| 维护 | 高（选择器会坏） | 中（LLM 会适应，但代码仍需更新） | 无（由提供方维护） |
| 反检测 | 自己搞定（代理、延迟） | 自己搞定 | 内置 |
| 准确率 | 运行正常时很高 | 很高，偶尔有 LLM 错误 | 很高（AI 驱动） |
| 成本 | 免费 + 代理成本 + 你的时间 | 免费 + LLM API 成本 + 代理成本 | 免费层；大规模按积分计费 |
| 导出 | 自己处理（JSON、CSV） | 自己处理 | Excel、表格、Airtable、Notion |
| 最适合 | 开发者、自定义管道 | 想降低维护成本的开发者 | 销售、招聘、运营团队 |
法律与伦理考量
这一节我会说得简短些，但不能跳过。
LinkedIn 的 （2025 年 11 月 3 日生效）明确禁止使用软件、脚本、机器人、爬虫或浏览器插件抓取服务。LinkedIn 也已经采取了执法行动：
- ：LinkedIn 宣布对 Proxycurl 采取法律行动
- ：LinkedIn 表示该案已解决
- ：Law360 报道称，LinkedIn 因大规模数据抓取起诉了更多被告
hiQ v. LinkedIn 这一系列案件确实围绕公开数据访问留下了一些灰度空间，但在违约理论上更偏向 LinkedIn。“公开可见”并不等于“在商业复用场景下可以放心大规模抓取”。
对于与欧盟相关的工作流，。法国数据监管机构对 就是一个很具体的例子：监管者把抓取到的 LinkedIn 数据视为受数据保护规则约束的个人数据。
使用像 Thunderbit 这样的维护型工具，并不会改变你的法律义务。但它确实能降低你无意中触发安全响应、或者以会引起 LinkedIn 注意的方式超出速率限制的风险。
2026 年哪些能用，哪些不能用
可行的做法
- 在投入任何仓库之前先做仓库健康评分
- 使用 cookie/session 复用，而不是反复自动登录
- 需要账号型抓取时使用住宅代理
- 采用更小、更慢、更像人的抓取流程
- 当你更看重适应性而不是少量 token 成本时，使用 AI 辅助抽取
- 当真实需求是表格输出，而不是拥有一个爬虫时，使用
- 多准备几种方案，而不是只押注一个公开仓库
不可行的做法
- 不检查维护状态和最近 issue 就直接克隆高星仓库
- 给 LinkedIn 用数据中心代理或免费代理列表
- 不设速率限制或反检测就把量扩到每天几百个资料
- 长期依赖 CSS 选择器而没有维护计划
- 把你的真实 LinkedIn 账号当成一次性基础设施
- 把“公开可访问”误认为“在合同或法律上没有问题”
常见问题
GitHub 上的 LinkedIn 爬虫仓库到 2026 年还在工作吗？
有些还在，但只是一小部分。在这次对 8 个显眼仓库的审计中，只有 2 个对 2026 年读者来说算得上真正可用，而且还需要很多免责声明。关键是看维护活跃度和 issue 健康状况，而不是 star 数。任何项目在投入搭建时间前，都应该先用仓库健康评分表筛一遍。
我每天能抓多少个 LinkedIn 个人资料而不被封？
没有一个绝对安全的数字，因为 LinkedIn 看的是会话行为，而不只是数量。社区反馈显示，每天每账号少于 50 个资料属于较低风险区，50–100 个属于中等风险，这时基础设施质量很重要，而超过 100 个就会越来越激进。5–15 秒的随机延迟和住宅代理有帮助，但没有任何方法能完全消除风险。
有没有 GitHub LinkedIn 爬虫项目的无代码替代方案？
有。 允许你通过几次点击就抓取 LinkedIn 页面，具备 AI 字段识别、基于浏览器的认证（无需代理配置），并可一键导出到 Excel、Google 表格、Airtable 或 Notion。它是为想要数据、但不想维护代码的销售、招聘和运营团队设计的。你也可以通过 试用。
抓取 LinkedIn 数据合法吗？
这是一个灰色地带，而且边界越来越清晰地偏紧。LinkedIn 的用户协议明确禁止抓取，LinkedIn 也在 对爬虫采取了法律行动。hiQ v. LinkedIn 关于公开数据访问的先例在后续判决中已被收窄。GDPR 适用于欧盟居民的个人数据，无论数据是如何收集的。对于任何商业用途，请根据你的具体情况咨询法律顾问。
AI 抽取还是 CSS 选择器——LinkedIn 抓取该选哪个？
CSS 选择器在可用时，每条记录的速度更快、成本更低，但它们会让你陷入持续维护，因为 LinkedIn 会定期改 DOM。AI/LLM 抽取每个资料的成本会稍高一点（按当前 ，大约每个资料 0.001–0.002 美元），但它能自动适应布局变化。对于大多数不是企业级、而是抓几百而不是几百万个资料的用户来说，AI 抽取是更好的长期投资。Thunderbit 内置的 AI 引擎提供了这一优势，而且你无需编写或维护任何代码。
了解更多