盖茨和纳德拉的领英档案，被我3行代码扒了个底朝天

领英上躺着20亿份职业档案，但想批量用起来，多数人还在手动复制粘贴。有人写Python脚本，有人买第三方服务，更多人直接放弃——不是技术门槛高，是 friction（摩擦成本）太烦人。

Apify上最近冒出一个新工具，作者用Go语言写了个Actor（Apify平台上的执行单元），专门啃公开档案。不用Cookie，不用登录，扔进去一个URL，吐出来结构化数据+公司信息+公开联系方式。我扒了下它的设计逻辑，发现这事挺有意思。

为什么公开数据反而更难用

领英的公开页面其实藏了不少东西：姓名、职位、公司、教育背景、技能标签。但页面结构复杂，动态加载多，反爬机制还时不时变阵。

作者的原话是：「I wanted something simpler.」——翻译过来就是，现有的工具要么要管理Session Cookie，要么返回的数据太脏，要么批量跑起来像挤牙膏。

他的解法分两层。解析层用HTML选择器+JSON-LD提取双保险，前者抓可见内容，后者挖页面里埋的结构化数据。执行层用Go的并发Worker，配重试机制和代理轮换，把单档案抓取时间压到秒级。

一个细节：支持流式输出。跑几百个档案时，不用等全部跑完才能看结果，第一个档案解析完就能进你的数据库。

公司信息从哪来

档案数据只是前半场。这个工具的后半段是做公司信息补全——不是调领英的公司页API，而是去公开渠道挖：公司官网、招聘页面、联系页面。

逻辑很产品经理：领英上的公司描述往往是PR话术，但公司官网的「About Us」和招聘页的技术栈要求，反而更接近真实业务画像。

作者举了个输入示例，用的是比尔·盖茨和萨提亚·纳德拉的公开档案URL。两个URL扔进去，返回的JSON里除了个人履历，还带了各自关联公司的域名、规模信号、以及从官网扒出来的公开邮箱格式。

这对应了三种典型用法：销售团队做线索富集、投资人扒创始人背景、市场研究搞竞品人才mapping。作者自己归类得很清楚：「enriched lead or research datasets」—— enriched 是关键词，raw data不值钱，structured enriched data才值钱。

Go语言选型背后的算计

Apify平台支持Node.js、Python、Go等多种运行时，但作者选了Go。理由没明说，但代码结构露了底：并发控制、内存管理、二进制部署。

Python写爬虫快，但GIL（全局解释器锁）让真·并行成了笑话。Node.js异步爽，CPU密集型解析时容易卡脖子。Go的goroutine+channel模型，刚好卡在中间地带：并发够轻量，解析够快，编译成单二进制文件扔上Apify也省事。

代理支持是硬需求。领英对异常流量的识别越来越准，单IP高频请求分分钟进验证码黑洞。工具里配了代理轮换，但没写死供应商——Apify的代理池、用户自己的代理列表，都能接。

一个产品细节：作者把「best-effort contact discovery」写进了功能描述。best-effort 是免责声明，意思是我们不保证一定能找到邮箱，但会尽力从公开页面推导出命名规则。比如官网有「press@company.com」，工具会推测「firstname.lastname@company.com」的概率分布。

合规红线画在哪

作者在文档里反复强调：「publicly visible LinkedIn data only」。公开档案页是数据源，不碰登录墙后的内容，不绕过身份验证。

这既是技术边界，也是法律自保。领英2019年告过HiQ Labs，最高法院2021年把案子踢回下级法院，但公开数据的 scraping 合法性至今是灰色地带。工具设计上主动收窄范围，只啃公开页，是在把法律风险从用户侧转移到可控的技术实现侧。

Apify平台上的Actor有评分和运行次数，这个工具目前还在早期，但设计思路很典型：不是做「更强的爬虫」，而是做「更少摩擦的数据管道」。输入URL，输出干净JSON，中间的黑盒对用户不可见。

作者留了个尾巴：「If you want, I can also share the implementation details」——意思是解析逻辑、富集 pipeline、错误处理策略，都可以展开讲。这很符合Apify社区的风格，工具开源，知识也开源，跑通了再卖咨询服务。

领英自己不做这种批量工具，原因 obvious：商业利益冲突。但公开数据就在那里，总有人会去挖。问题是，你愿意花多少 friction 去换这些数据？